httpAdditionalHeaders在Linux上不起作用 [英] httpAdditionalHeaders not working on linux

问题描述

在OS X和Linux上，我遇到了URLSession/URLSessionConfiguration/URLSessionDataTask行为不同的问题.

迅捷:3.0.2 Kitura:1.3

我正在执行以下操作:

let aURL = URL(string: "...")!

// Because shared is not implemented                
let sessionConfig = URLSessionConfiguration.default

sessionConfig.httpAdditionalHeaders = ["Accept": "application/json", "Accept-Language": "sv-SE"]

let session = URLSession(configuration: sessionConfig)

// additionalHeaders are set just fine                
Log.info("\(session.configuration.httpAdditionalHeaders)")

let dataTask = session.dataTask(with: aURL, completionHandler: { data, loadResponse, error in
                   ...
                })

 dataTask.resume()

其他头是在配置对象上设置的，但是当部署到Bluemix时，响应表明缺少语言头字段(我用错误的语言得到了响应).

我知道该请求是正确的，因为当我在本地(通过OS X上的Xcode)构建并运行此程序(Kitura)时，我得到了预期的行为.

有人遇到过这个吗?该怎么办?去哪里?

解决方案

这本来可以是评论，但仍然不允许我发表评论！

是的，我的同事在研究此bug 时遇到了这个问题.我认为您采用的解决方法是最好的替代选择.这需要更多的调查.我为此问题创建了一个新错误报告报告.

I ran into a problem of different behaviour of URLSession / URLSessionConfiguration / URLSessionDataTask on OS X and Linux.

Swift: 3.0.2 Kitura: 1.3

I am doing following:

let aURL = URL(string: "...")!

// Because shared is not implemented                
let sessionConfig = URLSessionConfiguration.default

sessionConfig.httpAdditionalHeaders = ["Accept": "application/json", "Accept-Language": "sv-SE"]

let session = URLSession(configuration: sessionConfig)

// additionalHeaders are set just fine                
Log.info("\(session.configuration.httpAdditionalHeaders)")

let dataTask = session.dataTask(with: aURL, completionHandler: { data, loadResponse, error in
                   ...
                })

 dataTask.resume()

The additional headers are set on the configuration object, but when deployed to Bluemix the response show that language header field is missing (i get the response in wrong language).

I know that the request is correct because when I build and run this (Kitura) locally (thorough Xcode on OS X) I get the expected behaviour.

Has anyone encountered this? What to do? Where to go?

解决方案

This could've been a comment, but I am still not allowed to post comments!

Yes, my colleague came across this while working on this bug. I think the work-around that you adopted is the best alternative option. This needs more investigation. I have created a new bug report report for this issue.

这篇关于httpAdditionalHeaders在Linux上不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！