Response sends content-type when no body is sent

[leth]

Long story short

With a recent release the "default" content type became "application/octet-stream".
This appears to be added to responses which do not include a body, so content-type is not relevant.

Expected behaviour

No content-type header present

Actual behaviour

content-type: "application/octet-stream"

Steps to reproduce

Your environment

[asvetlov]

What behavior it breaks?

[leth]

We have a unit test that checked there was no content type being sent on our API's 404 response, which has no body.

I don't know if it actually breaks anything, it's just not quite in line with the RFCs.
application/octet-stream is only the default content-type IF there is a message body on the request.

[asvetlov]

Sorry, I couldn't find exact RFC rule for this.
Would you mind pointing to the reference?

[leth]

The default references RFC 2616. I've down broken the paragraph I think it's referencing below:

Any HTTP/1.1 message containing an entity-body SHOULD include Content-Type header field defining the media type of that body.

If there is an entity-body sending a Content-Type header is advised, but optional.

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 missing, clients are permitted to guess.

If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

If clients can't guess, fall back to "application/octet-stream"

I don't think this suggests that an HTTP server should by default send a header with a default value.
Perhaps what's happened here, is that client and server code have become shared, and some odd behavior has crept in!

[asvetlov]

Well, the rule for not sending Content-Type is very complicated actually.

• Present if Content-Length is present and not 0.
• Present if chunked encoding is used (Transfer-Encoding: chunked).
• Present if implicit BODY are sent and user has improperly configured headers. It's still possible when StreamResponse is used.
• Present if no BODY is sent but request's type was HEAD.
• Absent if no BODY is sent and request's type is not HEAD.

The problem is: on headers sending stage it's impossible to figure out will user send data later or not?

The change was introduced by #1124 (fix for #944) and 3d53ba8

I don't think that server's behavior is incorrect now. It shouldn't break any existing client I believe.

[leth]

Hmm. Okay so is there a easy way to tell aiohttp to not send a content-type?

The reason we do this is our 404 response has no body but used to send a content-type heaser; Firefox would try to parse the empty body and would complain that the json was malformed.

[asvetlov]

del response.headers['Content-Type'] should help.

[asvetlov]

BTW default Content-Type is application/octet-stream.
If Firefox complains about malformed json maybe your code sets the type to application/json somewhere?

[leth]

It used to, when I originally fixed that I added the test to assert there was no header, which led to this issue when we upgraded!

Anyway, if it's simple to work around, and won't break anything then I'm happy to close this.
Thanks!

On 23 September 2016 14:21:56 BST, Andrew Svetlov notifications@github.com wrote:

BTW default Content-Type is application/octet-stream.
If Firefox complains about malformed json maybe your code sets the type
to application/json somewhere?

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#1191 (comment)

Sent from my phone. Please excuse my brevity.

[asvetlov]

Sure!

[lock]

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.