httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: Upgrade Summary
Date Tue, 08 Dec 2015 12:54:00 GMT
I see. Delta-V goodies.

My proposal therefore is:
- keep the upgrade/protocol switch mechanism as is for the 2.4.18 release
- make the agreed upon changes, including TLS upgrade and small content h2c upgrades for the
next release

Since the mechanism is already out with 2.4.17, I see no sense in delaying 2.4.18 at this
point and rather give us time to change it later, so it works for everyone.


> Am 08.12.2015 um 13:46 schrieb Bert Huijben <>:
>> -----Original Message-----
>> From: Stefan Eissing []
>> Sent: dinsdag 8 december 2015 13:22
>> To:
>> Subject: Re: Upgrade Summary
>>> Am 08.12.2015 um 12:40 schrieb Bert Huijben <>:
>>>> -----Original Message-----
>>>> From: Stefan Eissing []
>>>> Sent: dinsdag 8 december 2015 11:55
>>>> To:
>>>> 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

View raw message