Restkit throws false error with 202 without content-type #1685

Closed
Cedrick84 opened this Issue Nov 25, 2013 · 11 comments

Projects

None yet

3 participants

@Cedrick84

When I do a POST that returns a 202 (accepted) without any content and thus without a Content-Type header, the failure block gets triggered and throws the following error:

Error Domain=org.restkit.RestKit.ErrorDomain Code=-1016 "Expected content type {(
    "application/x-www-form-urlencoded",
    "application/json"
)}, got text/plain" 

As a response with Content-Length 0 doesn't need to have a Content-Type header I expect that the success block should be fired as the response code is in the 200 range.

If more info is needed please let me know.

@segiddins
Member

@blakewatters if you want to make this change, I can whip up some test coverage and implement. Would just like a reference on what codes don't need a content-type

@blakewatters
Member

We already have a workaround for this issue for the 204 (No Content) status code. We just need to add corresponding support for 202. Please make it so @segiddins. If you search for 204 in the tests/implementation it should be very straightforward.

@segiddins
Member

Are those the only two status codes where it should apply?

@blakewatters
Member

It may also make sense to support situations where Content-Length=0... but then again we aren't hearing a bunch of bug reports about this behavior so it may be unnecessary.

@segiddins
Member

I think I'll do that because I believe 201 is valid with an empty response body

@blakewatters
Member

cool works for me

@segiddins
Member

Unrelated, but we should probably bump the ruby version

@blakewatters
Member

Great answer on SO explaining the status codes for which this is acceptable behavior: http://stackoverflow.com/a/8628757/177284

Based on how large the list is, it feels much more reasonable to use the Content-Length=0 as the deciding factor rather than blessing individual status codes.

This may require corresponding changes in AFNetworking for RK 1.0 since we won’t have our own operation classes. The default HTTP response serializer should handle this content length check and skip the acceptable types check.

@blakewatters
Member

I already bumped it on the AFN 2.0 / RK 1.0 branch. Will get that pushed during the time off this holiday

@Cedrick84

The content length 0 is indeed the best solution here. Thanks so much for implementing. Cheers

@segiddins
Member

@Cedrick84 the issue is that there are many servers that don't report a content-length. For now, I've only made it so that more status codes can be exempted from content-type checking

@segiddins segiddins closed this in #1686 Dec 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment