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 [EMAIL PROTECTED] 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:[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]
