> -----Original Message----- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 11:55 > To: dev@httpd.apache.org > Subject: Re: Upgrade Summary > > > > Am 08.12.2015 um 11:44 schrieb Yann Ylavic <ylavic....@gmail.com>: > > > > On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing > > <stefan.eiss...@greenbytes.de> wrote: > >> [...] > >> Open: > >> 1. Protocols like Websocket need to take over the 101 sending > themselves in the "switch protocol" phase. (correct, Jacob?). Should we > delegate the sending of the 101 to the protocol switch handler? > >> 2. General handling of request bodies. Options: > >> a setaside in core of up to nnn bytes before switch invocation > >> b do nothing, let protocol switch handler care about it > > > > a. is tempting, where nnn would be the limit above which we don't honor > Upgrade. > > But that could be a default behaviour, i.e. when "Protocols ... http1" > > is finally elected. > > Possibly specific modules would bypass that? > > > >> 3. When to do the upgrade dance: > >> a post_read_request: upgrade precedes authentication > > > > Looks like it can't be RFC compliant, is it? > > I think it will not be, right.
I read the spec as H2c and HTTP/1.1 are equivalent protocols. Handling authentication *after* switching should work just like when not switching. As client I would like to switch as soon as possible, as at that point I can start multiple requests.. potentially with their own auth, using the same or different realms; or even different auth schemes. I don't think we should require all auth to happen on HTTP/1.1. With equivalent protocols we should switch as soon as possible... I don't think servers should be configured as H2c only for authenticated users. Especially if they also allow H2direct. Bert