Welcome to WebmasterWorld Guest from 188.8.131.52
If the 301 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, since this might change the conditions under which the request was issued.
Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate.
The requested resource MUST be accessed through the proxy given by the Location field.
Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
The client SHOULD NOT repeat the request without modifications.
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity.
The request could not be completed due to a conflict with the current state of the resource.
Conflicts are most likely to occur in response to a PUT request.
The server refuses to accept the request without a defined Content- Length.
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
The expectation given in an Expect request-header field could not be met by this server
The server does not support the functionality required to fulfill the request.
RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
Many pre-HTTP/1.1 user agents do not understand the 303 status.