http - solucion - response error code
¿Qué códigos de estado HTTP usa realmente al desarrollar aplicaciones web? (12)
La especificación HTTP / 1.1 ( RFC2616 ) define una serie de códigos de estado que puede devolver el servidor HTTP para señalar ciertas condiciones. Algunos de esos códigos pueden ser utilizados por aplicaciones web (y frameworks). ¿Cuáles de esos códigos son los más útiles en la práctica en respuestas tanto clásicas como asincrónicas (XHR), en qué situaciones usa cada una de ellas?
Qué códigos deben evitarse, ej. ¿deberían las aplicaciones interferir con el rango del código 5xx? ¿Cuáles son sus convenciones al devolver códigos HTTP en servicios web REST? ¿Alguna vez usa redireccionamientos que no sean 302?
500 Internal Server Error se devuelve en Aida / Web cuando su aplicación web genera una excepción. Debido a que esta es una aplicación de Smalltalk, se genera una ventana de excepción en el servidor (si la ejecuta de forma permanente) mientras que el usuario obtuvo 500 y una pila corta.
En el servidor, puede abrir un depurador completo y tratar de resolver el problema, mientras el servidor continúa ejecutándose, por supuesto. Otra cosa agradable es que la ventana de excepción con pila completa te está esperando hasta que llegues.
Conclusión: ¡500 es una bendición, no una pesadilla!
Aquí están los códigos de respuesta más comunes, según mi experiencia:
Los códigos de respuesta en el rango 1xx-2xx normalmente son manejados automáticamente por el servidor web subyacente (es decir, Apache, IIS), por lo que no tiene que preocuparse por ellos.
Los códigos 301 y 302 se usan normalmente para redireccionamientos, y 304 se usa mucho cuando el cliente o el proxy ya contiene una copia válida de los datos y no necesita una nueva versión del servidor (consulte el RFC para obtener detalles sobre cómo funciona esto exactamente). )
El código 400 generalmente se usa para indicar que el cliente envió datos malos o inesperados que causaron un problema en el servidor.
El código 403 es para realizar la autenticación, que de nuevo se maneja de manera algo automática por la configuración del servidor.
El código 404 es el código de error para una página no encontrada.
El código 500 indica una condición de error en el servidor que no es necesariamente causada por los datos enviados por el cliente. Por ejemplo, fallas de conexión a la base de datos, errores de programación u otras excepciones no controladas.
El código 502 se ve típicamente si está realizando un proxy desde un servidor web (como Apache) a un servidor de aplicaciones (como Tomcat) en el servidor, y la conexión no se puede realizar en el servidor de la aplicación.
Para llamadas asíncronas (es decir, respuestas AJAX / JSON), generalmente es más seguro devolver siempre una respuesta 200. Incluso si hubo un error en el servidor al procesar la solicitud, es mejor incluir el error en el objeto JSON y dejar que el cliente lo maneje de esa manera. La razón es que no todos los navegadores web permiten el acceso al cuerpo de respuesta para códigos de respuesta que no sean 200.
En Aida / Web framework usamos solo
- 200 Ok
- 302 Redirigir
- 404 No encontrado
- Error interno de servidor 500
He tenido pesadillas sobre el número 500.
Tiendo a usar el Método 405 No Permitido cuando alguien intenta OBTENER una URL que solo puede ser PUBLICADA. ¿Alguien más lo hace de la misma manera?
303 Ver Otro es imprescindible para PRG , que deberías utilizar ahora si aún no lo estás.
Básicamente los uso todos, según corresponda. La especificación en sí define cada código y las circunstancias en que deberían ser utilizados.
Al construir una aplicación web RESTful, no recomiendo escoger y elegir códigos de estado, y restringirme a un subconjunto del rango completo. Es decir, a menos que uno esté creando una aplicación web para un cliente HTTP específico, en cuyo caso uno realmente no está creando una aplicación web, sino que está creando una aplicación para ese cliente específico.
En mi empresa, tenemos algunos clientes de Flex. No pueden manejar códigos de estado distintos a 200, por lo que les pedimos que envíen un parámetro especial con sus solicitudes, lo que indica a nuestros servidores que siempre envíen un 200, incluso cuando no sea la respuesta adecuada.
418: soy una tetera
De http://www.ietf.org/rfc/rfc2324.txt Protocolo de control de pote de café Hyper Text (HTCPCP / 1.0)
No te olvides de 503 - Servicio no disponible. Este es esencial para el tiempo de inactividad del sitio. Especialmente en lo que respecta a los motores de búsqueda.
Digamos que está bajando el sitio por unas horas para realizar trabajos de mantenimiento o actualización. Al dirigir todas las solicitudes a una página amigable que devuelve un código 503, le dice a las arañas que "vuelvan a intentarlo más tarde".
Si simplemente muestra una página "Temporalmente Abajo" pero todavía muestra 200 OK, la araña puede indexar sus páginas de error o, lo que es peor, reemplazar la indexación existente con este "nuevo" contenido.
Esto podría afectar seriamente sus clasificaciones de SEO, especialmente si es un sitio grande y popular.
Estoy usando 409 en lugar de 400 para datos de usuario incorrectos (es decir, envío de formularios).
Las especificaciones para 409 continúan sobre conflictos de versión, pero menciona que la información sobre cómo solucionar el problema debe enviarse en la respuesta. Perfecto para correo electrónico mal formado o mensajes de contraseña incorrecta.
400 solo resuelve problemas de sintaxis que para mí suena como que la solicitud simplemente no tiene sentido en absoluto en lugar de fallar algunas expresiones regulares.
Uso webmachine, que automágicamente genera códigos de error adecuados. Pero hay casos en que necesito proporcionar el mío. He encontrado que es útil para el desarrollo y la depuración devolver 666 en esos casos, por lo que puedo decir fácilmente cuáles provienen de mi código y cuáles de webmachine. Además, me sale una risita cuando se trata. Debe recordar cambiar esto antes de la implementación real.
Los que estoy usando (que podría encontrar con un grep ''Status:'' rápido grep ''Status:'' todos modos):
- 200 Recuperó con éxito un recurso sin afectarlo
- 201 Enviado siempre que un envío de formulario pone algo importante en la base de datos (publicación en el foro, cuenta de usuario, etc.), creando un nuevo recurso
- 204 Enviado con el cuerpo vacío, por ejemplo después de un BORRAR
- 304 HTTP caching. He encontrado que este es muy difícil de corregir, ya que tiene que dar cuenta de los usuarios que cambian la configuración de visualización, etc. La mejor idea que he encontrado para eso es usar un hash de las preferencias del usuario como ETag. No ayuda que la mayoría de los navegadores tengan un comportamiento impredecible e incoherente aquí ...
- 400 Se utiliza para envíos de formularios incorrectos que no superan la verificación de validación.
- 403 Se usa cuando alguien está en algún lugar donde no debería estar (aunque trato de evitarlo al no mostrar enlaces a cosas a las que los usuarios no deberían acceder).
- 404 Además de los servidores web normales, los utilizo cuando la URL contiene números de ID no válidos. Supongo que sería una buena idea verificar en este caso si existe una identificación válida más alta y enviar un 410 en su lugar ...
- 429 Cuando las peticiones de los usuarios son demasiado frecuentes
- 500 : tiendo a poner estos en los bloques catch {} donde la única opción es darse por vencido, para asegurarse de que se envíe algo significativo al navegador.
Me doy cuenta de que podría salirse con la suya simplemente dejando que el servidor envíe "200" para todo, pero ahorran mucho dolor cuando los usuarios ven (o causan) errores y no le informan sobre ellos. Ya tengo funciones para mostrar mensajes de acceso denegado, etc., así que no es mucho trabajo agregarlos de todos modos.