httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c
Date Wed, 03 Aug 2016 17:29:51 GMT
On Wed, Aug 3, 2016 at 12:19 PM, William A Rowe Jr <wrowe@rowe-clan.net>
wrote:

> On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett <minfrin@sharp.fm> wrote:
>
>> On 18 Jul 2016, at 6:32 PM, William A Rowe Jr <wrowe@rowe-clan.net>
>> wrote:
>>
>> > Worse, in http 2.4, the first two registered methods collide with BREW
>> and WHEN. That said, the 'fix', if we wanted to resolve it, is to use
>> M_INVALID +3 as the first value.
>>
>> I’m not seeing the problem here, there is no expectation of binary
>> compatibility between httpd v2.4 and trunk. Can you confirm what you’re
>> trying to achieve by removing this?
>>
>
> The first problem in dropping BREW and WHEN is that any provider against
> 2.6/3.0 can register these methods itself. The ftp module, for example,
> registers some 50 commands. These exceed the number of AllowMethod
> limitable methods. The right answer for future-proofing would be to either
> have providers register only extension methods they want to use, and/or
> increase that from a 64-bit word to 128-bit index of allow methods (say
> 16 chars for simplicity's sake).
>
> The problem here is that BREW would collide with the first registered
> method,
> and WHEN would collide with the second registered method, wherein two
> method
> identifiers would share the same ID and same AllowMethod rule. That's bad
> (if these two were implemented by a provider).
>
> httpd 2.4 requires binary compatibility, if we don't want these to
> collide, we must
> assign the first registered method to 1+WHEN. The IDs can't change on
> 2.4.x,
> but the first number allocated for a registered method certainly can.
>
> In all, this was a cleanup-[de?]optimization of convoluted trunk logic, I
> don't see
> the point in backporting such noise to a maintenance branch. Only trunk,
> moving forwards, aught to be 'optimal' in terms of legibility and
> performance.
>
> So it wasn't my intent to backport. If we want to avoid BREW/WHEN
> collisions
> we should simply fix that.
>

Never mind, BREW and WHEN were simply not registered at all in 2.4/2.2.

I am going to suggest we register the hash lookup value for HEAD though as
a one-line patch to 2.2/2.4, aliased to M_GET just as on trunk.

Mime
View raw message