Re: Apache2 SAPI behaviour regarding PATH_TRANSLATED

Sascha Schumann <sascha@schumann.cx> wrote: > > Right, but it's also the case that adding more ini entries sorely for > > certain backwards compatibilities could make it harder for us to write > > portable scripts and could definitely generate a disgusting number of > > bogus PR's as in the case of register_globals. Therefore any attempts of > > such mitigation will not likely end up with a certain success after all. > > It's my understanding in this case that you can write > portable scripts even with the ini switch in place. Thus, > there is no point in saying that scripting becomes harder due > to such a change. Yes, I could indeed write portable scripts with a trivial hack, where what I mean by "a portable script" is the script designed to behave as nearly the same way as possible no matter what the ini settings would be. But IMHO scripting would become harder at this point because it should ask the users for such an elaboration then. As I can imagine quite a few cases where scripting guys are not responsible for server administration, the fluxous PATH_INFO / PATH_TRANSLATED behaviour that can be swayed by an ini entry will lead them into undesired confusion. I'd rather believe configuring ini entries and writing scripts belong to different semantics to one another. > > As a bunch of incompatibilities are to be addressed in php5, I suppose we > > don't always have to bother bringing light to such compromise. We need to > > progress somehow. > > But we are making progress. We correct PHP's behaviour while > enabling administrators to maintain legacy applications. > It's simply not always an option to fix the app, so let's > empower those who want to upgrade PHP without breaking > existing apps. My point is that as long as they'll have to suffer from the upgrade hell due to a number of inevitable BC breaks anyway, we should be allowed to drop some choices for simplicity. Moriyoshi