[EMAIL PROTECTED] wrote:
stas 2003/03/08 01:15:16

  Modified:    lib/Apache compat.pm
               lib/ModPerl Code.pm
               src/modules/perl mod_perl.c modperl_filter.c
               xs/Apache/RequestRec Apache__RequestRec.h
               .        Changes
  Log:
  When PerlOptions +ParseHeaders is an effect, the CGI headers parsing
  won't be done if any *mod_perl* handler, from the header_parser phase
  and upto and including the response phase, sets $r->content_type.
  (similar behavior to mp1's send_http_header()

I'm still trying to figure out what's the best way to handle the functionality of mp1's send_http_header() without breaking things. My previous attempt to rely on whether r->content_type is set or not, has failed, because the default mime handler sets r->content_type for file extenstions it knows about.


The problem is that I'm trying to solve is for scripts, running from directory/location configured with PerlOptions +ParseHeaders, that
don't want their headers to be parsed need a way to flag it (that's exactly what send_http_header() does in mp 1.0, but we don't have it 2.0).


So the current solution works like this: If any phase before and including the response phase, sets $r->content_type, the cgi header parsing will be skipped.
This logic can be a problem, if we have a pre-response handler that sets $r->content_type, but the response handler prints raw headers.


I see no other way to implement this (from the user point of view), other than giving the user the good ol' send_http_header(), which would do absolutely nothing but turning off the cgi header parsing flag. Or we could have a new method (e.g. skip_cgi_header_parser) which is more intuitive.

please comment up if you think that the current solution is inadequate, which I'm afraid will bite us in the future.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to