Repository navigation
feat. Req: ability to suppress default content-type #596
Description
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.
Activity
benoitc commentedon Apr 17, 2020
in which case you don't want to send a content-type header ?
joeapearson commentedon Dec 17, 2020
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-Typeheader is not appropriate in this context.As it happens, MS Azure doesn't seem to care about the default
application/octet-streamthat 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 commentedon Dec 19, 2020
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
hackneycould do is suppresscontent-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 fortransfer-encoding(I mainly found references tochunkedin the source).joeapearson commentedon Dec 22, 2020
@paulo-ferraz-oliveira thanks. Suppressing
content-typeas you describe sounds sensible and would work for my particular use case.