Chaque demande Web envoie-t-elle des cookies au navigateur?
Chaque demande Web envoie-t-elle les cookies du navigateur?
Je ne parle pas de pages vues, mais d'une demande d'image, .js fichier, etc.
Mise à jour Si une page Web a 50 éléments, cela signifie 50 demandes. Pourquoi enverrait-il le même cookie pour chaque demande, ne cache-t-il pas ou ne sait-il pas qu'il en a déjà un?
Oui, tant que l'URL demandée se trouve dans le même domaine et le même chemin que ceux définis dans le cookie (et dans toutes les autres restrictions - sécurisé, https, non périmé, etc.), le cookie est envoyé pour chaque demande.
Comme d'autres l'ont dit, si les restrictions relatives à l'hôte, au chemin d'accès, etc. du cookie sont respectées, il sera envoyé 50 fois.
Mais vous avez également demandé pourquoi: parce que les cookies sont une fonctionnalité HTTP et que HTTP est sans état. HTTP est conçu pour fonctionner sans que le serveur stocke aucun état entre les demandes.
En fait, le serveur ne dispose pas d’un moyen solide de reconnaître quel utilisateur envoie une requête donnée; il pourrait y avoir un millier d'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 demandait une ressource.
Enfin, le navigateur n'a aucune idée si le serveur a besoin des cookies ou pas, il sait simplement que le serveur lui a demandé d'envoyer le cookie pour toute demande à foo.com, c'est pourquoi 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 savoir.
Oui. Chaque demande envoie les cookies appartenant au même domaine. Elles ne sont pas mises en cache car HTTP est sans état, ce qui signifie que chaque requête doit être suffisante pour que le serveur sache quoi en faire. Disons que vous avez 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, ni un invité, parmi le pool des demandes qu'il reçoit.
Cela dit, il se peut que les cookies ne soient pas envoyés en raison des autres restrictions mentionnées dans les autres réponses, telles que le paramètre HTTPS, le chemin d'accès 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 faites une demande à www.stackoverflow.com/images/logo.png, tous ces 4 cookies seront envoyés.
Toutefois, 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 que ceux liés à ces domaines le seront.
Vous pouvez en savoir plus sur les cookies et les images demandant, par exemple, à ceci Blog de StackOverflow .
ans ont passé
Il y a une autre raison pour laquelle un navigateur n'envoie pas de cookies. Certains codes peuvent utiliser l'attribut crossOrigin de l'objet en anonyme pour empêcher l'envoi de cookies.
Non, chaque demande n'envoie pas les cookies. Cela dépend de la configuration du cookie et de la connexion client-serveur.
Par exemple, si l'option secure de votre cookie est définie sur true, elle doit être transmise via une connexion HTTPS sécurisée. Cela signifie que lorsque vous consultez ce site Web avec le protocole HTTP, ces cookies ne seront pas envoyés par les navigateurs car l'indicateur sécurisé est vrai.
Le cookie a une propriété "chemin". Si "path = /", la réponse est oui.
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 configurés 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 cette validation des freins de https certificats. J'ai effectué quelques tests à l'aide de Browsershots et de mes propres appareils. Le hack fonctionne sur presque tous les navigateurs sauf Safari (mobile et desktop), qui inclura des cookies dans la requête.