httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject [BUG]: "UPDATE: CGI outputting Location: redirect not working" on FreeBSD (fwd)
Date Thu, 06 Feb 1997 01:08:07 GMT


How about this as a solution:

Index: http_protocol.c
RCS file: /export/home/cvs/apache/src/http_protocol.c,v
retrieving revision 1.12
diff -u -r1.12 http_protocol.c
--- http_protocol.c     1997/01/31 22:26:42     1.12
+++ http_protocol.c     1997/02/06 01:06:29
@@ -1186,7 +1186,7 @@
 int should_client_block (request_rec *r)
-    if (is_HTTP_ERROR(r->status))
+    if (is_HTTP_ERROR(r->status) || is_HTTP_REDIRECT(r->status))
        return 0;
     if (!r->read_chunked && (r->remaining <= 0))


---------- Forwarded message ----------
Date: Wed Feb 5 15:39:15 1997
Subject: [BUG]: "UPDATE: CGI outputting Location: redirect not working" on FreeBSD

Operating system: FreeBSD, version: 2.2
Version of Apache Used: 1.2b6
Extra Modules used: just what comes with apache
URL exhibiting problem: 

This is an update to a previously submitted
bug report (see below). What seems to be
happening is that when the CGI returns a
redirect (via Location:), the new CGI gets
executed with the old "Content-Length" header
from the original POST CGI. But the content
has all already been read. I'm not an HTTP
expert but it seems like the second CGI should
not "inherit" the Content-Length header from
the first CGI.

The relevant function is setup_client_block().
This function is erroneously resetting the field
r->remaining back to its original, non-zero value.

Hope this helps.


A POST to my CGI never returns anything back
to the browser, even though the CGI has run
and exited.

What's happening is that the CGI is returning
a redirect by outputing a Location: header.
The mod_cgi module reads this and tries to
execute the new CGI by calling the function
internal_redirect_handler(). This eventually
loops back to cgi_handler(), which calls the
function should_client_block() in order to
determine if it needs to copy POST arguments.

It seems that for reasons I don't understand
the should_client_block() function is, on this
the second pass through cgi_handler(), erroneously
returning true, which causes cgi_handler() to try
to read the POST arguments AGAIN, even though
they've already been read. The browser has nothing
left to send, so things just hang until the
"send args" timeout.

Maybe the problem is that should_client_block() 
needs to make sure that the CGI is a POST or




View raw message