Cómo determinar el estado de funcionamiento del servidor a través del estado HTTP
El primer dígito de todos los códigos de estado representa uno de los cinco estados de la respuesta.
Mensaje 1xx
Este tipo de código de estado indica que la solicitud ha sido aceptada y debe continuar procesándose. Este tipo de respuesta es una respuesta provisional, que contiene solo una línea de estado y alguna información de encabezado de respuesta opcional, y termina con una línea en blanco. Dado que el protocolo HTTP/1.0 no define ningún código de estado 1xx, los servidores no deben enviar respuestas 1xx a dichos clientes excepto bajo ciertas condiciones experimentales.
100 Continuar
El cliente debe continuar enviando solicitudes. Esta respuesta provisional se utiliza para informar al cliente que el servidor ha recibido parte de su solicitud y aún no la ha rechazado. El cliente debe continuar enviando el resto de la solicitud o ignorar esta respuesta si la solicitud está completa. Una vez completada la solicitud, el servidor debe enviar una respuesta final al cliente.
Cambio de protocolo 101
El servidor ha entendido la solicitud del cliente y le notificará a través del encabezado del mensaje de actualización que se ha utilizado un protocolo diferente para completar la solicitud. Después de enviar la última línea vacía de esta respuesta, el servidor cambia al protocolo definido en el encabezado del mensaje de actualización.
Cambie a un nuevo protocolo sólo en circunstancias más favorables. Por ejemplo, puede ser más beneficioso cambiar a una nueva versión de HTTP que a una versión anterior, o cambiar a protocolos sincrónicos y en tiempo real para entregar recursos que aprovechen estas capacidades.
102 Procesamiento
Un código de estado extendido por WebDAV (RFC 2518) para indicar que el procesamiento continuará.
2xx Éxito
Este código de estado indica que el servidor recibió, entendió y aceptó la solicitud con éxito.
200 OK
La solicitud se realizó correctamente y el encabezado de respuesta o el cuerpo de datos requerido por la solicitud se devolverá junto con esta respuesta.
201 Creado
La solicitud se ha satisfecho y se ha creado un nuevo recurso según lo solicitado y su URI se ha devuelto con el encabezado Ubicación. Si el recurso requerido no se puede crear a tiempo, se debe devolver "202 Aceptado".
202 Aceptado
El servidor ha aceptado la solicitud pero aún no la ha procesado. Así como una solicitud puede ser denegada, en última instancia puede o no ejecutarse. En operaciones asincrónicas, nada más conveniente que enviar este código de estado.
El propósito de devolver una respuesta con un código de estado 202 es permitir que el servidor acepte solicitudes de otros procesos (como operaciones específicas basadas en lotes que solo se realizan una vez al día) sin tener que retener el cliente hasta que la operación por lotes se complete por completo. Las respuestas que aceptan solicitudes de procesamiento y devuelven un código de estado 202 deben contener alguna información en la entidad devuelta que indique el estado actual del proceso, así como un puntero a un monitor de estado del proceso o predicción de estado para que el usuario pueda estimar si la operación ha finalizado. terminado.
203 Información no autorizada
El servidor procesó exitosamente la solicitud, pero la metainformación del encabezado de la entidad devuelta no es un conjunto determinado válido en el servidor original, sino que proviene de un servidor local o de terceros. Copia de fuentes del partido. La información actual puede ser un subconjunto o un superconjunto de la versión original. Por ejemplo, contener metadatos para un recurso podría hacer que el servidor de origen conozca un superconjunto de la metainformación. El uso de este código de estado no es obligatorio y la respuesta devolverá 200 OK solo si no se utiliza este código de estado.
204 Sin contenido
El servidor procesó con éxito la solicitud, pero no necesita devolver ningún contenido físico, pero quiere devolver metainformación actualizada. La respuesta puede devolver metainformación nueva o actualizada en forma de encabezados de entidad.
Si dichos encabezados están presentes, deben corresponder a las variables solicitadas.
Si el cliente es un navegador, entonces el navegador del usuario DEBE conservar la página que envió la solicitud sin realizar ningún cambio en la vista del documento, aunque según la especificación, se debe aplicar metainformación nueva o actualizada al Documento de usuario en la vista activa del navegador.
Debido a que una respuesta 204 tiene prohibido contener cualquier cuerpo de mensaje, siempre termina con la primera línea vacía después de los encabezados del mensaje.
205 Restablecer contenido
El servidor procesó exitosamente la solicitud pero no devolvió ningún contenido. Sin embargo, a diferencia de una respuesta 204, una respuesta que devuelve este código de estado requiere que el solicitante restablezca la vista del documento. Esta respuesta se utiliza principalmente para restablecer el formulario inmediatamente después de aceptar la entrada del usuario, de modo que el usuario pueda iniciar fácilmente otra entrada.
Al igual que la respuesta 204, esta respuesta NO DEBE contener ningún cuerpo de mensaje y termina con la primera línea de espacio en blanco después de los encabezados del mensaje.
206 Contenido parcial
El servidor ha procesado con éxito parte de la solicitud GET. Las herramientas de descarga HTTP (como FlashGet o Thunderbolt) utilizan este tipo de respuesta para realizar descargas intermitentes o dividir documentos grandes en varios archivos para descargarlos simultáneamente.
La solicitud debe incluir un encabezado Range para indicar el rango de contenido requerido por el cliente, y puede incluir If-Range como condición de la solicitud.
La respuesta debe contener los siguientes campos de encabezado:
Content-Range se utiliza para indicar el rango de contenido devuelto en esta respuesta en el caso de una descarga multiparte con tipo de contenido multipart/; byteranges, Luego, cada segmento múltiple debe contener un campo Rango de contenido para indicar el contenido de este segmento. El campo Rango en cada segmento de descarga de varias partes indica el rango de contenido de ese segmento de descarga. Si se incluye Content-Length en la respuesta, debe coincidir con el número real de bytes en el rango de contenido que devuelve.
Fecha
ETag y/o Ubicación del contenido si la misma solicitud debería haber devuelto una respuesta 200.
Expira, Cache-Control y/o Vary, si sus valores pueden diferir de otras respuestas anteriores a la misma variable.
Si la solicitud utiliza la verificación de caché fuerte de If-Range, esta respuesta no contendrá otros encabezados de entidad; si la solicitud usa la verificación de caché débil de If-Range, esta respuesta no contendrá otros encabezados de entidad. Esto evita inconsistencias; entre el contenido de la entidad almacenado en caché y la información actualizada del encabezado de la entidad. De lo contrario, esta respuesta debe contener todos los campos de encabezado de entidad que deben devolverse en una respuesta 200.
Los cachés del cliente deben deshabilitar la combinación del contenido devuelto en la respuesta 206 con cualquier contenido previamente almacenado en caché si el encabezado ETag o Last-Modified no coincide exactamente.
Cualquier caché que no admita los encabezados Range y Content-Range tiene prohibido almacenar en caché el contenido devuelto por una respuesta 206.
207 Estado múltiple
Los códigos de estado extendidos por WebDAV (RFC 2518) significan que el cuerpo del mensaje posterior será un mensaje XML y puede contener una serie de códigos de respuesta independientes, dependiendo de el número de subsolicitudes anteriores.
Redireccionamiento 3xx
Este tipo de código de estado indica que el cliente necesita realizar más acciones para completar la solicitud. Normalmente, estos códigos de estado se utilizan para redireccionamientos y la dirección de solicitudes posteriores (el destino de redireccionamiento) se mostrará en el campo de ubicación de esta respuesta.
El navegador del usuario puede enviar automáticamente la solicitud posterior requerida sin intervención del usuario si, y sólo si, el método utilizado por la solicitud posterior es GET o HEAD.
Los clientes deben monitorear automáticamente las redirecciones de bucle infinito (por ejemplo, A-gt;A o A-gt;B-gt;C-gt;A), ya que esto puede hacer que el servidor y el cliente consuman grandes cantidades de recursos innecesarios. La especificación HTTP versión 1.0 recomienda que los navegadores accedan automáticamente a los redireccionamientos no más de cinco veces.
300 Selección múltiple
El recurso solicitado tiene una serie de opciones para devolver información, cada una con su propia dirección específica e información de negociación del controlador del navegador. El usuario o navegador puede elegir una dirección preferida para la redirección.
A menos que se trate de una solicitud HEAD, la respuesta debe contener una entidad que sea una lista de características y direcciones de recursos entre las que el usuario o el navegador pueda elegir la dirección de redireccionamiento más adecuada. El formato de esta entidad está determinado por el formato definido por Content-Type. El navegador puede tomar automáticamente la decisión más adecuada según el formato de la respuesta y las propias capacidades del navegador. Por supuesto, la especificación RFC 2616 no especifica cómo se debe realizar esta selección automática.
Si el servidor tiene un retorno preferido, este URI de retorno debe especificarse en Ubicación; el navegador puede usar este valor de Ubicación como dirección para redireccionamientos automáticos. Además, esta respuesta se puede almacenar en caché a menos que se especifique lo contrario.
301 movido permanentemente
El recurso solicitado se ha movido permanentemente a una nueva ubicación y cualquier referencia futura al mismo debe utilizar uno de los URI devueltos en esta respuesta. Si es posible, los clientes con capacidades de edición de enlaces deben cambiar automáticamente la dirección solicitada a la dirección devuelta por el servidor. A menos que se indique lo contrario, esta respuesta también se puede almacenar en caché.
El nuevo URI permanente debe devolverse en el campo de ubicación de la respuesta. A menos que sea una solicitud HEAD, la entidad de respuesta debe contener un hipervínculo al nuevo URI y una breve descripción.
Por lo tanto, si no se trata de una solicitud GET o HEAD, el navegador no debe redirigir automáticamente a menos que el usuario lo confirme, ya que los términos de la solicitud pueden cambiar en consecuencia.
Nota: Para algunos navegadores que utilizan el protocolo HTTP/1.0, cuando envían una solicitud POST y obtienen una respuesta 301, la siguiente solicitud de redireccionamiento será una solicitud GET.
302 Encontrado
El recurso solicitado ahora responde temporalmente a solicitudes de diferentes URI. Debido a que esta redirección es temporal, el cliente debe continuar enviando solicitudes futuras a la dirección original. Esta respuesta se puede almacenar en caché solo si se especifica en Cache-Control o Expires.
El nuevo URI temporal debe devolverse en el campo Ubicación de la respuesta. A menos que sea una solicitud HEAD, la entidad de respuesta debe contener un hipervínculo al nuevo URI y una breve descripción.
Si no se trata de una solicitud GET o HEAD, el navegador NO DEBE redirigir automáticamente a menos que el usuario lo confirme, ya que los términos de la solicitud pueden cambiar como resultado.
Nota: Aunque las especificaciones RFC 1945 y RFC 2068 no permiten que el cliente cambie el método de la solicitud al redirigir, muchos navegadores existentes tratan la respuesta 302 como una respuesta 303 y usan GET para acceder a la Ubicación. especificado en URI, ignorando el método de solicitud original. Se agregaron los códigos de estado 303 y 307 para dejar claro qué respuesta espera el servidor del cliente.
303 Ver otro
La respuesta a la solicitud actual se puede encontrar en otro URI y el cliente debe usar GET para acceder a ese recurso. Este método se utiliza principalmente para redirigir la salida de una solicitud POST activada por script a un nuevo recurso. Este nuevo URI no es una referencia de reemplazo del recurso original. Además, deshabilite el almacenamiento en caché de las respuestas 303. Por supuesto, la segunda solicitud (redireccionamiento) se puede almacenar en caché.
El nuevo URI debe devolverse en el campo Ubicación de la respuesta.
A menos que se trate de una solicitud HEAD, la entidad de respuesta debe contener un hipervínculo al nuevo URI y una breve descripción.
Nota: Muchos navegadores anteriores a la versión HTTP 1.1 no comprenden correctamente el estado 303. Si le preocupa la interacción con estos navegadores, el código de estado 302 debería ser suficiente, ya que la mayoría de los navegadores manejan respuestas 302 exactamente de la misma manera que la especificación anterior requiere que los clientes manejen respuestas 303.
304 No Modificado
Si el cliente envía una solicitud GET condicional que está permitida, y el contenido del documento no ha cambiado (desde el último acceso o según las condiciones del solicitud), el servidor debe devolver este código de estado. Las respuestas 304 NO DEBEN incluir un cuerpo de mensaje y, por lo tanto, siempre terminan con la primera línea en blanco después de los encabezados del mensaje. .
La respuesta debe contener los siguientes encabezados:
Fecha, a menos que el servidor no tenga reloj. Si los servidores sin relojes siguen estas reglas, entonces los servidores proxy y los clientes pueden agregar ellos mismos campos de fecha a los encabezados de respuesta entrantes (como se especifica en RFC 2068) y el mecanismo de almacenamiento en caché funcionará correctamente.
ETag y/o Content-Location, si la misma solicitud devolverá una respuesta 200.
Expira, Cache-Control y/o Vary, si sus valores pueden diferir de los de otras respuestas anteriores con la misma variable.
Si esta solicitud de respuesta utiliza una validación de caché sólida, esta respuesta NO DEBE contener ningún otro encabezado de entidad; de lo contrario (por ejemplo, una solicitud GET condicional usa una validación de caché débil), esta respuesta NO DEBE contener ningún otro encabezado de entidad; ; esto evita inconsistencias entre el almacenamiento en caché del contenido de la entidad y la actualización de la información del encabezado de la entidad.
Si una respuesta 304 indica que la entidad no está actualmente almacenada en caché, el sistema de almacenamiento en caché DEBE ignorar la respuesta y repetir la solicitud sin restricciones.
Si se recibe una respuesta 304 solicitando una actualización de una entrada de caché, el sistema de almacenamiento en caché debe actualizar la entrada completa para reflejar los valores de todos los campos actualizados en la respuesta.
305 Usando proxy
Se debe acceder al recurso solicitado a través del proxy especificado. El campo de ubicación proporciona información que especifica el URI del proxy a través del cual el destinatario debe enviar repetidamente una solicitud separada para acceder al recurso. Sólo el servidor de origen puede crear una respuesta 305.
Nota: RFC 2068 no establece explícitamente que una respuesta 305 esté destinada a redirigir una única solicitud y solo puede ser creada por el servidor de origen. Ignorar estas restricciones puede tener graves consecuencias para la seguridad.
Agente de conmutación 306
En la última versión de la especificación, el código de estado 306 ya no se utiliza.
Redireccionamiento temporal 307
El recurso solicitado ahora responderá temporalmente a las solicitudes de un URI diferente. Debido a que esta redirección es temporal, el cliente debe continuar enviando solicitudes futuras a la dirección original. Esta respuesta se puede almacenar en caché solo si se especifica en Cache-Control o Expires.
El nuevo URI temporal debe devolverse en el campo Ubicación de la respuesta. A menos que sea una solicitud HEAD, la entidad de respuesta debe contener un hipervínculo al nuevo URI y una breve descripción. Debido a que algunos navegadores no reconocen las respuestas 307, es necesario agregar la información anterior para que los usuarios puedan comprender y solicitar acceso al nuevo URI.
Si no se trata de una solicitud GET o HEAD, el navegador NO DEBE redirigir automáticamente a menos que el usuario lo confirme, ya que los términos de la solicitud pueden cambiar como resultado.