Alamofire: default emptyResponseAllows returns false unless HTTP Method is .head

[jvannoord]

• [x] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.

What did you do?

I'm deserializing a response from an HTTP PUT Method and returns an empty status code (204).

What did you expect to happen?

My instinct was that ResponseSerializer.emptyResponseAllowed(forRequest:response:) would return true if either the http method was HEAD or the status code was 204/205.

If I were to have written this method, it would have looked like this:

requestAllowsEmptyResponseData(request) == true || responseAllowsEmptyResponseData(response) == true

What happened instead?

It appears that in the default case, the code returns true only if the http method is HEAD AND the status code to be 204/205. Below is the current code.

requestAllowsEmptyResponseData(request) ?? responseAllowsEmptyResponseData(response) ?? false

Again, I'm merely asking if this is logical AND is intentional or not.

The workaround is easy: just need to explicitly enumerate all of the HTTP methods that can return empty responses.

Alamofire Environment

Alamofire version: 5.0.0-beta3
Xcode version: 10.1 / 10.2
Swift version: 4.2
Platform(s) running Alamofire: iOS

[jshier]

My first thought is that this is a bug from being too clever during cleanup of these methods. It should certainly be what you've put. Seems like we'll need a fix and some testing around this.

[jshier]

@jvannoord Give the bug/2770-empty-response-logic branch a shot, that should fix it. We'll roll this into the next beta, I just need to write some tests for it. Thanks for the report!

[jvannoord]

Whoa, just like that! Thanks! I was gonna volunteer, but you. are. on. it.

[ruslankaminsky]

I've just encountered this issue today morning, after updating from v4.8 to v5 beta 3. And noticed that server responses with code 204 and empty body started to be handled as errors with "Alamofire.AFError.ResponseSerializationFailureReason.inputDataNilOrZeroLength" error.
I'm happy that it will be fixed soon.

[cnoon]

This issue should be resolved in the 5.0.0-beta.4 release. Please test it out and let us know!

Cheers. 🍻