|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005411||libmicrohttpd||compliance||public||2018-07-25 13:07||2018-08-08 11:13|
|Assigned To||Christian Grothoff|
|Target Version||Fixed in Version|
|Summary||0005411: MHD incorrectly sets Transfer-Encoding when Content-Length header is present|
We have a piece of software which uses libmicrohttpd to serve HTTP responses. The data to be returned is of a known length, and as such we set the Content-Length header in the response. In our particular use-case, the client needs to know the full length of the response upfront.
However, we've observed that when setting the Content-Length header via MHD_add_response_header, there's nothing in MHD to flag that it must not (as per https://tools.ietf.org/html/rfc7230#section-3.3.2 ) send a Content-Length header in a response that contains a Transfer-Encoding header.
I've attached a quick patch which adds an additional flag into build_header_response so that Transfer-Encoding is not set if the application has already provided a Content-Length header.
Let me know what you think.
|Tags||No tags attached.|
Christian Grothoff (manager)
Ok, interesting. But re-reading RFC 7230 it seems to me that we need to do a bit more about Transfer-Encoding vs. Content-Length: if a client sets 'Transfer-Encoding: gzip' we must also detect this, append ", chunked" *and* then disable setting of Content-Length and instead do the chunking. I think we don't do that either.
Let me know if this is urgent, then I could apply the patch quickly. Otherwise, I'd rather spend the time to address this issue more comprehensively.
|It's not urgent for us, I can always add patches to our own packages to fix the specific issue that we're seeing for now. By all means add your own changes to cover the case of gzip as well.|
|2018-07-25 13:07||samh||New Issue|
|2018-07-25 13:07||samh||File Added: 0001-Don-t-set-transfer-encoding-if-content-length-suppli.patch|
|2018-08-05 22:09||Christian Grothoff||Note Added: 0013174|
|2018-08-05 22:09||Christian Grothoff||Assigned To||=> Christian Grothoff|
|2018-08-05 22:09||Christian Grothoff||Status||new => assigned|
|2018-08-08 11:13||samh||Note Added: 0013188|