Chaque demande Web envoie-t-elle des cookies au navigateur?

198

Chaque demande Web envoie-t-elle les cookies du navigateur?

Je ne parle pas de pages vues, mais d'une demande d'image, de .jsfichier, etc.

Mise à jour Si une page Web contient 50 éléments, c'est 50 demandes. Pourquoi enverrait-il le MÊME cookie (s) pour chaque demande, ne cache-t-il pas ou sait-il qu'il l'a déjà?

cookies mrblah
la source
8
Je ne pense pas que la mise en cache soit possible dans cette situation - nous parlons du navigateur envoyant des données au serveur, et non l'inverse. Vous ne pouvez pas dire avec certitude que le serveur "l'a déjà" après que l'utilisateur a envoyé une demande, pour de nombreuses raisons. Il peut y avoir un grand nombre de serveurs qui ne se parlent pas; le serveur peut ne pas vouloir (ou avoir de la place) se souvenir de quoi que ce soit concernant les requêtes précédentes - HTTP est censé être sans état; chaque demande doit être indépendante des autres. Pour cette raison, les cookies, comme les informations d'authentification, doivent être envoyés avec chaque demande.
Ian Clelland
J'ai mentionné pourquoi la mise en cache n'a pas de sens pour les cookies dans une mise à jour de ma réponse: stackoverflow.com/a/1336178/102960
igorsantos07

Réponses:

198

Oui, tant que l'URL demandée se trouve dans le même domaine et chemin défini dans le cookie (et toutes les autres restrictions - sécurisé, httponly, non expiré, etc.), le cookie sera envoyé pour chaque demande.

Ian Clelland
la source
103
C'est d'ailleurs pour cette raison que les outils de vitesse de page comme Google Page Speed ​​ou Yahoo YSlow recommandent de diffuser du contenu statique à partir d'un domaine séparé et sans cookie.
ceejayoz
J'ai mentionné la
diffusion de
Est-il vrai que le navigateur envoie des cookies Site2 lorsqu'il y a une redirection HTTP de Site1 vers Site2?
Zeigeist
92

Comme d'autres l'ont dit, si les restrictions relatives à l'hôte, au chemin, etc. du cookie sont respectées, il sera envoyé 50 fois.

Mais vous avez également demandé pourquoi: car les cookies sont une fonctionnalité HTTP et HTTP est sans état. HTTP est conçu pour fonctionner sans que le serveur ne stocke aucun état entre les requêtes.

En fait, le serveur n'a pas de moyen solide de reconnaître quel utilisateur envoie une demande donnée; il pourrait y avoir mille utilisateurs derrière un seul proxy web (et donc une adresse IP). Si les cookies n'étaient pas envoyés à chaque demande, le serveur n'aurait aucun moyen de savoir quel utilisateur demande quelle que soit la ressource.

Enfin, le navigateur n'a aucune idée si le serveur a besoin des cookies ou non, il sait simplement que le serveur lui a demandé d'envoyer le cookie pour toute demande à foo.com, donc il le fait. Parfois, les images en ont besoin (par exemple, générées dynamiquement par utilisateur), parfois non, mais le navigateur ne peut pas le dire.

