From a pure protocol point of view, all responses can have headers, I think. But there might be several implementations that do not cope well with them. But if we get some from an upstream server, I think we should forward them.
> Am 07.12.2016 um 17:31 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > On Wed, Dec 7, 2016 at 9:05 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Nov 30, 2016 11:46 AM, "Luca Toscano" <toscano.l...@gmail.com> wrote: > Hi everybody, > > while working on https://bz.apache.org/bugzilla/show_bug.cgi?id=51350 a user > asked why httpd send the "Content-Length: 0" header for HTTP 204 responses > given the following statement in the RFC: > > https://tools.ietf.org/html/rfc7230#page-30 > "A server MUST NOT send a Content-Length header field in any response with a > status code of 1xx (Informational) or 204 (No Content)." > > I was looking at the spec for 101 and 100 responses and think we are going > way overboard on replying with a 100 response. Looking at the 101 example, we > should send a reply of 0 or a few very explicit header fields and save the > balance of output headers for the final response code. Otherwise these all > seem to be wasted network bytes. > > > The 101 Upgrading response has a very short list of necessary > headers, only Connection: and Upgrade: fields are informative; > https://tools.ietf.org/html/rfc7230#section-6.7 > > I did not find anything in these sections on useful 100 Continue > response headers, and believe there are none; > https://tools.ietf.org/html/rfc7231#section-6.2.1 > https://tools.ietf.org/html/rfc7231#section-5.1.1 > > Does anyone have pointers to legitimizing any 100 response > headers? >
