> -----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
