> -----Original Message-----
> From: Stefan Eissing [mailto:[email protected]]
> Sent: dinsdag 8 december 2015 10:25
> To: [email protected]
> Subject: Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl
> Upgrade tls
>
>
> > Am 08.12.2015 um 01:58 schrieb William A Rowe Jr <wrowe@rowe-
> clan.net>:
> >
> > On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic <[email protected]>
> wrote:
> > On Tue, Dec 8, 2015 at 1:27 AM, William A Rowe Jr <wrowe@rowe-
> clan.net> wrote:
> > > On Mon, Dec 7, 2015 at 6:15 PM, Yann Ylavic <[email protected]>
> wrote:
> > >>
> > >> On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic <[email protected]>
> wrote:
> > >> >
> > >> > the body ought to be
> > >> > set aside for any (relevant) TLS response (which needs the
> > >> > handshake...).
> > >>
> > >> Hmm, no need to set aside, *unless* with must produce a response
> > >> before the entire body (and the handshake) is read.
> > >> But we'd better not Upgrade in this case...
> > >
> > >
> > > Yes, there is a set aside, because the handler will read from the
filter
> > > stack... the handler phase has not yet occurred, and other content
> > > input filters may be inserted to transform the request body.
> > >
> > > The upgrade switch would occur before the request content handler
> > > is invoked, in all cases (post_read_request, or later during fixups
> > > or the very beginning of invoke_handler).
> >
> > But this isn't what the RFC says, right?
> > The body of the first request is never Upgraded, so why would we read
> > it using the Upgraded protocol?
> >
> > How do you mean? The RFC states we must read the request body
> > (following a 100-continue) prior to a 101-switching protocols. AFTER
> > the protocol is switched, we are ready to invoke the handler, which
> > will read the request body (which I suggest we have set aside within
> > the http input filter) and it will write to the output filter stack, but
to
> > a different stack of protocol and network filters.
>
> No, that is not what the RFC says. HTTP/1 switching protocols does not
need
> to happen simultaneously on upstream and downstream. Instead, the server
> switches directly after the 101 response, the client switches after the
last
> byte of the request.
The client can only switch once it has confirmation from the server, that it
is really going to perform the upgrade. If the server doesn't accept the
upgrade it must continue using 1.1.
So it has to stop producing data after that first request and first check if
there is a 101 response before it can pipeline the next request.
In pipelining clients such as serf this makes a huge difference.
At some points during update/checkout we may have tens of requests pipelined
on a single connection... but that process starts a bit after the initial
handshake. I'm trying to be in H2(c) at that point, to avoid opening the
additional connections at that point, which we currently have.
Once the client has the 101 it can switch protocol for both input and output
and start sending the next request. Waiting for the 101 is a full stall.
Bert
