Migrating existing code from Almofire v4.8.2 to the latest beta v5.0.0-beta.5.
I have a post network request which returns empty response body with an Authorization header.
as in the previous stable version, Response Data call should succeed and I can parse Headers from the response
It throws error responseSerializationFailed(reason: Alamofire.AFError.ResponseSerializationFailureReason.inputDataNilOrZeroLength)
Alamofire version: 5.0.0-beta.5
Xcode version: 10.2
Swift version: 5
Platform(s) running Alamofire: iOS
macOS version running Xcode: 10.14.4
https://github.com/ashusath/AlamofireBetaAlamofireTestEmptyResponse
https://github.com/ashusath/AlamofireTestEmptyResponse
Can you provide more information about your response? We support the automatic handling of 204 and 205 response codes, as well as .head requests. If your response does not have one of those properties you'll need to customize your response serializer to allow it.
Thank you for response @jshier, Here is the mock URL http://www.mocky.io/v2/5cb82f8b4c00000319d3d3c9. I have to parse the Authorization header from the response, It has an empty body.
It's a login request and we post the credentials to this endpoint.
It is working properly on v4.8.2 and before.
Will I have to make changes to use with Alamofire 5?
If you can update the server to return a proper 204 response, it should work automatically, as a 200 isn't usually considered valid for an empty response.
If you can't make the change, there are a variety of things you can do. You could:
response(queue:responseSerializer:completionHandler) that enables the additional empty response codes.response(queue:completionHandler:).ResponseSerializer that allows all of the flexibility you need. You can use our built in serializers as examples.Thank you! We think about it and decided to update the server to return a proper 204 response.
isn't usually considered valid for an empty response.
What's the benefit of adding this check, if it's only "usually"?
Complicates life a little bit for the cases where it's the case. Eg. Uploading to Amazon S3 now requires the workarounds..
Ok turned out easier than I imagined from jshier's answer, pasting here for anyone else facing:
let dataResponseSerializer = DataResponseSerializer(emptyResponseCodes: [200, 204, 205]) // Default is [204, 205]
manager.upload(multipartFormData: { multipartFormData in
/// ...
}, usingThreshold: UInt64.init(), to: ep.s3.virginiaBucketUrl, method: .post, headers: headers)
.response(responseSerializer: dataResponseSerializer) { response in
switch response.result {
case .failure(let error):
// ...
case .success(let value):
// ...
}
}
Most helpful comment
Ok turned out easier than I imagined from jshier's answer, pasting here for anyone else facing: