httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <r...@imdb.com>
Subject Re: [BUG]: "CGI outputting Location: redirect not working" on FreeBSD (fwd)
Date Thu, 06 Feb 1997 14:20:55 GMT

An alternative solution. I think this is what I considered last month
back when the same problem existed for redirected ErrorDocument handlers
that clean up after a POST request. There's something ugly about relying
on reading/manipulating r->headers_in for this information so late into the
request.

Shouldn't changing the method be enough of a clue to be picked up later.


---------- Forwarded message ----------
Date: Wed, 5 Feb 1997 23:10:49 -0800 (PST)
From: Archie Cobbs <archie@whistle.com>
To: Rob Hartill <robh@imdb.com>
Subject: Re: [BUG]: "CGI outputting Location: redirect not working" on FreeBSD


> We'll look into it.

Thanks. Here's a quick fix patch that fixes the problem for me...

-Archie

Index: mod_cgi.c
===================================================================
RCS file: /cvs/mod/apache/httpd/src/mod_cgi.c,v
retrieving revision 1.1.1.4
diff -c -r1.1.1.4 mod_cgi.c
*** 1.1.1.4	1997/01/31 20:32:22
--- mod_cgi.c	1997/02/06 07:10:15
***************
*** 481,486 ****
--- 481,487 ----
  	    */
  	    r->method = pstrdup(r->pool, "GET");
  	    r->method_number = M_GET;
+ 	    table_unset(r->headers_in, "Content-Length");
  
  	    internal_redirect_handler (location, r);
  	    return OK;


> cheers.
> 
> On Wed, 5 Feb 1997 archie@whistle.com wrote:
> 
> > Submitter: archie@whistle.com
> > Operating system: FreeBSD, version: 
> > Version of Apache Used: 1.2b6
> > Extra Modules used: just what comes with apache
> > URL exhibiting problem: 
> > 
> > Symptoms:
> > --
> > 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
> > something.
> > 
> > --
> > 
> > Backtrace:
> > --
> > 
> > --
> > 
> > 
> 
> _______________________________________________________________________
> Rob Hartill.       Internet Movie Database Ltd.    http://www.imdb.com/
> CGI ? how quaint.
> 

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com



Mime
View raw message