On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett <[email protected]> wrote:
> On 18 Jul 2016, at 6:32 PM, William A Rowe Jr <[email protected]> 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.
