«

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?

On 04/29/2007 11:37 AM, 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.