[combining replies to your last two emails]
On 12/07/2016 02:19 PM, William A Rowe Jr wrote:
On Wed, Dec 7, 2016 at 2:23 PM, Jacob Champion <champio...@gmail.com
<mailto: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>
<mailto: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.
I misunderstood this sentence to be your answer to my question (i.e. I
thought you were saying "we should never send headers in 100 Continue").
I see now that you were simply describing the current behavior
("ap_http_filter() currently sends no headers when dealing with 100
Continue").
In that light, my next two questions didn't make much sense.
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 can't tell if we're discussing just the proxy behavior, or all 1xx
processing in general. Again, I thought the original bug report was
related to 204 processing only, and then Luca asked if his patch should
also include informational-status checks as well.
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
103 Early Hints is in discussion on the IETF lists. The client
interoperability angle -- which I assume is what you're referring to
below -- is part of that conversation, and so far there seems to be
significant interest in fixing up clients so that they properly deal
with unsolicited 1xx codes, as required by the spec.
In fact there doesn't seem to be any canonical definition. HTTP/1.1
should surely reject such
No, not reject -- conforming clients parse (and may discard) 1xx's they
don't understand, treating them like 100 Continue, and proxies must
forward as-is (unless the proxy was the agent requesting the 1xx
response). Right?
RFC 7231, sec. 6.2:
A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses.
A proxy MUST forward 1xx responses unless the proxy itself requested
the generation of the 1xx response. For example, if a proxy adds an
"Expect: 100-continue" field when it forwards a request, then it need
not forward the corresponding 100 (Continue) response(s).
, 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.
They can be combined, yes, but you said "it handles 101 UPGRADE interim
responses without first testing that expecting-100 was satisfied, per
spec". That test is *not* required; the two features are orthogonal to
each other.
On 12/07/2016 02:26 PM, William A Rowe Jr wrote:
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),
Not per spec. Practically speaking, it is probably *wise* not to
generate unsolicited 1xx's at this time, considering how many clients
have historically seen fit to ignore that MUST I referenced above. But
like I said, there's currently some interest in fixing that on the
modern web, and we should make sure we evolve alongside everyone else.
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.
--Jacob
