¿Cada solicitud web envía cookies al navegador?


198

¿Cada solicitud web envía las cookies del navegador?

No estoy hablando de vistas de página, sino de una solicitud de una imagen, .jsarchivo, etc.

Actualización Si una página web tiene 50 elementos, son 50 solicitudes. ¿Por qué enviaría las MISMAS cookies para cada solicitud, no almacena en caché o sabe que ya lo tiene?


8
No creo que el almacenamiento en caché sea posible en esta situación: estamos hablando de que el navegador envía datos al servidor, no al revés. No puede decir con certeza que el servidor "ya lo tiene" después de que el usuario haya enviado una solicitud, por muchas razones. Puede haber una gran cantidad de servidores que no se comunican entre sí; es posible que el servidor no quiera (o no tenga espacio) para recordar nada sobre solicitudes anteriores: se supone que HTTP no tiene estado; cada solicitud debe ser independiente del resto. Por esta razón, las cookies, como las credenciales de autenticación, deben enviarse con cada solicitud.
Ian Clelland

Mencioné por qué el almacenamiento en caché no tiene sentido para las cookies en una actualización de mi respuesta: stackoverflow.com/a/1336178/102960
igorsantos07

Respuestas:


198

Sí, siempre que la URL solicitada se encuentre dentro del mismo dominio y ruta definidos en la cookie (y todas las demás restricciones: seguro, httponly, no caducado, etc.), la cookie se enviará para cada solicitud.


103
Por cierto, esta es la razón por la cual las herramientas de velocidad de página como Google Page Speed ​​o Yahoo's YSlow recomiendan servir contenido estático desde un dominio separado y libre de cookies.
ceejayoz

Mencioné sobre la publicación de contenido de un dominio separado en mi respuesta actualizada: stackoverflow.com/a/1336178/102960
igorsantos07

¿Es cierto que el navegador envía cookies de Site2 cuando hay una redirección HTTP de Site1 a Site2?
Zeigeist

92

Como otros han dicho, si se cumplen las restricciones de host, ruta, etc. de la cookie, se enviará 50 veces.

Pero también preguntó por qué: porque las cookies son una característica HTTP, y HTTP no tiene estado. HTTP está diseñado para funcionar sin que el servidor almacene ningún estado entre solicitudes.

De hecho, el servidor no tiene una forma sólida de reconocer qué usuario está enviando una solicitud determinada; podría haber mil usuarios detrás de un solo proxy web (y, por lo tanto, una dirección IP). Si no se enviaran las cookies a todas las solicitudes, el servidor no tendría forma de saber qué usuario está solicitando cualquier recurso.

Finalmente, el navegador no tiene idea de si el servidor necesita las cookies o no, solo sabe que el servidor le ordenó enviar la cookie para cualquier solicitud a foo.com, por lo que lo hace. A veces las imágenes las necesitan (por ejemplo, generadas dinámicamente por usuario), a veces no, pero el navegador no puede decirlo.


1
¿Es esto cierto con HTTP 1.1, que es un esquema de multiplexación? Es decir, las solicitudes se agrupan en una única conexión TCP. Por supuesto, cada solicitud se recibe con una copia de la cookie adjunta. Pero si la preocupación es mucha duplicación de transmisión, HTTP 1.1 está en condiciones de optimizar. Aunque no sé si realmente lo hace ...
Chris Noe

1
Luego, el problema se convierte en "¿a qué solicitudes pretendía el navegador adjuntar las cookies?" El servidor establece la política con la cookie, para decidir qué dominios y qué rutas de URL debe enviar la cookie, pero luego la olvida. Necesitaría una forma de especificar que ciertas solicitudes en la conexión tenían la cookie, y otras no. Eso definitivamente no existe en HTTP / 1.1, excepto al incluirlos explícitamente en cada solicitud. Honestamente, una mejor solución (compatible con los estándares) para reducir el ancho de banda sería la codificación de contenido gzip del lado del cliente, pero nadie lo admite todavía.
Ian Clelland el

1
@Ian Clelland: el cliente tiene que enviar el primer mensaje, por lo que no sabe qué enviaría el servidor para Accept-Encoding (si los servidores enviaran ese campo, HTTP / 1.1 §14.3 dice que es un encabezado de solicitud). Y el problema es que puede variar según la URL, incluso en el mismo servidor, y puede cambiar con el tiempo, por lo que hacer que funcione no sería trivial.
derobert

1
@Chris: No, keepalive solo guarda la configuración de conexión TCP / sobrecarga de desmontaje, eso es todo. Los encabezados completos aún se envían para cada solicitud. Sin embargo, la canalización (envío de múltiples solicitudes sin esperar la respuesta) puede ser de gran ayuda. HTTP / 1.1 §8.1 da detalles.
derobert

21

Si. Cada solicitud envía las cookies que pertenecen al mismo dominio. No se almacenan en caché ya que HTTP no tiene estado, lo que significa que cada solicitud debe ser suficiente para que el servidor descubra qué hacer con ella. Supongamos que tiene imágenes a las que solo pueden acceder ciertos usuarios; usted debe enviar la cookie de autenticación con cada una de esas 50 solicitudes, por lo que el servidor sabe que es usted y no otra persona, o un invitado, entre el grupo de peticiones que se está haciendo.

