httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: Upgrade Summary
Date Tue, 08 Dec 2015 13:01:01 GMT
If so, for 2.4.18 we should probably backport Bill's proposal in
STATUS (r1717816), so that OPTIONS works as in 2.4.16...

On Tue, Dec 8, 2015 at 1:54 PM, Stefan Eissing
<stefan.eissing@greenbytes.de> wrote:
> 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.
>
> //Stefan
>
>> Am 08.12.2015 um 13:46 schrieb Bert Huijben <bert@qqmail.nl>:
>>
>>
>>
>>> -----Original Message-----
>>> From: Stefan Eissing [mailto:stefan.eissing@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 <bert@qqmail.nl>:
>>>>> -----Original Message-----
>>>>> From: Stefan Eissing [mailto:stefan.eissing@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
>

Mime
View raw message