Códigos de Estado HTTP

El servidor ha recibido los headers y el cliente debe proceder a enviar el cuerpo de la solicitud.

El servidor está cambiando protocolos según lo solicitado por el cliente (ej: upgrade a WebSocket).

El servidor ha recibido y está procesando la solicitud, pero aún no hay respuesta disponible (WebDAV).

Se usa para devolver algunos headers antes del mensaje final, permitiendo al navegador precargar recursos.

La solicitud fue exitosa. El significado depende del método HTTP: GET devuelve el recurso, POST devuelve el resultado de la acción.

La solicitud fue exitosa y se creó un nuevo recurso. Típicamente usado como respuesta a solicitudes POST.

La solicitud ha sido aceptada para procesamiento, pero aún no se ha completado. Usado para operaciones asíncronas.

El servidor procesó la solicitud exitosamente pero no devuelve contenido. Respuesta común para operaciones DELETE.

El servidor entrega solo parte del recurso debido a un header Range enviado por el cliente.

Respuesta que transmite información sobre múltiples recursos donde varios códigos de estado podrían ser apropiados (WebDAV).

El recurso se ha movido permanentemente a una nueva URL. Los buscadores actualizarán sus enlaces.

El recurso reside temporalmente en otra URL. El cliente debe seguir usando la URL original para futuras solicitudes.

La respuesta se puede encontrar en otra URL usando GET. Frecuentemente usado después de POST para redirigir a una página de confirmación.

El recurso no ha sido modificado desde la última solicitud. Usado para caché — el cliente puede usar su versión guardada.

El recurso reside temporalmente en otra URL. A diferencia del 302, el método de solicitud no debe cambiar.

El recurso se ha movido permanentemente. A diferencia del 301, el método de solicitud no debe cambiar.

El servidor no puede procesar la solicitud debido a sintaxis mal formada, parámetros inválidos o campos requeridos faltantes.

Se requiere autenticación. El cliente debe proporcionar credenciales válidas (API key, token o login) para acceder.

El servidor entendió la solicitud pero se niega a autorizarla. La autenticación no ayudará — el usuario no tiene permiso.

El recurso solicitado no se encontró en el servidor. La URL puede ser incorrecta o el recurso pudo haber sido eliminado.

El método HTTP usado no es soportado para este recurso. Por ejemplo, usar POST en un endpoint de solo lectura.

El servidor agotó el tiempo de espera. El cliente tardó demasiado en enviar la solicitud completa.

La solicitud entra en conflicto con el estado actual del servidor. Común en control de versiones o al intentar crear un recurso duplicado.

El recurso ya no está disponible y no lo estará de nuevo. A diferencia del 404, esta es una condición permanente.

El cuerpo de la solicitud es más grande de lo que el servidor acepta. Común para límites de carga de archivos.

El tipo de medio del cuerpo de la solicitud no es soportado. Por ejemplo, enviar XML cuando solo se acepta JSON.

El servidor se niega a preparar café porque es, permanentemente, una tetera. Una broma del April Fools' del RFC 2324.

El servidor entiende el contenido pero no puede procesarlo. Usado para errores de validación — la sintaxis es correcta pero los datos son inválidos.

El usuario ha enviado demasiadas solicitudes en un período de tiempo (rate limiting). Revisa el header Retry-After.

El servidor encontró una condición inesperada que le impidió completar la solicitud. Un error genérico del servidor.

El servidor no soporta la funcionalidad requerida. El método puede no ser reconocido.

El servidor, actuando como gateway o proxy, recibió una respuesta inválida del servidor upstream.

El servidor no puede manejar la solicitud temporalmente debido a mantenimiento o sobrecarga. Usualmente temporal.

El servidor, actuando como gateway o proxy, no recibió una respuesta a tiempo del servidor upstream.