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)
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?
Stas Bekman wrote:
Mark James wrote:
STDOUT is flushed prior to a fork to exec an external binary (rcs).
I understand the cause. But I hope that you agree with me that this is
an application's problem. If you haven't sent anything to STDOUT yet,
don't flush. And if this is not under your
Mark James wrote:
Stas Bekman wrote:
Mark James wrote:
STDOUT is flushed prior to a fork to exec an external binary (rcs).
I understand the cause. But I hope that you agree with me that this is
an application's problem. If you haven't sent anything to STDOUT yet,
don't flush. And if this is
Stas Bekman wrote:
Since the mod_perl's internal STDOUT buffer isn't mangled if you re-tie
it later, and it'll be always flushed at the end of the request, there
is no *need* to flush on CLOSE. However in order to be consistent with
perl fh close behavior, it probably needs to be changed to
The
difference between mod_cgi and mod_perl is that mod_cgi does not
activate the filter brigade until it has read all the headers.
But in the case of mod_perl, this event is valid only for handlers
which print their own headers, rather than using mod_perl API to set
them. In the generic
Mark James wrote:
I'm having CGI redirect problems mp2 (cvs).
Instead of being redirected to the proper web page, I'm sometimes
getting a 302 Moved page containing a link to the correct URL.
Damn this was a hard bug to track down.
The cause of the problem was my perl code calling flush.pl and
The cause of the problem was my perl code calling flush.pl and
flushing STDOUT at a point prior to it printing the response headers.
Under mp2, flushing STDOUT calls mpxs_output_flush in
xs/Apache/RequestIO/Apache__RequestIO.h, which in turn calls
ap_rflush, which triggers creation of the
Mark James wrote:
Mark James wrote:
I'm having CGI redirect problems mp2 (cvs).
Instead of being redirected to the proper web page, I'm sometimes
getting a 302 Moved page containing a link to the correct URL.
Damn this was a hard bug to track down.
The cause of the problem was my perl code
[EMAIL PROTECTED] wrote:
The cause of the problem was my perl code calling flush.pl and
flushing STDOUT at a point prior to it printing the response headers.
Under mp2, flushing STDOUT calls mpxs_output_flush in
xs/Apache/RequestIO/Apache__RequestIO.h, which in turn calls
ap_rflush, which triggers
Stas Bekman wrote:
Mark James wrote:
The cause of the problem was my perl code calling flush.pl and
flushing STDOUT at a point prior to it printing the response headers.
Hmm, why do you flush?
STDOUT is flushed prior to a fork to exec an external binary (rcs).
The child is closing STDOUT and then
Mark James wrote:
Stas Bekman wrote:
Mark James wrote:
The cause of the problem was my perl code calling flush.pl and
flushing STDOUT at a point prior to it printing the response headers.
Hmm, why do you flush?
STDOUT is flushed prior to a fork to exec an external binary (rcs).
The child is
Stas Bekman wrote:
As I wrote this, I'm actually starting to think that it's Apache who
should ignore the flush bucket if it had seen no other data so far, and
not generate any headers till it actually sees the real data.
And I went to produce a patch in http_filter, I figured that that would
Mark James wrote:
Stas Bekman wrote:
Can you send a short script (removing all the irrelevant bits) that we
can reproduce the problem with?
Made a script that generated the same POST request and same
redirect as the problem code. The problem was not reproduced!
The only difference I can see
Stas Bekman wrote:
Can you send a short script (removing all the irrelevant bits) that we
can reproduce the problem with?
Made a script that generated the same POST request and same
redirect as the problem code. The problem was not reproduced!
The only difference I can see between working POSTs
I'm having CGI redirect problems mp2 (cvs).
Instead of being redirected to the proper web page, I'm sometimes
getting a 302 Moved page containing a link to the correct URL.
Seems to be related to the following code in modperl_cgi.c:
if (location (location[0] == '/') (r-status == 200)) {
How are you telling the server to redirect? You do know it's different
from mp1, right?
In mp2 you need to do:
my $location = 'http://foo.bar.baz';
$r-headers_out-{'Location'} = $location;
# Or use $r-err_headers_out-{'Location'} which you will have
# to do with any other headers you want to
On Thu, 6 Mar 2003, Mark James wrote:
Nick Tonkin wrote:
Now that I think about it, maybe you're using CGI.pm to do your redirect?
If so, maybe the code in CGI.pm has not been correctly updated?
Yes Nick, I'm using CGI.pm version 2.91 (the latest). Its redirect code
sends a Status: 302
Mark James wrote:
I'm having CGI redirect problems mp2 (cvs).
Instead of being redirected to the proper web page, I'm sometimes
getting a 302 Moved page containing a link to the correct URL.
Seems to be related to the following code in modperl_cgi.c:
if (location (location[0] == '/') (r-status
Stas Bekman wrote:
Mark James wrote:
I'm having CGI redirect problems mp2 (cvs).
as the comment just above this line says, that code was copy-n-pasted
from mod_cgi. Can you reproduce the same problem while running a cgi
script?
No, them problem only manifests under mod_perl (2, haven't used 1).
Mark James wrote:
Stas Bekman wrote:
Mark James wrote:
I'm having CGI redirect problems mp2 (cvs).
as the comment just above this line says, that code was copy-n-pasted
from mod_cgi. Can you reproduce the same problem while running a cgi
script?
No, them problem only manifests under
Mark James wrote:
303 See Other is the correct post-POST redirect response:
http://rfc.net/rfc2616.html#s10.3.4
which your first link suggests works in all browsers.
Well, taking a closer look, 303 doesn't work in Netscape 3 or 4.
CGI.pm always returns a 302, though, if necessary, I can
22 matches
Mail list logo
