www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Drukman <...@gamespot.com>
Subject mod_cgi/978: mod_cgi incorrectly returns 302 when parsing headers
Date Thu, 07 Aug 1997 19:20:05 GMT

>Number:         978
>Category:       mod_cgi
>Synopsis:       mod_cgi incorrectly returns 302 when parsing headers
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    apache (Apache HTTP Project)
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Thu Aug  7 12:20:04 1997
>Originator:     jsd@gamespot.com
>Release:        1.2.1
all platforms i have tested (sgi, freebsd, solaris)
the http1.1 spec clearly states (in section 10.3.4) that redirects after
POST methods should use the 303 See Other return code.  but mod_cgi spits
out 302 when it parses the headers of your cgi script regardless of the
request type.  technically this is incorrect behavior and could be considered
an apache bug.

it hasn't really mattered up to now because all browsers i've seen treated
302's like 303's
in this case.  unfortunately the new version of Internet Explorer (*spit*)
has decided to get all technical on us.  if it sees a 302 in response to a
POST it will pop up a dialog asking the user if they really want to accept
the redirect - this is fine, it's what the spec says should happen.
unfortunately, it doesn't properly redirect afterwards.  even worse, all
the netscape versions i have tried don't understand 303's at all!  they give
an alert saying "document contains no data".
write a cgi that simply spits out
Location: http://www.apache.org/

and hit it with POST and GET from various sources.
most browsers will redirect without complaints.
technically they are doing the wrong thing...
i realize that you guys hate to work around buggy browser behavior but if
mod_cgi could determine the user agent and spit out 302 or 303 accordingly
that would be best.  or at least provide some configurable way to control
what return codes are generated...

and technically, returning 302 to a POST is DEFINITELY an apache bug..

View raw message