El recurso objetivo ha sido asignado a una nueva URI permanente y cualquier referencia futura a este recurso debería usar una de las URIs incluidas.
Los clientes con capacidades de edición de enlaces deberían automáticamente re-enlazar las referencias a la URI de solicitud efectiva a una o más de las nuevas referencias enviadas por el servidor, cuando sea posible.
El servidor DEBERÍA generar un campo de encabezado Location en la respuesta que contenga una referencia URI preferida para la nueva URI permanente. El agente de usuario PUEDE usar el valor del campo Location para redirección automática. El contenido de respuesta del servidor usualmente contiene una nota hipertexto corta con un hipervínculo a la(s) nueva(s) URI(s).
Nota: Por razones históricas, un agente de usuario PUEDE cambiar el método de solicitud de POST a GET para la solicitud posterior. Si este comportamiento no es deseado, se puede usar el código de estado 307 Temporary Redirect en su lugar.
Una respuesta 301 es cacheable por defecto; es decir, a menos que se indique lo contrario por la definición del método o controles de caché explícitos1.
- 1 Calculating Heuristic Freshness RFC7234 Section 4.2.2
- Source: RFC7231 Section 6.4.2
Referencias por lenguaje
- .NET HTTP Status Enum
HttpStatusCode.MovedPermanently - Rust HTTP Status Constant
http::StatusCode::MOVED_PERMANENTLY - Rails HTTP Status Symbol
:moved_permanently - Go HTTP Status Constant
http.StatusMovedPermanently - Symfony HTTP Status Constant
Response::HTTP_MOVED_PERMANENTLY - Python2 HTTP Status Constant
httplib.MOVED_PERMANENTLY - Python3+ HTTP Status Constant
http.client.MOVED_PERMANENTLY - Python3.5+ HTTP Status Constant
http.HTTPStatus.MOVED_PERMANENTLY