On Wed, Dec 7, 2016 at 4:19 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Dec 7, 2016 at 2:23 PM, Jacob Champion <champio...@gmail.com> > wrote: > >> On 12/07/2016 12:03 PM, William A Rowe Jr wrote: >> >>> On Wed, Dec 7, 2016 at 10:50 AM, Jacob Champion <champio...@gmail.com >>> <mailto:champio...@gmail.com>> wrote: >>> >>> What's your end goal? I don't think we can *prohibit* modules from >>> sending extra headers in 100 responses, but it does make sense to >>> limit what we send by default, especially if we're currently sending >>> Content-Length (which IIUC is meaningless in that context). >>> >>> When we send 100 CONTINUE from the http_filters.c core read >>> filter, we send no headers. Simple. >>> >> >> 1) Are 1xx responses handled by the http_filters code? I was under the >> impression that they were not. >> > > that code generates 100 CONTINUE responses, yes. Although not > for mod_proxy_http in RFC mode, that case is a pass through of > the various 1xx responses, except for 100 if it is not expected still. > > > >> 2) This is allowed by the spec, I guess, but it seems punitively strict >> to me. Some deployments might be using something interesting in the >> headers, perhaps a precursor to the upcoming 103? > > > From a mod_proxy perspective, other 1xx's could be sent with the > headers that accompanied them, but what headers of value can > httpd add? None, IMO. mod_proxy_http should read the headers > from 1XX interims into an empty headers array and send them on > using ap_send_interim_response without extra processing, until > we finally arrive at a final status which httpd should decorate using > whatever happened to the headers_out array during pre-processing, > including mod_headers activity. > > >> mod_proxy_http shoves all existing Set-Cookie headers into the >>> >> interim response (e.g. those added by other modules), and it doesn't >>> appear that these headers are cleared after a 100 continue response. >>> The Via response is added, hop by hop headers are cleared, and >>> a whole bunch of other inappropriate processing is going on there. >>> That module looks the most problematic, send_interim_response >>> was not very well thought out and includes much internal httpd >>> decoration that is only appropriate for the final response. >>> >> I mean the logic between reading interim headers and the call to send_interim_response was inappropriate... and note that we really can't relay very many 'unexpected' 1XX codes, in fact all 1xx codes must be negotiated (even 100 with the 100-continue expectation), something that we will be ill-posed to do as a proxy intermediary. For example, the protocol negotiation itself is hop-by-hop and the mod_proxy_http can only speak protocols it knows. We may want to use 100-continue expectations to the backend even if our client is HTTP/1.0 and we cannot forward them, provide them to our client when asked even if the backend won't support them, etc. This item in particular can't be resolved for 2.4.24 IMO, it is sufficiently borked as to merit no attention until those items with concensus are completed and 2.4.24 is tagged.
