On Wed, Dec 7, 2016 at 10:50 AM, Jacob Champion <champio...@gmail.com> wrote:
> On 12/07/2016 08:31 AM, William A Rowe Jr wrote: > >> Does anyone have pointers to legitimizing any 100 response >> headers? >> > > Date is called out explicitly (RFC 7231, sec. 7.1.1.2): > > [...] An origin server MAY > send a Date header field if the response is in the 1xx > (Informational) or 5xx (Server Error) class of status codes. > > It was even more explicit in 2616 (sec. 14.18): > > 1. If the response status code is 100 (Continue) or 101 (Switching > Protocols), the response MAY include a Date header field, at > the server's option. > > 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. 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. 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). Prior to core_upgrade_handler calling ap_send_interim_response to the upgrade, The 100 continue interim response is required, and in response to the client's reaction to the 100 continue, the request body must be read off the wire. Only then may the upgrade interim response, and ap_switch_protocol handling occur. We also seem to be failing to send Upgrade and Connection headers after the first response (c.f. the c->keepalives), in the core_upgrade_handler. Is this some "stateful" reading of the HTTP protocol? I had thought we discussed this on list once before. It appears to run in the map_to_storage hook for OPTIONS * requests, and is deferred to VERY_FIRST in the handler phase otherwise. This seems awfully late for the intermediate phases, e.g. auth requiring a TLS connection, but it doesn't seem possible to resolve this with respect to 100 continue, which the spec insists can be avoided with an error response, and they use an auth failure in that example :) > *Are* we currently sending Content-Length in 100 responses? Luca's bug > mentions 204 only. > I may have misread the top line complaint here.
