You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/03/08 10:55:13 UTC
do we need send_http_header in mp2? (was Re: cvs commit: modperl-2.0
Changes)
stas@apache.org 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: do we need send_http_header in mp2? (was Re: cvs commit: modperl-2.0
Changes)
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Sun, 9 Mar 2003, Stas Bekman wrote:
>
>
>>I wish Doug would follow up and explain why was it dumped from the 2.0 API in
>>first place.
>
>
> you'll need to ask dev@httpd.apache.org for details, but the jist is that
> filters handle sending headers at the proper time. not sure if the reason
> matters much, the function was removed from the 2.0 server api, so naturally
> it removed from the modperl 2.0 api.
I know why it was removed from the Apache API ;) mod_perl is probably the only
beast that can allow cgi scripts to use Apache API to send headers, rather
than via plain print. Therefore I don't think Apache people have a need for
this function. That's why I thought that skip_cgi_header_parser is needed to
be in mod_perl API.
>>We also still have $r->send_cgi_header, which Doug suggested to rename
>>$r->cgi_header_parse. You can see it here:
>
>
> cosmetic. the method does not send anything, just parses and inserts into
> headers_out.
Or, you were asking if anybody uses send_cgi_header. Guess what, CGI.pm does.
I've ported CGI.pm to use mp2 API and replaced send_cgi_header, with setting
$r->headers_out. I'll probably remove it from our XS code base and add to
compat.pm.
>>I think we need to have:
>>
>>$r->skip_cgi_header_parser() which will only turn the parsing flag off. And
>>porters will replace:
>>
>>$r->send_http_header;
>>
>>with
>>
>>$r->skip_cgi_header_parser;
>
>
> i'm pretty far out of the loop at the moment, but this doesn't sound
> right. there should be a way to check internally if headers have already
> been sent. for example, if Content-Type exists in r->headers_out. since
> nothing but the server should be inserting that header into the table.
> and such a check should only happen if +ParseHeaders is enabled of course.
That won't quite work. If we try to do that and +ParseHeaders is enabled, in
the code:
$r->content_type('text/plain');
$r->print("foo");
the print() call will try to parse headers, when we don't want it to.
$r->content_type, sets r->content_type (not r->headers_out). However we can't
rely on r->content_type not being set by some earlier phase (which is the case
with the mime handler). And the whole concept of 'headers been sent' makes a
whole different sense in mp2, because they are normally sent much later then
the current code is run, so the response handler phase can't test for
r->headers_out->{Content-Type}
The current solution that I've committed recently is to turn off the
parseheaders flag if any of the *modperl* handlers have called
$r->content_type. However I'm afraid that this can be a problem with
pre-response phase handlers calling
$r->content_type, but the response handler to be a script that prints the
headers. This DWIM may fail. An explicit call to $r->skip_cgi_header_parser
would be a foolproof solution. Please suggest better ideas of you have any.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: do we need send_http_header in mp2? (was Re: cvs commit:
modperl-2.0 Changes)
Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 9 Mar 2003, Stas Bekman wrote:
> I wish Doug would follow up and explain why was it dumped from the 2.0 API in
> first place.
you'll need to ask dev@httpd.apache.org for details, but the jist is that
filters handle sending headers at the proper time. not sure if the reason
matters much, the function was removed from the 2.0 server api, so naturally
it removed from the modperl 2.0 api.
> We also still have $r->send_cgi_header, which Doug suggested to rename
> $r->cgi_header_parse. You can see it here:
cosmetic. the method does not send anything, just parses and inserts into
headers_out.
> I think we need to have:
>
> $r->skip_cgi_header_parser() which will only turn the parsing flag off. And
> porters will replace:
>
> $r->send_http_header;
>
> with
>
> $r->skip_cgi_header_parser;
i'm pretty far out of the loop at the moment, but this doesn't sound
right. there should be a way to check internally if headers have already
been sent. for example, if Content-Type exists in r->headers_out. since
nothing but the server should be inserting that header into the table.
and such a check should only happen if +ParseHeaders is enabled of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: do we need send_http_header in mp2? (was Re: cvs commit: modperl-2.0
Changes)
Posted by Stas Bekman <st...@stason.org>.
Nick Tonkin wrote:
> On Sat, 8 Mar 2003, Stas Bekman wrote:
>
>
>>stas@apache.org 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.
>
>
> If that's all the functionality it would have, then I sau write it and
> name it so. Better to be clear.
I wish Doug would follow up and explain why was it dumped from the 2.0 API in
first place.
We also still have $r->send_cgi_header, which Doug suggested to rename
$r->cgi_header_parse. You can see it here:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/xs/Apache/Response/Apache__Response.h?rev=1.7&content-type=text/vnd.viewcvs-markup
I think we need to have:
$r->skip_cgi_header_parser() which will only turn the parsing flag off. And
porters will replace:
$r->send_http_header;
with
$r->skip_cgi_header_parser;
and:
$r->send_http_header('text/html');
with:
$r->content_type('text/html');
$r->skip_cgi_header_parser;
and of course Apache::compat will take care of doing it transparently for
those who use it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: do we need send_http_header in mp2? (was Re: cvs commit:
modperl-2.0 Changes)
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Sat, 8 Mar 2003, Stas Bekman wrote:
> stas@apache.org 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.
If that's all the functionality it would have, then I sau write it and
name it so. Better to be clear.
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org