Dicho esto, es posible que las cookies no se envíen debido a otras restricciones mencionadas en las otras respuestas, como la configuración de HTTPS, la ruta o el dominio. Especialmente allí, algo importante a tener en cuenta: las cookies no se comparten entre dominios. Eso ayuda a reducir el tamaño de las llamadas HTTP para archivos estáticos, como las imágenes y los scripts que mencionó.
Ejemplo: tiene 4 cookies en www.stackoverflow.com; si realiza una solicitud www.stackoverflow.com/images/logo.png, se enviarán todas esas 4 cookies.
Sin embargo, si solicita stackoverflow.com/images/logo.png(observe el cambio de subdominio) o images.stackoverflow.com/logo.png, esas 4 cookies no estarán presentes, pero tal vez las relacionadas con estos dominios sí lo estarán.

Puede leer más sobre las cookies y las imágenes que solicitan, por ejemplo, en esta publicación de blog de StackOverflow .


10

No. No todas las solicitudes envían las cookies. Depende de la configuración de las cookies y la conexión cliente-servidor.

Por ejemplo, si la secureopción de su cookie está configurada en, trueentonces debe transmitirse a través de una conexión HTTPS segura. Significa que cuando ve ese sitio web con protocolo HTTP, estas cookies no serán enviadas por los navegadores ya que el indicador de seguridad es verdadero.


7

Cookie tiene una propiedad de "ruta". Si "ruta = /", la respuesta es Sí.


Sí, podría organizar la estructura de su sitio / aplicación de modo que todas las URL que requieran cookies sean /app/delgadas o similares, conservaría la portabilidad sin necesidad de subdominios separados para eliminar la sobrecarga redundante. O podría deshacerse del ahora inútil Google Analytics para empezar. He visto encabezados de cookies tanto tiempo que me pregunto si mi abuela los estaba tejiendo.
Jake

7

Han pasado 3 años

Hay otra razón por la cual un navegador no enviaría cookies. Puede agregar un crossOriginatributo a su <script>etiqueta y el valor a "anonymous". Esto evitará que se envíen cookies al servidor de destino. El 99.9% de las veces, sus javascripts son archivos estáticos y no genera ese código js en función de las cookies de la solicitud. Si tiene 1KB de cookies y tiene 200 recursos en su página, entonces su usuario está cargando 200KB, y eso podría llevar algún tiempo en 3G y no tendrá ningún efecto en la página de resultados. Visite el atributo HTML: crossorigin para referencia.


Por favor explique.
Jake

44
@Jake puede agregar un atributo crossOrigin a su etiqueta <script> y el valor a "anónimo". Esto evitará que se envíen cookies al servidor de destino. El 99.9% de las veces, sus javascripts son archivos estáticos y no genera ese código js en función de las cookies de la solicitud. Si tiene 1KB de cookies y tiene 200 recursos en su página, entonces su usuario está cargando 200KB, y eso podría llevar algún tiempo en 3G y no tendrá ningún efecto en la página de resultados. Visite developer.mozilla.org/en-US/docs/Web/HTML/… como referencia.
Gil

4

Sé que es un viejo tema. Pero acabo de notar que la mayoría de los navegadores no enviarán cookies para un dominio si agrega un punto final. Por ejemplo http://example.com., no recibirá cookies configuradas para .example.com. Apache, por otro lado, los trata como el mismo host. Considero que esto es útil para hacer que el seguimiento entre dominios sea más difícil para los recursos externos que incluyo, pero también podría usarlo por razones de rendimiento. Tenga en cuenta que esto frena la validación de los httpscertificados. He realizado algunas pruebas con navegadores y mis propios dispositivos. El hack funciona en casi todos los navegadores, excepto para safari (móvil y de escritorio), que incluirá cookies en la solicitud.


¿Cómo "hace que el seguimiento entre dominios sea más difícil para los recursos externos que incluyo"? ¿Estás hablando de Farcebook Like y esos widgets, que sabemos que rastrean la navegación de usuarios que aún están conectados accidentalmente?
Jake

Si. Hará que sea más difícil, porque la mayoría de los navegadores no enviarán las cookies. Entonces, si incluye algo de google.com, por ejemplo, y ha iniciado sesión en google, google no puede vincular las dos solicitudes. Esto no está garantizado, algunos navegadores envían las cookies de todos modos y hay métodos menos confiables y menos utilizados para identificar a los usuarios (como las direcciones IP) que aún funcionarán. El mayor inconveniente es que no puedes usar HTTPS, lo que lo hace inútil hoy en día.
Gellweiler

0

La respuesta corta es sí. Las siguientes líneas son de la documentación de JS

Las cookies se usaron alguna vez para el almacenamiento general del lado del cliente. Si bien esto era legítimo cuando eran la única forma de almacenar datos en el cliente, ahora se recomienda utilizar API de almacenamiento modernas. Las cookies se envían con cada solicitud, por lo que pueden empeorar el rendimiento (especialmente para las conexiones de datos móviles).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.