httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bert Huijben <b...@qqmail.nl>
Subject RE: AW: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls
Date Mon, 07 Dec 2015 22:30:48 GMT
Is this a h2 limitation or a mod_h2 limitation?

If I would like h2c upgrade from Subversion without an additional request I would have to
send the upgrade request with a very short OPTIONS request that has a body.

The way I read the spec that should be possible if both sides go through all those rough edge
cases to support a request in one protocol and the response in the other. For serf I intended
to implement that, but I’m not sure if it is worth the trouble if httpd doesn’t implement
it.

Bert

Sent from Mail for Windows 10



From: Stefan Eissing
Sent: maandag 7 december 2015 20:11
To: dev@httpd.apache.org
Subject: Re: AW: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls


h2 does not propose a switch if the request has a body. 

As clarified on the http wg lists by the gurus there,  when i asked, the upgraded connection
is in a mixed state after a 101. Any byte sent by the server MUST be from the switched protocol,
while the client needs to send the body in HTTP/1 format and can only talk the new proto afterwards. 

For an Expect 100 that would mean that the 100 intermediate comes before the 101. However
that is untested with h2 as we do not propose a switch when a body is there.

Am 07.12.2015 um 19:50 schrieb Plüm, Rüdiger, Vodafone Group <ruediger.pluem@vodafone.com>:
 
 
Von: William A Rowe Jr [mailto:wrowe@rowe-clan.net] 
Gesendet: Montag, 7. Dezember 2015 17:39
An: httpd <dev@httpd.apache.org>
Betreff: Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
 
https://tools.ietf.org/html/rfc7230#section-6.7 makes things more interesting, it calls out
that 101-continue and the request body read precedes the 101-switching protocols.  Not sure
who decided that would be a good idea, sigh... but mod_ssl TLS upgrade has these reversed
for several good reasons including the intent to encrypt the request body if present and simple
economics of processing.
I think that handling upgrade advertisement and alerting must be in post read req, bypassing
all request hooks until the 101-continue is presented, any small request body read and set
aside for the http input brigade, and 101-switching protocols is presented.  This allows
the request to still be processed for tls-style upgrades, or discarded for relevant protocols.
How do we handle this today if the client just sends a request body and not an Expect header?
Do we set it already aside before answering with a 101?
Regards
Rüdiger



Mime
View raw message