Re: [mp2] non-parsed headers registry scripts

> 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