>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: [EMAIL PROTECTED] >Organization: apache >Release: 1.2.1 >Environment: all platforms i have tested (sgi, freebsd, solaris) >Description: 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". >How-To-Repeat: 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... >Fix: 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.. >Audit-Trail: >Unformatted:
