ajax - successful - response error code
¿El encabezado vacío "esperar" significa algo? (1)
Muchas bibliotecas incluyen Expect: 100-continue en todas las solicitudes HTTP 1.1 POST y PUT de forma predeterminada.
Tengo la intención de reducir la latencia percibida eliminando el mecanismo 100-continue en el lado del cliente en aquellas solicitudes para las cuales sé que el gasto de enviar datos de inmediato es menor que esperar un viaje de ida y vuelta para 100-continuar, es decir, en solicitudes cortas.
Por supuesto, todavía quiero todas las otras características excelentes de HTTP 1.1, por lo tanto, solo deseo matar a Expect: 100-continue header. Tengo dos opciones:
- eliminar el encabezado esperado por completo, o
- enviar encabezado de espera vacío,
Expect:/r/n
¿Alguna vez hay alguna diferencia entre los dos?
¿Algún software que podría romperse por uno u otro?
Nada debería romperse si elimina el encabezado Expect , pero sé que Microsoft IIS ha tenido problemas con 100 Continue en el pasado. Por ejemplo, IIS5 siempre envía 100 respuestas continuas . Por lo tanto, me pregunto si al menos algunos de los usos que se le pueden dar a las bibliotecas podrían ser un comportamiento similar en los servidores.
Muchas bibliotecas parecen configurar este encabezado y luego no manejan 100 Continue correctamente - por ejemplo, comienzan a enviar el cuerpo de la solicitud inmediatamente sin esperar un 100 Continue y luego no manejan el hecho de que el servidor puede enviar un código de error HTTP antes han terminado de enviar el cuerpo de la solicitud (la primera parte está OK, es la segunda parte la que está rota, ver más adelante en mi respuesta). Esto me lleva a creer que algunos autores acaban de copiarlo de otra parte sin entender completamente las sutilezas .
No veo ningún motivo para incluir un encabezado Expect blanco; si no va a incluir 100-continue (o alguna otra cláusula de Expect ), omita el encabezado por completo. La única razón para incluirlo sería trabajar con servidores web rotos, pero no conozco ninguno que se comporte de esta manera.
Finalmente, si solo busca reducir las latencias de ida y vuelta, me parece que no sería realmente inconsistente con el RFC simplemente comenzar a transmitir el cuerpo de la solicitud de inmediato. Se supone que no debes esperar indefinidamente para enviar el cuerpo de la solicitud (según el RFC ), por lo que te estás comportando de acuerdo con las especificaciones; solo es tu tiempo de espera antes de enviar de todos modos es cero.
Debe tener en cuenta que los servidores tienen la libertad de no enviar la respuesta 100 Continue si ya han recibido parte del cuerpo de la solicitud, por lo que debe manejar los servidores que envían 100 Continue , aquellos que no envían nada y esperan la solicitud completa. aquellos que envían inmediatamente cualquier código de error HTTP (que puede ser 417, pero más probablemente un código genérico 4xx). De esta forma, sus solicitudes cortas no deberían tener ningún costo adicional (aparte del encabezado Expect ), pero no tendrá que esperar a las 100 Continue . Por supuesto, para que este enfoque funcione, tendrá que hacer las cosas de manera que le permita interrumpir la solicitud tan pronto como el servidor devuelva un código de error (por ejemplo, IO no bloqueante con poll() o select() ).
Hacer las cosas de esta manera podría ayudar a mantener su código más consistente entre las solicitudes pequeñas y grandes al tiempo que se reduce la latencia. La desventaja es que tal vez no sea lo que los autores de RFC tenían en mente, incluso si no viola explícitamente ninguno de los requisitos. Además, podría complicar más el código posterior si aún no está haciendo IO sin bloqueo o similar.