Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent default Content-Type #184

Closed
tailhook opened this issue Dec 2, 2014 · 7 comments
Closed

Inconsistent default Content-Type #184

tailhook opened this issue Dec 2, 2014 · 7 comments
Labels

Comments

@tailhook
Copy link
Contributor

tailhook commented Dec 2, 2014

When body is string or bytes object the aiohttp sets default content type to application/octed-stream, but when body is StreamReader or coroutine or other kind of stream the Content-Type is not touched.

I believe automatic Content-Type should not be set. But in case it has to, it should at least be consistent.

@asvetlov
Copy link
Member

asvetlov commented Dec 4, 2014

Hmm. Do you talk about aiohttp.client or aoithttp.web ???

@tailhook
Copy link
Contributor Author

tailhook commented Dec 4, 2014

I talk about aiohttp.client

@tailhook
Copy link
Contributor Author

tailhook commented Dec 4, 2014

It's also data not body

@lithammer
Copy link

Taken from RFC 2616, chapter 7.2.1:

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.

@tailhook
Copy link
Contributor Author

tailhook commented Mar 4, 2015

@Renstrom, I'm not sure what you mean. The HTTP spec says "recipient SHOULD", but aiohttp sets header at sender side.

Well, if it's not clear the issue is about the body of POST (and other) requests sent from client to server.

@lithammer
Copy link

Perhaps I misinterpreted. But on the server side, if a client sends a request with a body (regardless of verb) and the Content-Type header is missing for whatever reason, the server should interpret it as application/octet-stream. That is, unless you wanna implement some kind of guessing algorithm.

I figured you were talking about what a server should do since you mentioned StreamReader. But I see now that you explicitly said aiohttp.client, my bad...

@lock
Copy link

lock bot commented Oct 29, 2019

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.

@lock lock bot added the outdated label Oct 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants