On Wed, Aug 3, 2016 at 12:19 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett <minf...@sharp.fm> wrote: > >> On 18 Jul 2016, at 6:32 PM, William A Rowe Jr <wr...@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.
