Moreover if you look at mod_cgi.c:818, if the script's name starts with 'nph-' it'll cheat at internally remove all the protocol filters which mess with headers letting the script do its own thing.
ugh
The only way mod_perl users can send unparsed headers is by calling:
$r->assbackwards(1);
in their code (as kindly mentioned by Geoff a few months ago).
:)
The problem is that this doesn't work for registry scripts striving to be compatible with mod_cgi, i.e. run unmodified.
Therefore I thought of two posible solutions:
1) Introduce a new option:
PerlOptions +NonParseHeaders
which will do just that, call: $r->assbackwards(1) at the beginning of the response phase.
sure. just remember that that only supresses outgoing headers - it doesn't do anything to incoming headers or make the outgoing ones invisible. I'm never sure exactly what nph scripts do, but if there is more to the mod_cgi implementation than supressing outgoing headers we probably need to evaluate exactly what it is first.
2) An alternative solution is to mess with RegistryCooker to match /npn-/ and call $r->assbackwards(1) on behalf of the script.
nah
The first solution closely matches mp1, by giving users control over the naming of the scripts and even handlers.
The second solution matches 1:1 mod_cgi, which hardcodes 'nph-' condition.
this looks truly awful, and I'm inclined to not support it, so long as we give users some way to do nph scripts.
Which solution do you think is the best?
Also I'm not hardwired on 'PerlOptions +NonParseHeaders' so other names are welcome if you prefer the first option.
sounds fine to me.
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
