Re: CGI module redirect defaults to 302 -- why?
- From: "Mumia W." <paduille.4061.mumia.w+nospam@xxxxxxxxxxxxx>
- Date: Sun, 29 Apr 2007 20:02:24 GMT
On 04/29/2007 11:37 AM, Mott.Jeff@xxxxxxxxx wrote:
If the 302 status code is received in response to a request
other than GET or HEAD, the
user agent MUST NOT automatically redirect the request unless
it can be confirmed by the
user.
-- HTTP/1.1
For a CGI program that was requested from a POST form, the 302 message
seems to not be what I would want. But 303:
The response to the request can be found under a different URI
and SHOULD be retrieved
using a GET method on that resource. This method exists
primarily to allow the output of a
POST-activated script to redirect the user agent to a selected
resource. The new URI is not a
substitute reference for the originally requested resource.
HTTP/1.1
303 seems to be designed *exactly* for redirecting the browser after a CGI program has run. Why then does the CGI module return a 302 response by default?
CGI forms probably respond to GET requests at least as often as they respond to POST requests. Anyway, you are the programmer; you can specify a different status code if you want to.
Also, if you continue reading that section (§10.3.4 of RFC2616), you see this:
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
.
- References:
- CGI module redirect defaults to 302 -- why?
- From: Mott . Jeff
- CGI module redirect defaults to 302 -- why?
- Prev by Date: FAQ 4.56 What happens if I add or remove keys from a hash while iterating over it?
- Next by Date: Re: Correlating Data from same .csv, line by line
- Previous by thread: CGI module redirect defaults to 302 -- why?
- Next by thread: I find the perl syntax easier than python
- Index(es):
Relevant Pages
|
|
