httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject Re: About Interim Response Headers (was: Content-Length header for 1xx status codes)
Date Wed, 07 Dec 2016 20:23:37 GMT
On 12/07/2016 12:03 PM, William A Rowe Jr wrote:
> On Wed, Dec 7, 2016 at 10:50 AM, Jacob Champion <
> <>> 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.


View raw message