Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

If MIMEType is NULL #505

achainan opened this Issue Sep 7, 2012 · 1 comment


None yet
2 participants

achainan commented Sep 7, 2012

If the MIMEType is NULL shouldn't we be on the safe side and respond YES?

Example change:

- (BOOL)hasAcceptableContentType {
    if (!self.response) {
        return NO;

    if (!self.response.MIMEType == NULL) {
        return YES;

    return ![[self class] acceptableContentTypes] || [[[self class] acceptableContentTypes] containsObject:[self.response MIMEType]];

mattt commented Sep 7, 2012

Well, let's see what the RFC has to say about it:

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

According to this, it seems like the correct approach would be to default to application/octet-stream in the rare cases where no type is defined. This way, you can register application/octet-stream as an acceptable content type, and make this check pass.

This has been added in c0d7e11. Thanks for pointing this out.

@mattt mattt closed this Sep 7, 2012

egrim pushed a commit to egrim/AFNetworking that referenced this issue Sep 18, 2012

greghe pushed a commit to skillz/AFNetworking that referenced this issue Sep 3, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment