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:
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_heade
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 cas
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 flu
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 n
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 control,
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 be
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 c
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
[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
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 c
>
> 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
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
f
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 be
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
Further down modperl_cgi.c has:
else if (location && (r->status == 200)) {
MP_dRCFG;
/* Note that if a script wants to produce its own Redirect
* body, it now has to explicitly *say* "Status: 302"
*/
but it seems that it's being done already by CGI.pm.
Can yo
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 ed
Stas Bekman wrote:
Mark James wrote:
No, them problem only manifests under mod_perl (2, haven't used 1).
Sorry, I'm not following your comment. I've suggested to test with
mod_cgi (under Apache2), since mod_perl mimics mod_cgi's behavior here.
I changed the handler in httpd.conf from perl-script t
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 mod_per
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:
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->
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 "Sta
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 Moved".
Mark
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 t
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)) {
25 matches
Mail list logo