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.pl...@vodafone.com>: > > > > Von: William A Rowe Jr [mailto:wr...@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
