search

benoitc / hackney

simple HTTP client in Erlang
Other
1.34k stars 427 forks source link

feat. Req: ability to suppress default content-type #596

Open ityonemo opened 4 years ago

ityonemo commented 4 years ago

I have been mocking a (poorly written) HTTP request by a coworker and after a lot of debugging found that the request was failing to emit a content-type header, it might be nice to suppress the default content-type with an option or by pre-setting it to the atom undefined.

benoitc commented 4 years ago

in which case you don't want to send a content-type header ?

joeapearson commented 3 years ago

I came across this need too when implementing a call to make this request: https://docs.microsoft.com/en-us/rest/api/storageservices/create-container

It's an HTTP PUT with no body specified, so (I assume) a Content-Type header is not appropriate in this context.

As it happens, MS Azure doesn't seem to care about the default application/octet-stream that is added so I was able to work around easily. I did however end up spending an hour or two of hunting around while I tried to figure out where it was coming from :).

paulo-ferraz-oliveira commented 3 years ago

Some context... RFC 2616 states "The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. [...] if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.", so I guess what hackney could do is suppress content-type, by default, if no body is present in the request (i.e. if content-length =:= 0). (this would prevent an option being required). Some care might also be required for transfer-encoding (I mainly found references to chunked in the source).

joeapearson commented 3 years ago

@paulo-ferraz-oliveira thanks. Suppressing content-type as you describe sounds sensible and would work for my particular use case.