CGI module redirect defaults to 302 -- why?

[Mott.Jeff]

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?

 

[Mumia W.]

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: