By the way, this submission of the HTTP header also seems to result in
an about 20 second additional delay on the client side -- i.e. if I
request an object which returns the Refresh header, I wait for about 20
seconds, then see the headers flash by as page contents, and then the
refresh occurs. I do not get this extra delay when I simply submit the
refresh as a <meta> header, so this seems to be an artifact of the HTTP
transaction in some way.
Victor Danilchenko wrote:
I seem to be missing something very obvious... I have:
$r->header_out("Refresh"=>"0; URL=$uri\n");
$r->send_http_header;
print "Test redirect => $uri\n";
But when the redirect page gets submitted, the HTTP headers show up
as page contents:
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
1e
Test redirect => /?loopback=1
0
Obviously only the stuff after 'Test redirect' should show up. I am
using Mason, and writing an error handler -- it tries to tell the
browser resubmit a GET request in the event of a Mason failure. It looks
like Mason inserts a blank line to terminate the HTTP header block. is
there any way to counter that, so that the header directives end up in
the header?
Incidentally, the actual Refresh header does work, so maybe my
hypothesis about Mason is off the wall.
Any ideas?
P.S. On a wild shot, does anyone know if the XMLHttpRequest JavaScript
directive generally honors the HTTP Refresh header in Firefox and IE?
