[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: [mp2] CGI redirects incorrectly handled?
From:       Stas Bekman <stas () stason ! org>
Date:       2003-03-24 23:35:53
[Download RAW message or body]

Mark James wrote:
> Stas Bekman wrote:
> 
>>> So can flushing be held off until either (1) blank line is printed,
>>> (2) the 8k buffer fills, or (3) send_http_header is called?
>>
>>  
>> 1) is relevant only for handler that print headers, rather than set them
>> 2) absolutely not, what if you want to flush data before?
>> 3) send_http_header doesn't exist in Apache2/mod_perl2
> 
> 
> I didn't realise that mp2 doesn't use send_http_header.  That explains
> the appearance of wb->r->content_type in the mp2 code. 

I'm not quite happy yet about the current situation with send_http_header API 
removal. Currently an explicit call to $r->content_type (only in mod_perl 
handlers) turns the headers parsing off, if it was on. Which works fine as a 
replacement for $r->send_http_header. However it's possible that some earlier 
phase calls $r->content_type and the response phase still wants to *print* its 
headers, rather than use API to set them. If that's the case, we are in trouble.

I'll be soon working on providing the API for PerlOptions and other config 
options. And while most of these things are read-only, I'm thinking that I 
might be able to add a read/write accessor for ParseHeaders. So one can turn 
the parsing on and off, disregarding what was the setting in httpd.conf. I 
believe that would be the perfect solution, since it'll give developers a 
total flexibility.

> So is it
> true that if headers are sent using the API then no output filtering
> and transmission occurs until the 8k buffer is either filled or flushed
> (explcitly or after exit)?

That's correct. Though the headers are really sent by the Apache core http 
output filter, once we send the response body.

>> Only in the case that your handler is configured with:
>>
>>   PerlOptions +ParseHeaders
>>
>> *and*
>>
>> it prints headers ala:
>>
>>   print "Content-type: ...."
>>
>> In all other cases where headers are set via the API, e.g. 
>> $r->content_type, $r->headers_out, etc, there is no such a thing as 
>> "the handler has send an empty line signaling the end of sending 
>> headers", because it never sends any headers at all, but uses api to 
>> set them.
> 
> 
> Is +ParseHeaders always indicative of explicit header printing, or
> can it also be set when using the API?  If the former, then yes, if
> +ParseHeaders is set flushing could be held off until a blank line is seen.

See my plan and current situation explanation above.

>> Do we now agree that the event of "end of sending headers" is possible 
>> only in the case explained at the top?
> 
> 
> Yes, the key I was missing is that mp2 no longer uses send_http_header.
> Can you just lock out flushing when nothing has been printed and
> content_type is undefined? (You impliy above that the content_type
> setting is persistent, so the script would have to undef it if necessary.)
> Then all the user script has to do is to make sure any Status header is
> either printed or set via headers_out in the first batch of
> printing/setting code before flush is called (again).

As I suggested earlier, I think the solution is to ignore rflush calls if we 
expect to parse headers and they weren't parsed yet. However if the buffer 
overflows, we have not much choice but to send it out. But I think that this 
will be a satisfactory solution.

Also since close($fh) always flushes in mod_cgi, I think you can get rid of 
the explicit flush for good. Since mod_perl's CLOSE is no-op, it won't cause 
the flush (at least for now).

__________________________________________________________________
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

[prev in list] [next in list] [prev in thread] [next in thread]