Cómo entender el código de estado de una respuesta HTTP
1xx indica que la solicitud ha sido aceptada, pero se requiere procesamiento adicional. Por ejemplo:
100 (continuar)
El cliente debe continuar enviando la solicitud.
101 (Cambiar protocolo)
Es necesario cambiar el protocolo y el servidor notifica al cliente a través del campo de encabezado de respuesta de actualización.
Así funciona WebSocket, introducido en HTML5. Primero, el cliente solicita la URL donde se encuentra el websocket, el servidor devuelve 101 y luego establece una conexión TCP full-duplex. Tenga en cuenta que los campos de encabezado Actualización y Conexión son campos salto por salto y deberá continuar configurándolos al configurar el proxy Websocket en lugar de simplemente reenviar la solicitud.
2xx
El servidor recibió, entendió y aceptó exitosamente la solicitud.
200 (OK)
La solicitud se recibió 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 cumplido y se ha creado un nuevo recurso en función de la solicitud. Normalmente se utiliza para responder a solicitudes POST en un diseño de URL de estilo RESTFul.
202 (Aceptado)
El servidor ha aceptado la solicitud pero aún no la ha procesado.
204 (Sin contenido)
El servidor procesó exitosamente la solicitud pero no necesita devolver ningún contenido físico, y la respuesta 204 NO DEBE contener ningún cuerpo de mensaje. Después de que el navegador reciba esta respuesta, no debería cambiar la vista del documento.
205 (Restablecer contenido)
El servidor procesó exitosamente la solicitud pero no necesita devolver ningún contenido real. La respuesta 205 tiene prohibido contener cualquier cuerpo de mensaje. A diferencia de 204, una respuesta que devuelve este código de estado requiere que el solicitante restablezca la vista del documento. Por ejemplo, si el usuario acaba de enviar un formulario, devolver 205 restablecerá la página para que el usuario pueda completar inmediatamente el siguiente formulario.
206 (contenido parcial)
El protocolo HTTP permite la transmisión fragmentada. Cuando el encabezado de una solicitud contiene un campo de rango, solo se devuelve en la respuesta la parte especificada por el rango. La respuesta debe contener Content-Range para indicar el rango de contenido que se devolverá.
Otros
203 (Información no autorizada)
207 (Estados múltiples)
3xx
Estos tipos Un código de estado indica que el cliente necesita tomar medidas adicionales para completar la solicitud. Normalmente, estos códigos de estado se utilizan para redirecciones, cuyo destino se indica en el campo del encabezado de ubicación de esta respuesta.
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 múltiples URI devueltos en esta respuesta. Si la solicitud no es GET/HEAD, los navegadores normalmente piden al usuario que confirme la redirección.
301 se utiliza a menudo cuando se migra un sitio web, donde el servidor realiza una redirección 301 desde la URL anterior a la nueva URL para que los motores de búsqueda puedan actualizar correctamente la clasificación de la página original y otra información.
302 (Encontrado)
El recurso solicitado ahora responde temporalmente a solicitudes de un URI diferente. Esta respuesta no se puede almacenar en caché a menos que se especifique Cache-Control o Expires. Si la solicitud actual no es HEAD ni GET, el navegador necesita la confirmación del usuario antes de redirigir.
Esto es comprensible ya que los cambios de contexto, por ejemplo, las solicitudes POST no son equivalentes.
303 (Ver Otros)
La respuesta correspondiente a la solicitud actual se puede encontrar en otra 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. Deshabilite el almacenamiento en caché de 303 respuestas.
303 hará que el navegador OBTENGA recursos directamente sin el consentimiento del usuario. Este es el tipo de redireccionamiento más común en aplicaciones web.
304 (Sin modificar)
Si el cliente envía una solicitud GET condicional y la solicitud está permitida, y el contenido del documento (desde el último acceso o según las condiciones solicitadas) no han cambiado. Las respuestas 304 tienen prohibido incluir un cuerpo de mensaje.
La respuesta 304 también es un mecanismo de almacenamiento en caché. Los servidores web suelen almacenar en caché archivos de recursos estáticos, por lo que verás muchas respuestas 304 en el desarrollo web. La respuesta correspondiente dada por el servidor generalmente contiene la Etag utilizada para identificar el ID del recurso, por ejemplo:
ETag: "686897696a7c876b7e"
El cliente establecerá el campo de encabezado si el siguiente vez que accede a la misma URL -None-Match (esta es una condición de solicitud):
If-None-Match: "686897696a7c876b7e"
Antes de que el servidor devuelva el recurso, lo determine si el Etag es el mismo que el proporcionado por el cliente. Si coincide, si coincide, significa que el recurso no ha cambiado y se debe devolver 304.