Content-Type header should be optional in Response

[rmedaer]

🐞 Describe the bug
I'm not able to remove the Content-Type header in aiohttp.web.Response. However, according to HTTP RFC, the Content-Type header is not mandatory. Especially if you don't return content (e.g. 204 No Content)

💡 To Reproduce

from aiohttp.web import Response

async def handler(request):
    return Response(
        status=204,
        content_type=None
    )

💡 Expected behavior

Be able, some how, to remove the Content-Type header.

📋 Logs/tracebacks

Result from curl:

< HTTP/1.1 204 No Content
< Content-Length: 0
< Content-Type: application/octet-stream
< Date: Fri, 06 Mar 2020 11:32:46 GMT
< Server: Python/3.7 aiohttp/3.5.1

[borysvorona]

I do not agree with that, according to
https://tools.ietf.org/html/rfc2616#section-7.2.1

I think that an additional optional Response param can solve that issue.
For example:

aiohttp.web.Response(status=204, force_empty_content_type=True)

[rmedaer]

I do not agree with that, according to
https://tools.ietf.org/html/rfc2616#section-7.2.1

Could you expand on that, please ?

If I well understand the RFC, the entity-body is optional... Here is the relevant quotes where I highlighted some keywords and added some footnotes:

Section 7.2.1 Type (you quoted):

When² an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type (...)
Any HTTP/1.1 message containing an entity-body SHOULD¹ include a Content-Type header field defining the media type of that body.

Section 7.2 Entity Body:

The entity-body (if any) (...)
An entity-body is only present in a message when a message-body is present³ (...)

If my understanding is correct, it means:

1. A Content-Type is not mandatory
2. A Content-Type header should be specified if an entity-body is included
3. If there is not any message body, there is no entity-body

So, if not any body is returned, not any Content-Type header should be returned !

[asvetlov]

This issue has been mentioned on aio-libs. There might be relevant details there:

https://aio-libs.discourse.group/t/optional-content-type-header/82/1

[alex-eri]

Write custom Response subclass and fix setter

aiohttp/aiohttp/web_response.py

Line 254 in fe647a0

@content_type.setter

[rmedaer]

@alex-eri I don't understand why I should write a custom Response subclass for what should be a default behavior.

IMHO we should use response subclass to add extra feature/behavior, not to remove them.

I found a nice illustration of the issue in Chrome. Currently, if I return a (not-so) empty 404:

async def not_found(request):
    return Response(status=404)

# < HTTP/1.1 404 Not Found
# < Content-Type: application/octet-stream
# < Content-Length: 0
#  (...)

Chrome shows an invalid response (due to the Content-Type application/octet-stream)

If I remove the Content-Type and Content-Length headers (or if Content-Type is text/html), here is what Chrome shows: