httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: cvs commit: apache-1.3/src/modules/standard mod_auth.c mod_status.c
Date Sun, 06 Feb 2000 12:42:53 GMT

In article <Pine.LNX.4.10.10002060307550.8462-100000@nebula.lyra.org> you wrote:
> On 5 Feb 2000 rse@hyperreal.org wrote:
>> rse         00/02/05 04:33:17

> [...]
> You've changed the allowed values here(!)
>
> ExtendedStatus used to be able to take "0". However, you changed the
> directive to use a FLAG which is only "on" and "off".  Hmm. Actually, it
> used to be able to take anything.
> 
> While the new code conforms to the documentation, it could mess up
> existing configurations that used "0" or "1" or something.
> 
> Just a yellow flag... I'm -0 on the change.

Yes, I was aware that I've changed the allowed values. 

I thought it is better to do it now than never. IMHO it is harmless
that someone who really used the bogus "ExtendedStatus 0" now has to
adjust his config to use the correct "ExtendedStatus off". Because if we
keep all unclean and inconsistant things just because it could "break"
someones (incorrect) configurations, we would never reach a clean state
and Apache would evolve over time into a totally inconsistant piece of
software.

IMHO one has to carefully distinguish between feature changes which make
things no longer backward compatible and bugfixes or cleanups which make
things not 100% backward compatible. The first one has to definetely
and always avoid in stable series of a software. But IMHO the second is
required, even in stable series like Apache 1.3.x. And I considered the
change to belong to the second type.

But please feel free to back out the change to mod_status.c if you care
more about the 100% backward compatibility point. I've done the change
because I'm personally convinved it is better this way, but I know that
others do not share my opinion on this point, so I accept if you back it
out again.

Yours,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message