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. 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?
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?
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.
--Jacob
