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. > I'm looking at ap_send_interim_response and am somewhat confused >> by core_upgrade handler, which I'll get to in a moment. >> >> h2_h2.c check_push() applies only to HTTP/2, and notably does >> not clear headers_out before adding the Link header and pushing >> out a 103 response, but I'm not going to dig much further at this >> exact moment. >> > > Well, in that case the entire point of 103 is to send headers. That is, if > I'm understanding the spec correctly; Stefan, can you confirm? 102 PROCESSING is defined here, per the registry, https://tools.ietf.org/html/rfc2518#page-59 It doesn't seem to call for additional headers (concieveable one would want to add X-Delay: sec or something). 103 is not defined here; http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml In fact there doesn't seem to be any canonical definition. HTTP/1.1 should surely reject such, HTTP/2, ENOCLUE (but mod_proxy_http2 should not let it dribble back into HTTP/1.1 requests). > 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. >> >> core_upgrade_handler (in server/core.c) *does* clear headers_out >> before adding the two necessary Upgrade and Connection headers, >> so in this context we are good. But it handles 101 UPGRADE >> interim responses without first testing that expecting-100 was >> satisfied, per spec. There appears to be no way to process more >> than one upgrade (and we know from spec, that multiple upgrades >> may be necessary; crypto vs framing, for example). >> > > Expect: 100-continue doesn't have anything to do with 101 Upgrade... and > more than one upgrade doesn't make sense IMO, as the HTTP protocol is > replaced wholesale. I think a couple of protocol pieces are being confused > here. Uhm, they can be combined and the spec is clear on how must happen.
