> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Sent: dinsdag 8 december 2015 13:22
> To: dev@httpd.apache.org
> Subject: Re: Upgrade Summary
>
>
> > Am 08.12.2015 um 12:40 schrieb Bert Huijben <b...@qqmail.nl>:
> >> -----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
> >>>> [...]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.
>
> It does. We are only talking about upgrade.
>
> > 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.
>
> Again, your easiest choice is a direct h2c connection. The second easiest
is
> an initial OPTIONS * request without *request* body. The response may
> have
> any body length it wants.
>
> The options * will, as I understand it, not trigger any authentication. In
> another mail, you describe that you already send such a request as 1st
thing.
> But you said it has a body. What does that contain, I wonder?
>
> If you can live without that request body, we are all fine and have a
simple
> implementation. If we need to implement upgrades to h2c on some length
> request bodies, I personally do not have the time to do that right away
> among
> all other changes that are being discussed. At least not this week.
>
> So, what is so relevant about the OPTIONS request body, may I ask?
I can't live without that request body. That would just add another request
to my handshake... the thing I'm trying to avoid.
I'm guessing the body of that initial body is something like
[[
<D:options xmlns:D="DAV:">
<D:activity-collection-set />
</D:options>
]]
(content-type text/xml of course)
And this request is mostly handled by mod_dav, and further annotated with
additional headers by mod_dav_svn.
I can't just redesign DAV to optimize for http/2. If we had a timemachine,
we would have made other decisions.
Would have been nice if we knew DELTA/V was never really implemented outside
Subversion. But now we have compatibility guarantees with older Subversion
clients/servers and other implementations that may use some of the features.
Bert
