CODEWITHSUNDEEP
swiftalamofirensurlsession
boidkan
boidkan

Reputation: 4731

Alamofire: Error Domain=NSPOSIXErrorDomain Code=100 "Protocol error in iOS 11

Running AlamoFire 4.5 Swift 4 (my project)

I only get this bug in iOS 11.

So I recently started to get this error non stop for a working api endpoint:

Error Domain=NSPOSIXErrorDomain Code=100 "Protocol error" UserInfo={NSErrorPeerAddressKey=<CFData 0x1c40913f0 [0x1b2c04240]>{length = 16, capacity = 16, bytes = 0x100201bb36aec68a0000000000000000}, _kCFStreamErrorCodeKey=100, _kCFStreamErrorDomainKey=1}

This is the jist of how I am making the request:

let urlPath = "SOME_PATH"
var params = [String:Any]()
params["app_version"] = version
params["apnsEnabled"] = apnsEnabled
params["ios_version"] = DeviceInfo.getIOSVersion()
params["model_name"] = UIDevice.current.modelName

let request = AFSessionManager.shared.manager.request(urlPath, method: HTTPMethod.get,  parameters: params as Parameters, headers: ["requested-domain":ServerDomain.get()!] as HTTPHeaders)

request.responseJSON{ response in
            if response.result.error == nil{
                 //DO STUFF               
            }else{
                 //HANDLE ERROR
            }
}

EDIT:

I also ended up trying this with just URLSession:

func ping(){

    let session = URLSession(configuration: URLSessionConfiguration.default)

    let request = URLRequest(url: URL(string: "MY_PING_URL_STRING")!)

    let task: URLSessionDataTask = session.dataTask(with: request) { (data, response, error) -> Void in

        guard error == nil else {
            //Handle Error
            return
        }

        //DO STUFF
    }
    task.resume()
}

Still got the protocol error with just URLSession.

Also, getting this error in Safari on MacOS High Sierra.

Upvotes: 0

Views: 2147

Answers (1)

boidkan
boidkan

Reputation: 4731

I went through apple and got some help. Here was their response:

The server sends the “upgrade” header in the response. This is the header that is used in the http request and disallowed as the response header by our internal implementation. Removing or using a different name for the header (if this information is still needed to be passed to the client) will solve the problem.

It turns out that Apache responds with upgrade in the header telling the client to upgrade to http/2. However, it is broken when SSL/TLS is being used. Here is the discussion on Apache's bugzilla. It also looks like the upgrade header was always being sent even if the client was using http/2.

You can remove the header in Apache by putting this in host config:

Header unset Upgrade

Upvotes: 3

Related Questions