On Wed, Apr 04, 2007 at 10:34:31PM +0100, Stuart Children wrote: > Behaviour *has already been broken* from 2.0.x to 2.2.x - I've given > evidence of this. Our work systems heavily rely on the 2.0 behaviour. > Maybe someone else would like to repeat my tests - it's possible > it's not as simple as I think. Checking the 1.3.x behaviour would be > interesting too.
The original code did only override >= 400 responses, but was broken as described in PR 20183. That was changed to override all >= 300 responses as what looks like a mis-guided attempt to fix PR 22951, which was probably really just PR 20183 in disguise: http://svn.apache.org/viewvc?view=rev&revision=102069 the original bug, PR 20183, was later fixed: http://svn.apache.org/viewvc?view=rev&revision=102935 but I confess to missing the preceding 400->300 change at the time. That leads to what is in trunk/2.2. I agree that the intended behaviour of the original code was intuitively correct, only >= 400 errors should be overriden, and adding configuration foo to try to maintain "compatibility" is adding complexity to cover up a screw-up. Nobody actually *wants* 3xx errors to be overrided here, it makes no sense. joe
