2011-11-06 12 views
7

Estoy escribiendo un servidor proxy HTTP y me di cuenta de que muchos clientes usan el encabezado "Conexión: Keep-Alive" para mantener una conexión persistente. ¿Es posible que el cliente envíe otra solicitud HTTP antes de que el servidor procese la primera?¿Puede un cliente HTTP persistente enviar más de una solicitud a la vez?

Por ejemplo, el cliente envía "GET/HTTP/1.1" pero antes de que el servidor tenga la posibilidad de responder, el cliente envía "GET /favicon.ico HTTP/1.1". ¿Es eso posible? ¿O el cliente hará una pausa para la respuesta antes de enviar la segunda solicitud?

Además, cuando se usa una conexión persistente, ¿es seguro asumir que todas las solicitudes a través de esa conexión tendrán el mismo encabezado "Host:"?

+2

[HTTP pipelining] (http://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_proxies), que es diferente de las conexiones persistentes simplemente – Flexo

Respuesta

4

Sí, es posible que el cliente canalice las solicitudes. (Ver http://en.wikipedia.org/wiki/HTTP_pipelining).

Convirtiendo su última pregunta en torno ... no sería seguro para un cliente suponer que las solicitudes a múltiples hosts serían atendidas por una única canalización. Puede que no haya especificaciones que aborden directamente su pregunta en el encabezado Host: pero es seguro que serán lo mismo.

+0

No entiendo por qué "no sería seguro para un cliente asumir que las solicitudes a múltiples hosts serían atendidas por una única canalización ". ¡Es la elección del cliente usar una única tubería! –

+0

Gracias, no sabía sobre el término "canalización de HTTP". Estoy escribiendo el servidor, no el cliente, así que quiero manejar cualquier quark extraño que el cliente me arroje. Entonces, ¿estás diciendo que debería tratar de manejar el caso de que una conexión persistente intente conectarse a un host diferente? – Yifan

+0

Sí, lo digo, aunque supongo que pocos o ningún navegador se comporta de esa manera hoy. –

1

En cuanto a la primera pregunta:

¿Es posible que el cliente envía otra solicitud HTTP antes de que el servidor procesa la primera?

Creo que sí, puede ser posible (quizás estoy equivocado, recordé haber leído eso hace un par de años, la respuesta definitiva está en las especificaciones del protocolo HTTP). Pero no entiendo por qué estás preguntando. Además, el cliente puede abrir varias conexiones TCP a la vez en el mismo servidor HTTP. Y, por supuesto, tienes muchos clientes simultáneos.

Sobre la segunda pregunta

Además, al utilizar una conexión persistente, es seguro asumir todas las solicitudes de conexión que tendrá el mismo "Anfitrión:" cabecera?

Creo que suele ser el caso, pero no voy a asumir eso para estar seguro. Me podría imaginar que algunos clientes HTTP inteligentes, reconociendo que dos URL con Host diferentes: los encabezados comparten la misma IP, podrían reutilizar la misma conexión.

Pero no entiendo por qué lo preguntas. Se han inventado conexiones HTTP persistentes para minimizar las conexiones TCP que son costosas, y las dos preguntas que hace son un punto extremo sobre eso. Quizás pocos clientes HTTP están haciendo lo que describes hoy.

Y debe ser estricto con lo que envía (conformidad con el estándar w.r.t), pero flexible en lo que acepta recibir.

+0

Pregunto porque estoy intentando escribir un servidor proxy HTTP genérico y quiero manejar cualquier cosa que un cliente me arroje. – Yifan

+0

Pero no veo por qué eso le importa. Un proxy HTTP robusto supondría un sí a Q1 y un no a Q2. –

5

"Además, cuando se usa una conexión persistente, ¿es seguro asumir que todas las solicitudes a través de esa conexión tendrán el mismo encabezado" Host: "?"

Yo no lo creo, ver HTTPbis P1, Section 2.2:

Los beneficiarios deben tener en cuenta todos los mensajes en una conexión en forma aislada; Debido a que HTTP es un protocolo sin estado, no puede suponerse que dos solicitudes en la misma conexión son del mismo cliente o comparten otros atributos comunes.En particular, los intermediarios pueden mezclar solicitudes de diferentes clientes en una sola conexión de servidor. Tenga en cuenta que algunas extensiones HTTP existentes (por ejemplo, [RFC4559]) infringen este requisito, lo que puede causar problemas de interoperabilidad y seguridad.

Cuestiones relacionadas