Re: Describing current practice for 301 and 302

Paul Hoffman:
>
>>+      Note: When automatically redirecting a POST request after
>>+      receiving a 301 status code, some existing user agents will
>>+      change the method of the request to GET.
>
>When you say "will change the method of the request to GET", do you mean
>"will send the same request again, except change the POST method to a GET
>method"?

I guess they will also delete the body of the POST request when
changing the method to GET, though I have not done experiments to
confirm this.  What about this note, which better leaves things
undefined:

+      Note: When automatically redirecting a POST request after
+      receiving a 301 status code, some existing user agents will
+      change it into a GET request.

>If so, why on earth would they do that?

Historical reasons, I believe.  A very old version of the HTTP
specification could be interpreted as requiring a change to GET on
redirection.

> And, more importantly, is it worth
>noting if it doesn't make much sense?

It does make some limited sense for the 302 code, as is shown by the
introduction of the 303 code in the 1.1 draft.  But whether or not is
makes sense is orthogonal to whether it is worth noting.

It is worth noting because most user agents in use now change the POST
to a GET.  Thus, there is a discrepancy between current practice and
the 1.0 informational definition.  It is important to warn about such
discrepancies in the 1.0 document.

>--Paul Hoffman
>--Internet Mail Consortium

Koen.

Received on Wednesday, 31 January 1996 15:13:31 UTC