httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c
Date Wed, 03 Aug 2016 17:19:47 GMT
On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett <> wrote:

> On 18 Jul 2016, at 6:32 PM, William A Rowe Jr <> 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
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

So it wasn't my intent to backport. If we want to avoid BREW/WHEN collisions
we should simply fix that.

View raw message