derobert
la source
1
Est-ce vrai avec HTTP 1.1, qui est un schéma de multiplexage? C'est-à-dire que les demandes sont regroupées dans une seule connexion TCP. Bien sûr, chaque demande est reçue avec une copie du cookie attaché. Mais si le souci est beaucoup de duplication de transmission, HTTP 1.1 est en mesure d'optimiser. Bien que je ne sais pas si c'est le cas ...
Chris Noe
1
Ensuite, le problème devient "à quelles demandes le navigateur avait-il l'intention de joindre les cookies?" Le serveur définit la politique avec le cookie, pour décider à quels domaines et à quels chemins d'URL le cookie doit être renvoyé, mais il l'oublie. Vous auriez besoin d'un moyen de spécifier que certaines demandes de connexion contenaient le cookie, et d'autres non. Cela n'existe certainement pas dans HTTP / 1.1, sauf en les incluant explicitement dans chaque demande. Honnêtement, une meilleure solution (compatible avec les normes) pour réduire la bande passante serait le codage de contenu gzip côté client, mais personne ne le prend encore en charge.
Ian Clelland
1
@Ian Clelland: Le client doit envoyer le premier message, donc il ne sait pas ce que le serveur enverrait pour Accept-Encoding (si les serveurs envoyaient ce champ, HTTP / 1.1 §14.3 dit que c'est un en-tête de demande). Et le problème est qu'il peut varier selon l'URL même sur le même serveur et peut changer au fil du temps, donc le faire fonctionner ne serait pas anodin.
derobert
1
@Chris: Non, keepalive enregistre simplement la surcharge de configuration / démontage de la connexion TCP, c'est tout. Des en-têtes complets sont toujours envoyés pour chaque demande. Cependant, le pipelining (envoyer plusieurs demandes sans attendre la réponse) peut grandement aider. HTTP / 1.1 §8.1 donne des détails.
derobert
21

Oui. Chaque demande envoie des cookies appartenant au même domaine. Ils ne sont pas mis en cache car HTTP est sans état, ce qui signifie que chaque demande doit être suffisante pour que le serveur sache quoi en faire. Supposons que vous ayez des images qui ne sont accessibles que par certains utilisateurs; vous devez envoyer votre cookie d'authentification avec chacune de ces 50 demandes, afin que le serveur sache que c'est vous et pas quelqu'un d'autre, ou un invité, parmi le pool de demandes qu'il reçoit.

Cela dit, les cookies peuvent ne pas être envoyés compte tenu des autres restrictions mentionnées dans les autres réponses, telles que le paramètre HTTPS, le chemin ou le domaine. Surtout là, une chose importante à noter: les cookies ne sont pas partagés entre les domaines. Cela aide à réduire la taille des appels HTTP pour les fichiers statiques, tels que les images et les scripts que vous avez mentionnés.
Exemple: vous avez 4 cookies sur www.stackoverflow.com; si vous en faites la demande www.stackoverflow.com/images/logo.png, tous ces 4 cookies seront envoyés.
Cependant, si vous demandez stackoverflow.com/images/logo.png(notez le changement de sous-domaine) ou images.stackoverflow.com/logo.png, ces 4 cookies ne seront pas présents - mais peut-être ceux liés à ces domaines.

Vous pouvez en savoir plus sur les cookies et les images demandant, par exemple, sur ce blog StackOverflow .

igorsantos07
la source
10

Non. Toutes les demandes n'envoient pas les cookies. Cela dépend de la configuration des cookies et de la connexion client-serveur.

Par exemple, si l' secureoption de votre cookie est définie sur, trueil doit être transmis via une connexion HTTPS sécurisée. Signifie que lorsque vous voyez ce site Web avec le protocole HTTP, ces cookies ne seront pas envoyés par les navigateurs car l'indicateur sécurisé est vrai.

Iman Sedighi
la source
7

Le cookie a une propriété "path". Si "path = /", la réponse est Oui.

neoedmund
la source
Oui, vous pouvez organiser la structure de votre site / application de sorte que toutes les URL nécessitant des cookies soient minces /app/ou similaires - cela conserverait la portabilité sans avoir besoin de sous-domaines séparés pour éliminer les frais généraux redondants. Vous pouvez également abandonner Google Analytics, désormais inutile. J'ai vu des en-têtes de cookies depuis si longtemps que je me demande si ma grand-mère les tricotait.
Jake
7

3 ans se sont écoulés

Il y a une autre raison pour laquelle un navigateur n'envoie pas de cookies. Vous pouvez ajouter un crossOriginattribut à votre <script>balise et la valeur à "anonymous". Cela empêchera l'envoi de cookies au serveur de destination. 99,9% du temps, vos javascripts sont des fichiers statiques et vous ne générez pas ce code js sur la base des cookies de la requête. Si vous avez 1 Ko de cookies et que vous avez 200 ressources sur votre page, votre utilisateur télécharge 200 Ko, ce qui peut prendre un certain temps en 3G et avoir un effet nul sur la page de résultats. Visitez l' attribut HTML: crossorigin pour référence.

gilm
la source
S'il vous plaît, expliquez.
Jake
4
@Jake, vous pouvez ajouter un attribut crossOrigin à votre balise <script> et la valeur à "anonyme". Cela empêchera l'envoi de cookies au serveur de destination. 99,9% du temps, vos javascripts sont des fichiers statiques et vous ne générez pas ce code js sur la base des cookies de la requête. Si vous avez 1 Ko de cookies et que vous avez 200 ressources sur votre page, votre utilisateur télécharge 200 Ko, ce qui peut prendre un certain temps en 3G et avoir un effet nul sur la page de résultats. Visitez developer.mozilla.org/en-US/docs/Web/HTML/… pour référence.
gilm
4

Je sais que c'est un vieux fil. Mais je viens de remarquer que la plupart des navigateurs n'enverront pas de cookies pour un domaine si vous ajoutez un point de fin. Par exemple http://example.com., ne recevra pas les cookies définis pour .example.com. Apache d'autre part les traite comme le même hôte. Je trouve cela utile pour rendre le suivi entre domaines plus difficile pour les ressources externes que j'inclus, mais vous pouvez également l'utiliser pour des raisons de performances. Notez que cela freine la validation des httpscertificats. J'ai exécuté quelques tests à l'aide de navigateurs et de mes propres appareils. Le hack fonctionne sur presque tous les navigateurs à l'exception de safari (mobile et ordinateur), qui inclura des cookies dans la demande.

Gellweiler
la source
Comment cela "rend-il le suivi inter-domaines plus difficile pour les ressources externes que j'inclus"? Parlez-vous de Farcebook Like et de ces widgets - que nous connaissons pour suivre la navigation des utilisateurs accidentellement encore connectés?
Jake
Oui. Cela rendra la tâche plus difficile, car la plupart des navigateurs n'enverront pas les cookies. Par exemple, si vous incluez quelque chose sur google.com et que vous êtes connecté à google, google ne peut pas associer les deux demandes. Cela n'est pas garanti, certains navigateurs ont quand même envoyé les cookies et il existe des méthodes moins fiables et moins utilisées pour identifier les utilisateurs (comme les adresses IP) qui fonctionneront toujours. Le plus gros inconvénient est que vous ne pouvez pas utiliser HTTPS, ce qui le rend aujourd'hui inutile.
Gellweiler
0

La réponse courte est oui. Les lignes ci-dessous proviennent de la documentation JS

Les cookies étaient autrefois utilisés pour le stockage général côté client. Bien que cela était légitime alors qu'ils étaient le seul moyen de stocker des données sur le client, il est désormais recommandé d'utiliser des API de stockage modernes. Les cookies sont envoyés à chaque demande, ce qui peut détériorer les performances (en particulier pour les connexions de données mobiles).

Yashwin Munsadwala
la source