RFC(F) 6265

From RFC.Wiki
Jump to: navigation, search
Groupe de travail sur l'ingénierie Internet (IETF)                         A. Barth
Demande de commentaires: 6265                                           UC Berkeley
Obsolètes: 2965 avril 2011
Catégorie: Standards Track
ISSN: 2070-1721

                    Mécanisme de gestion des états HTTP

Abstrait

   Ce document définit les champs d'en-tête HTTP Cookie et Set-Cookie.
   Ces champs d'en-tête peuvent être utilisés par les serveurs HTTP pour stocker l'état
   (appelés cookies) sur les agents utilisateurs HTTP, permettant aux serveurs de
   session avec état sur le protocole HTTP pour la plupart sans état. Bien que
   les cookies ont de nombreuses infélicités historiques qui dégradent leur sécurité
   et la confidentialité, les champs d'en-tête Cookie et Set-Cookie sont largement utilisés
   sur Internet. Ce document obsolète la RFC 2965.

Statut de ce mémo

   Il s'agit d'un document Internet Standards Track.

   Ce document est un produit de l'Internet Engineering Task Force
   (IETF). Il représente le consensus de la communauté IETF. Il a
   a reçu un examen public et a été approuvé pour publication par le
   Groupe directeur de l'ingénierie Internet (IESG). Plus d'informations sur
   Les normes Internet sont disponibles dans la section 2 de la RFC 5741.

   Informations sur l'état actuel de ce document, tout errata,
   et comment fournir des commentaires à ce sujet
   http://www.rfc-editor.org/info/rfc6265.

Copyright

   Copyright (c) 2011 IETF Trust et les personnes identifiées comme
   auteurs de documents. Tous les droits sont réservés.

   Ce document est soumis au BCP 78 et aux mentions légales de l'IETF Trust.
   Dispositions relatives aux documents de l'IETF
   (http://trustee.ietf.org/license-info) en vigueur à la date de
   publication de ce document. Veuillez consulter ces documents
   soigneusement, car ils décrivent vos droits et restrictions en ce qui concerne
   à ce document. Les composants de code extraits de ce document doivent
   inclure le texte de la licence BSD simplifiée comme décrit dans la section 4.e de
   les dispositions légales de Trust et sont fournis sans garantie
   décrit dans la licence BSD simplifiée.

   Ce document peut contenir des éléments des documents de l'IETF ou de l'IETF
   Contributions publiées ou rendues publiques avant novembre
   10, 2008. La ou les personnes contrôlant le droit d'auteur sur certains de ces
   matériel peut ne pas avoir accordé à l'IETF Trust le droit d'autoriser
   modifications de ce matériel en dehors du processus de normalisation de l'IETF.
   Sans obtenir une licence adéquate de la ou des personnes contrôlant
   le droit d'auteur sur ces documents, ce document ne peut pas être modifié
   en dehors du processus de normalisation de l'IETF, et les travaux dérivés de celui-ci peuvent
   ne pas être créé en dehors du processus de normalisation de l'IETF, sauf pour formater
   pour publication sous forme de RFC ou pour le traduire dans d'autres langues
   que l'anglais.

Table des matières

   1. Introduction ............................................... ..... 3
   2. Conventions ............................................... ...... 4
      2.1. Critères de conformité ....................................... 4
      2.2. Notation de syntaxe ........................................... 5
      2.3. Terminologie ........................................... 5
   3. Aperçu ............................................... ......... 6
      3.1. Exemples ................................................. ..6
   4. Configuration requise pour le serveur ........................................... 8
      4.1. Set-Cookie ............................................... ..8
           4.1.1. Syntaxe .............................................. 8
           4.1.2. Sémantique (non normative) ................... 10
      4.2. Biscuit ................................................. ... 13
           4.2.1. Syntaxe ............................................. 13
           4.2.2. Sémantique .......................................... 13
   5. Configuration requise pour l'agent utilisateur ....................................... 14
      5.1. Algorithmes de sous-composants ................................... 14
           5.1.1. Dates .............................................. 14
           5.1.2. Noms d'hôtes canonisés ........................... 16
           5.1.3. Correspondance de domaine .................................... 16
           5.1.4. Chemins et Match-Path ............................... 16
      5.2. L'en-tête Set-Cookie ..................................... 17
           5.2.1. L'attribut Expires .............................. 19
           5.2.2. L'attribut Max-Age .............................. 20
           5.2.3. L'attribut de domaine ............................... 20
           5.2.4. L'attribut Path ................................. 21
           5.2.5. L'attribut sécurisé ........................... 21
           5.2.6. L'attribut HttpOnly ............................. 21
      5.3. Modèle de stockage ........................................... 21
      5.4. L'en-tête du cookie ......................................... 25
   6. Considérations relatives à la mise en œuvre ............................... 27
      6.1. Limites ................................................. ... 27
      6.2. Interfaces de programmation d'application ........................ 27
      6.3. Dépendance et migration IDNA ............................. 27
   7. Considérations sur la confidentialité ......................................... 28

      7.1. Cookies tiers ....................................... 28
      7.2. Commandes utilisateur ............................................. 28
      7.3. Dates d'expiration .......................................... 29
   8. Considérations de sécurité ....................................... 29
      8.1. Aperçu ................................................. .29
      8.2. Autorité ambiante ......................................... 30
      8.3. Effacer le texte ................................................ 30
      8.4. Identifiants de session ....................................... 31
      8.5. Faible confidentialité ...................................... 32
      8.6. Faible intégrité ........................................... 32
      8.7. Dépendance à l'égard du DNS ........................................... 33
   9. Considérations IANA ............................................ 33
      9.1. Biscuit ................................................. ... 34
      9.2. Set-Cookie ............................................... .34
      9.3. Cookie2 ................................................. ..34
      9.4. Set-Cookie2 ............................................... 34
   10. Références ............................................... ..... 35
      10.1. Références normatives ..................................... 35
      10.2. Références informatives ................................... 35
   Annexe A. Remerciements ....................................... 37

1. Introduction

   Ce document définit les champs d'en-tête HTTP Cookie et Set-Cookie.
   En utilisant le champ d'en-tête Set-Cookie, un serveur HTTP peut transmettre le nom / la valeur
   paires et métadonnées associées (appelées cookies) à un agent utilisateur. Quand
   l'agent utilisateur fait des requêtes ultérieures au serveur, l'utilisateur
   l'agent utilise les métadonnées et d'autres informations pour déterminer s'il faut
   renvoie les paires nom / valeur dans l'en-tête Cookie.

   Bien que simples à première vue, les cookies ont un certain nombre de
   complexités. Par exemple, le serveur indique une étendue pour chaque
   cookie lors de son envoi à l'agent utilisateur. La portée indique la
   durée maximale pendant laquelle l'agent utilisateur doit renvoyer le
   cookie, les serveurs auxquels l'agent utilisateur doit renvoyer le cookie,
   et les schémas d'URI pour lesquels le cookie est applicable.

   Pour des raisons historiques, les cookies contiennent un certain nombre de
   infélicités de la vie privée. Par exemple, un serveur peut indiquer qu'un
   le cookie donné est destiné aux connexions "sécurisées", mais le
   l'attribut n'assure pas l'intégrité en présence d'un actif
   attaquant de réseau. De même, les cookies pour un hôte donné sont partagés
   sur tous les ports de cet hôte, même si l'habituel "même origine"
   "utilisée par les navigateurs Web isole le contenu récupéré via différents
   ports.

   Il existe deux publics pour cette spécification: les développeurs de cookies
   générer des serveurs et des développeurs d'agents utilisateurs consommateurs de cookies.

   Pour maximiser l'interopérabilité avec les agents utilisateurs, les serveurs DEVRAIENT limiter
   eux-mêmes au profil de bonne conduite défini dans la section 4 lorsque
   générer des cookies.

   Les agents utilisateurs DOIVENT mettre en œuvre les règles de traitement les plus libérales définies
   dans la section 5, afin de maximiser l'interopérabilité avec les
   les serveurs qui ne sont pas conformes au profil de bonne conduite défini dans
   Section 4.

   Ce document spécifie la syntaxe et la sémantique de ces en-têtes comme
   ils sont en fait utilisés sur Internet. En particulier, ce document
   ne crée pas de nouvelle syntaxe ou sémantique au-delà de celles utilisées aujourd'hui.
   Les recommandations pour la génération de cookies fournies dans la section 4
   représentent un sous-ensemble préféré du comportement actuel du serveur, et même le
   l'algorithme de traitement des cookies plus libéral fourni dans la section 5 ne
   ne recommande pas toutes les variantes syntaxiques et sémantiques utilisées
   aujourd'hui. Lorsque certains logiciels existants diffèrent des logiciels recommandés
   protocole de manière significative, le document contient une note expliquant
   la différence.

   Avant ce document, il y avait au moins trois descriptions de
   cookies: la soi-disant "spécification de cookie Netscape" [Netscape],
   RFC 2109 [RFC2109] et RFC 2965 [RFC2965]. Cependant, aucun de ces
   les documents décrivent comment les en-têtes Cookie et Set-Cookie sont réellement
   utilisé sur Internet (voir [Kri2001] pour le contexte historique). Dans
   relation avec les spécifications IETF précédentes de la gestion des états HTTP
   mécanismes, ce document demande les actions suivantes:

   1. Modifiez le statut de [RFC2109] en Historique (il a déjà été
       obsolète par [RFC2965]).

   2. Modifiez l'état de [RFC2965] sur Historique.

   3. Indiquez que [RFC2965] a été obsolète par ce document.

   En particulier, en déplaçant la RFC 2965 vers l'historique et en la rendant obsolète, cette
   le document déconseille l'utilisation de l'en-tête Cookie2 et Set-Cookie2
   des champs.

2. Conventions

2.1. Critères de conformité

   Les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "NE DOIT PAS",
   "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "MAI" et "FACULTATIF" dans ce
   document doivent être interprétés comme décrit dans [RFC2119].

   Exigences formulées dans l'impératif dans le cadre d'algorithmes (tels que
   "supprimer tous les premiers caractères de l'espace" ou "retourner faux et annuler ces
   ") doivent être interprétées avec la signification du mot clé
   ("DOIT", "DEVRAIT", "PEUT", etc.) utilisés pour introduire l'algorithme.

   Les exigences de conformité formulées sous forme d'algorithmes ou d'étapes spécifiques peuvent
   être mis en œuvre de quelque manière que ce soit, tant que le résultat final est
   équivalent. En particulier, les algorithmes définis dans ce
   Les spécifications doivent être faciles à comprendre et ne sont pas
   destiné à être performant.

2.2. Notation de syntaxe

   Cette spécification utilise la forme Backus-Naur augmentée (ABNF)
   notation de [RFC5234].

   Les règles de base suivantes sont incluses par référence, comme défini dans
   [RFC5234], Appendice B.1: ALPHA (lettres), CR (retour chariot), CRLF
   (CR LF), CTL (contrôles), DIGIT (décimal 0-9), DQUOTE (guillemet double),
   HEXDIG (hexadécimal 0-9 / AF / af), LF (saut de ligne), NUL (octet nul),
   OCTET (toute séquence de données 8 bits sauf NUL), SP (espace), HTAB
   (onglet horizontal), CHAR (n'importe quel caractère [USASCII]), VCHAR (tout visible
   [USASCII] et WSP (espace blanc).

   La règle OWS (espaces blancs facultatifs) est utilisée lorsque zéro ou plus linéaire
   des caractères d'espacement PEUVENT apparaître:

   OWS = * ([obs-fold] WSP)
                    ; espace "facultatif"
   obs-fold = CRLF

   OWS NE DEVRAIT PAS être produit ou être produit comme un seul SP
   personnage.

2.3. Terminologie

   Les termes agent utilisateur, client, serveur, proxy et serveur d'origine ont
   la même signification que dans la spécification HTTP / 1.1 ([RFC2616], Section
   1.3).

   L'hôte de demande est le nom de l'hôte, tel que connu par l'agent utilisateur,
   à laquelle l'agent utilisateur envoie une requête HTTP ou à partir de laquelle il
   reçoit une réponse HTTP (c'est-à-dire le nom de l'hôte auquel il
   envoyé la requête HTTP correspondante).

   Le terme request-uri est défini dans la section 5.1.2 de la [RFC2616].

   On dit que deux séquences d'octets correspondent à chaque casse
   autres si et seulement s'ils sont équivalents sous le i; ascii-casemap
   classement défini dans [RFC4790].

   Le terme chaîne signifie une séquence d'octets non NUL.

3. Présentation

   Cette section décrit un moyen pour un serveur d'origine d'envoyer l'état
   informations à un agent utilisateur et à l'agent utilisateur de renvoyer le
   état des informations au serveur d'origine.

   Pour stocker l'état, le serveur d'origine inclut un en-tête Set-Cookie dans un
   Réponse HTTP. Dans les demandes suivantes, l'agent utilisateur renvoie un
   En-tête de demande de cookie au serveur d'origine. L'en-tête Cookie
   contient des cookies que l'agent utilisateur a reçus dans le Set-Cookie précédent
   en-têtes. Le serveur d'origine est libre d'ignorer l'en-tête du cookie ou
   utiliser son contenu dans un but défini par l'application.

   Les serveurs d'origine PEUVENT envoyer un en-tête de réponse Set-Cookie avec
   réponse. Les agents utilisateurs PEUVENT ignorer les en-têtes Set-Cookie contenus dans
   réponses avec des codes d'état à 100 niveaux mais DOIVENT traiter Set-Cookie
   en-têtes contenus dans d'autres réponses (y compris les réponses avec 400-
   et codes d'état à 500 niveaux). Un serveur d'origine peut inclure plusieurs
   Champs d'en-tête Set-Cookie dans une seule réponse. La présence d'un
   Un champ d'en-tête Cookie ou Set-Cookie n'empêche pas les caches HTTP
   de stocker et de réutiliser une réponse.

   Les serveurs d'origine NE DEVRAIENT PAS plier plusieurs champs d'en-tête Set-Cookie en
   un seul champ d'en-tête. Le mécanisme habituel pour plier les en-têtes HTTP
   (c.-à-d., comme défini dans [RFC2616]) peut changer la sémantique de
   le champ d'en-tête Set-Cookie car le caractère% x2C (",") est utilisé
   par Set-Cookie d'une manière qui entre en conflit avec un tel pliage.

3.1. Exemples

   En utilisant l'en-tête Set-Cookie, un serveur peut envoyer à l'agent utilisateur un court
   chaîne dans une réponse HTTP que l'agent utilisateur retournera à l'avenir
   Les requêtes HTTP qui sont dans la portée du cookie. Par exemple,
   le serveur peut envoyer à l'agent utilisateur un "identifiant de session" nommé SID
   avec la valeur 31d4d96e407aad42. L'agent utilisateur renvoie ensuite le
   identifiant de session dans les requêtes suivantes.

   == Serveur -> Agent utilisateur ==

   Set-Cookie: SID = 31d4d96e407aad42

   == Agent utilisateur -> Serveur ==

   Cookie: SID = 31d4d96e407aad42

   Le serveur peut modifier la portée par défaut du cookie en utilisant le chemin
   et les attributs de domaine. Par exemple, le serveur peut demander à l'utilisateur
   agent pour renvoyer le cookie à chaque chemin et à chaque sous-domaine de
   example.com.

   == Serveur -> Agent utilisateur ==

   Set-Cookie: SID = 31d4d96e407aad42; Chemin = /; Domaine = exemple.com

   == Agent utilisateur -> Serveur ==

   Cookie: SID = 31d4d96e407aad42

   Comme le montre l'exemple suivant, le serveur peut stocker plusieurs cookies
   à l'agent utilisateur. Par exemple, le serveur peut stocker une session
   identifiant ainsi que la langue préférée de l'utilisateur en renvoyant deux
   Champs d'en-tête Set-Cookie. Notez que le serveur utilise Secure et
   Attributs HttpOnly pour fournir des protections de sécurité supplémentaires pour
   l'identifiant de session le plus sensible (voir Section 4.1.2.)

   == Serveur -> Agent utilisateur ==

   Set-Cookie: SID = 31d4d96e407aad42; Chemin = /; Sécurise; HttpOnly
   Set-Cookie: lang = en-US; Chemin = /; Domaine = exemple.com

   == Agent utilisateur -> Serveur ==

   Cookie: SID = 31d4d96e407aad42; lang = en-US

   Notez que l'en-tête du cookie ci-dessus contient deux cookies, l'un nommé
   SID et un nommé lang. Si le serveur souhaite que l'agent utilisateur
   conserver le cookie sur plusieurs "sessions" (par exemple, agent utilisateur
   redémarre), le serveur peut spécifier une date d'expiration dans Expires
   attribut. Notez que l'agent utilisateur peut supprimer le cookie avant
   la date d'expiration si le magasin de cookies de l'agent utilisateur dépasse sa
   quota ou si l'utilisateur supprime manuellement le cookie du serveur.

   == Serveur -> Agent utilisateur ==

   Set-Cookie: lang = en-US; Expire = mer., 09 juin 2021 10:18:14 GMT

   == Agent utilisateur -> Serveur ==

   Cookie: SID = 31d4d96e407aad42; lang = en-US

   Enfin, pour supprimer un cookie, le serveur renvoie un en-tête Set-Cookie
   avec une date d'expiration dans le passé. Le serveur réussira
   en supprimant le cookie uniquement si le chemin d'accès et l'attribut de domaine
   l'en-tête Set-Cookie correspond aux valeurs utilisées lorsque le cookie a été
   créé.

   == Serveur -> Agent utilisateur ==

   Set-Cookie: lang =; Expire = Dim, 06 Nov 1994 08:49:37 GMT

   == Agent utilisateur -> Serveur ==

   Cookie: SID = 31d4d96e407aad42

4. Configuration requise pour le serveur

   Cette section décrit la syntaxe et la sémantique d'un bon comportement
   profil des en-têtes Cookie et Set-Cookie.

4.1. Set-Cookie

   L'en-tête de réponse HTTP Set-Cookie est utilisé pour envoyer des cookies
   serveur à l'agent utilisateur.

4.1.1. Syntaxe

   De manière informelle, l'en-tête de réponse Set-Cookie contient le nom de l'en-tête
   "Set-Cookie" suivi d'un ":" et d'un cookie. Chaque cookie commence par
   une paire nom-valeur, suivie de zéro ou plusieurs paires attribut-valeur.
   Les serveurs NE DEVRAIENT PAS envoyer d'en-têtes Set-Cookie qui ne sont pas conformes à
   la grammaire suivante:

 set-cookie-header = "Set-Cookie:" SP set-cookie-string
 set-cookie-string = cookie-pair * (";" SP cookie-av)
 cookie-pair = cookie-name "=" cookie-value
 cookie-name = token
 cookie-value = * cookie-octet / (DQUOTE * cookie-octet DQUOTE)
 octet de cookie =% x21 /% x23-2B /% x2D-3A /% x3C-5B /% x5D-7E
                       ; Caractères US-ASCII hors CTL,
                       ; espace DQUOTE, virgule, point-virgule,
                       ; et barre oblique inverse
 token = <token, défini dans [RFC2616], Section 2.2>

 cookie-av = expires-av / max-age-av / domain-av /
                     path-av / secure-av / httponly-av /
                     extension-av
 expires-av = "Expires =" sane-cookie-date
 sane-cookie-date = <rfc1123-date, défini dans [RFC2616], section 3.3.1>
 max-age-av = "Max-Age =" chiffre différent de zéro * CHIFFRE
                       ; En pratique, expires-av et max-age-av
                       ; sont limitées à des dates représentables par le
                       ; agent utilisateur.
 chiffre non nul =% x31-39
                       ; chiffres 1 à 9
 domaine-av = "Domaine =" valeur-domaine
 domaine-valeur = <sous-domaine>
                       ; défini dans [RFC1034], section 3.5, comme
                       ; amélioré par [RFC1123], Section 2.1
 path-av = "Path =" valeur-chemin
 path-value = <tout CHAR sauf CTL ou ";">
 secure-av = "Sécurisé"
 httponly-av = "HttpOnly"
 extension-av = <tout CHAR sauf CTL ou ";">

   Notez que certains des termes grammaticaux ci-dessus des documents de référence
   qui utilisent des notations grammaticales différentes de ce document (qui
   utilise ABNF de [RFC5234]).

   La sémantique de la valeur du cookie n'est pas définie par ce document.

   Pour maximiser la compatibilité avec les agents utilisateurs, les serveurs qui souhaitent
   stocker des données arbitraires dans une valeur de cookie DEVRAIT coder ces données, par exemple
   exemple, en utilisant Base64 [RFC4648].

   Les portions de la chaîne set-cookie produites par le terme cookie-av
   sont appelés attributs. Pour maximiser la compatibilité avec les agents utilisateurs,
   les serveurs NE DEVRAIENT PAS produire deux attributs avec le même nom dans le
   même set-cookie-string. (Voir la section 5.3 pour savoir comment les agents utilisateurs gèrent
   ce cas.)

   Les serveurs NE DEVRAIENT PAS inclure plus d'un champ d'en-tête Set-Cookie dans
   la même réponse avec le même nom de cookie. (Voir la section 5.2 pour
   comment les agents utilisateurs gèrent ce cas.)

   Si un serveur envoie plusieurs réponses contenant des en-têtes Set-Cookie
   simultanément à l'agent utilisateur (par exemple, lors de la communication avec le
   agent utilisateur sur plusieurs sockets), ces réponses créent une «course
   condition "qui peut conduire à un comportement imprévisible.

   REMARQUE: Certains agents utilisateurs existants diffèrent dans leur interprétation de
   années à deux chiffres. Pour éviter les problèmes de compatibilité, les serveurs DEVRAIENT utiliser
   le format de date rfc1123, qui nécessite une année à quatre chiffres.

   REMARQUE: certains agents utilisateurs stockent et traitent les dates dans les cookies au format 32 bits
   Valeurs UNIX time_t. Bogues d'implémentation dans les bibliothèques prenant en charge
   Le traitement time_t sur certains systèmes peut entraîner la
   traiter les dates après l'année 2038 de manière incorrecte.

4.1.2. Sémantique (non normative)

   Cette section décrit la sémantique simplifiée de l'en-tête Set-Cookie.
   Ces sémantiques sont suffisamment détaillées pour être utiles à la compréhension
   les utilisations les plus courantes des cookies par les serveurs. La sémantique complète est
   décrit à la section 5.

   Lorsque l'agent utilisateur reçoit un en-tête Set-Cookie, l'agent utilisateur
   stocke le cookie avec ses attributs. Par la suite, lorsque
   l'agent utilisateur fait une requête HTTP, l'agent utilisateur inclut le
   les cookies applicables et non expirés dans l'en-tête Cookie.

   Si l'agent utilisateur reçoit un nouveau cookie portant le même nom de cookie,
   valeur de domaine et valeur de chemin en tant que cookie qu'il a déjà stocké,
   le cookie existant est supprimé et remplacé par le nouveau cookie.
   Notez que les serveurs peuvent supprimer les cookies en envoyant à l'agent utilisateur un
   nouveau cookie avec un attribut Expires avec une valeur dans le passé.

   Sauf indication contraire des attributs du cookie, le cookie est
   renvoyé uniquement au serveur d'origine (et non, par exemple, à
   sous-domaines), et il expire à la fin de la session en cours (comme
   défini par l'agent utilisateur). Les agents utilisateurs ignorent les cookies non reconnus
   (mais pas le cookie entier).

4.1.2.1. L'attribut Expires

   L'attribut Expires indique la durée de vie maximale du cookie,
   représentée comme la date et l'heure d'expiration du cookie. le
   l'agent utilisateur n'est pas tenu de conserver le cookie jusqu'à ce que le
   la date est passée. En fait, les agents utilisateurs expulsent souvent les cookies en raison de
   pression sur la mémoire ou problèmes de confidentialité.

4.1.2.2. L'attribut Max-Age

   L'attribut Max-Age indique la durée de vie maximale du cookie,
   représenté comme le nombre de secondes jusqu'à l'expiration du cookie. le
   l'agent utilisateur n'est pas tenu de conserver le cookie pour la durée spécifiée
   durée. En fait, les agents utilisateurs expulsent souvent les cookies en raison de la mémoire
   problèmes de pression ou de confidentialité.

      REMARQUE: certains agents utilisateurs existants ne prennent pas en charge Max-Age
      attribut. Agents utilisateurs qui ne prennent pas en charge l'attribut Max-Age
      ignorer l'attribut.

   Si un cookie a à la fois l'attribut Max-Age et Expires, le
   L'attribut d'âge a la priorité et contrôle la date d'expiration du
   biscuit. Si un cookie n'a ni l'âge maximum ni l'expiration
   , l'agent utilisateur conservera le cookie jusqu'à ce que "la
   session est terminée "(tel que défini par l'agent utilisateur).

4.1.2.3. L'attribut de domaine

   L'attribut Domain spécifie les hôtes vers lesquels le cookie sera
   être envoyé. Par exemple, si la valeur de l'attribut Domain est
   "example.com", l'agent utilisateur inclura le cookie dans le cookie
   en-tête lors de l'envoi de requêtes HTTP à example.com, www.example.com et
   www.corp.example.com. (Notez qu'un% x2E (".") En tête, s'il est présent,
   est ignoré même si ce caractère n'est pas autorisé, mais un
   si% x2E (".") à la fin, s'il est présent, l'agent utilisateur l'ignorera
   l'attribut.) Si le serveur omet l'attribut Domain, l'utilisateur
   l'agent renverra le cookie uniquement au serveur d'origine.

      AVERTISSEMENT: certains agents utilisateurs existants traitent un domaine absent
      attribut comme si l'attribut Domain était présent et contenu
      le nom d'hôte actuel. Par exemple, si example.com renvoie un Set-
      En-tête de cookie sans attribut de domaine, ces agents utilisateurs
      envoyer à tort le cookie à www.example.com également.

   L'agent utilisateur rejettera les cookies sauf si l'attribut de domaine
   spécifie une portée pour le cookie qui inclurait l'origine
   serveur. Par exemple, l'agent utilisateur acceptera un cookie avec un
   Attribut de domaine "example.com" ou "foo.example.com" de
   foo.example.com, mais l'agent utilisateur n'acceptera pas un cookie avec un
   Attribut de domaine "bar.example.com" ou "baz.foo.example.com".

   REMARQUE: pour des raisons de sécurité, de nombreux agents utilisateurs sont configurés pour rejeter
   Attributs de domaine qui correspondent à des "suffixes publics". Par exemple,
   certains agents utilisateurs rejetteront les attributs de domaine "com" ou "co.uk".
   (Voir la section 5.3 pour plus d'informations.)

4.1.2.4. L'attribut de chemin

   La portée de chaque cookie est limitée à un ensemble de chemins, contrôlés par
   l'attribut Path. Si le serveur omet l'attribut Path, l'utilisateur
   l'agent utilisera le "répertoire" du composant de chemin de l'URI de demande comme
   la valeur par défaut. (Voir la section 5.1.4 pour plus de détails.)

   L'agent utilisateur inclura le cookie dans une requête HTTP uniquement si le
   chemin d'accès de la requête-uri correspond (ou est un sous-répertoire de)
   l'attribut Path du cookie, où le caractère% x2F ("/") est
   interprété comme un séparateur de répertoire.

   Bien qu’apparemment utile pour isoler les cookies entre différents
   chemins au sein d'un hôte donné, l'attribut Path ne peut pas être invoqué
   pour la sécurité (voir la section 8).

4.1.2.5. L'attribut sécurisé

   L'attribut Secure limite la portée du cookie à "sécurisé"
   canaux (où "sécurisé" est défini par l'agent utilisateur). Lorsqu'un
   cookie possède l'attribut Secure, l'agent utilisateur inclura le
   cookie dans une requête HTTP uniquement si la requête est transmise sur un
   canal sécurisé (généralement HTTP sur Transport Layer Security (TLS)
   [RFC2818]).

   Bien qu'apparemment utile pour protéger les cookies du réseau actif
   attaquants, l'attribut Secure protège uniquement les cookies
   confidentialité. Un attaquant du réseau actif peut écraser Secure
   les cookies d'un canal non sécurisé, perturbant leur intégrité (voir
   Section 8.6 pour plus de détails).

4.1.2.6. L'attribut HttpOnly

   L'attribut HttpOnly limite la portée du cookie à HTTP
   demandes. En particulier, l'attribut demande à l'agent utilisateur de
   omettre le cookie lors de l'accès aux cookies via des API "non HTTP"
   (comme une API de navigateur Web qui expose les cookies aux scripts).

   Notez que l'attribut HttpOnly est indépendant de Secure
   attribut: un cookie peut avoir à la fois HttpOnly et Secure
   attribut.

4.2. Biscuit

4.2.1. Syntaxe

   L'agent utilisateur envoie des cookies stockés au serveur d'origine dans le
   En-tête de cookie. Si le serveur est conforme aux exigences de
   Section 4.1 (et l'agent utilisateur est conforme aux exigences de
   Section 5), l'agent utilisateur enverra un en-tête de cookie conforme à
   la grammaire suivante:

   cookie-header = "Cookie:" OWS chaîne de cookies OWS
   cookie-string = cookie-pair * (";" SP cookie-pair)

4.2.2. Sémantique

   Chaque paire de cookies représente un cookie stocké par l'agent utilisateur. le
   la paire de cookies contient le nom du cookie et la valeur du cookie de l'agent utilisateur
   reçu dans l'en-tête Set-Cookie.

   Notez que les attributs des cookies ne sont pas retournés. En particulier,
   le serveur ne peut pas déterminer à partir de l'en-tête du cookie seul lorsqu'un
   expirera, pour quels hôtes le cookie est valide, pour lequel
   chemins d'accès du cookie est valide, ou si le cookie a été défini avec le
   Attributs sécurisés ou HttpOnly.

   La sémantique des cookies individuels dans l'en-tête Cookie n'est pas
   défini par ce document. On s'attend à ce que les serveurs imprègnent ces
   cookies avec une sémantique spécifique à l'application.

   Bien que les cookies soient sérialisés linéairement dans l'en-tête Cookie,
   les serveurs NE DEVRAIENT PAS se fier à l'ordre de sérialisation. En particulier,
   si l'en-tête Cookie contient deux cookies portant le même nom (par exemple,
   qui ont été définis avec des attributs de chemin ou de domaine différents), des serveurs
   NE DEVRAIT PAS compter sur l'ordre dans lequel ces cookies apparaissent dans le
   entête.

5. Configuration requise pour l'agent utilisateur

   Cette section spécifie les en-têtes Cookie et Set-Cookie dans
   suffisamment de détails pour qu'un agent utilisateur mettant en œuvre ces exigences
   peut précisément interagir avec les serveurs existants (même ceux qui
   non conforme au profil de bonne conduite décrit à la section 4).

   Un agent utilisateur pourrait appliquer plus de restrictions que celles spécifiées
   ici (par exemple, dans un souci de sécurité améliorée); cependant,
   des expériences ont montré qu'une telle rigueur réduit la probabilité
   qu'un agent utilisateur pourra interagir avec les serveurs existants.

5.1. Algorithmes de sous-composants

   Cette section définit certains algorithmes utilisés par les agents utilisateurs pour traiter
   sous-composants spécifiques des en-têtes Cookie et Set-Cookie.

5.1.1. Rendez-vous

   L'agent utilisateur DOIT utiliser un algorithme équivalent au suivant
   algorithme pour analyser une date de cookie. Notez que les différents booléens
   indicateurs définis comme faisant partie de l'algorithme (c.-à-d.
   jour du mois, mois trouvé, année trouvée) sont initialement "non définis".

   1. En utilisant la grammaire ci-dessous, divisez la date de cookie en jetons de date.

   cookie-date = * délimiteur liste de jetons de date * délimiteur
   date-token-list = date-token * (1 * délimiteur date-token)
   jeton de date = 1 * non délimiteur

   délimiteur =% x09 /% x20-2F /% x3B-40 /% x5B-60 /% x7B-7E
   non délimiteur =% x00-08 /% x0A-1F / DIGIT / ":" / ALPHA /% x7F-FF
   non numérique =% x00-2F /% x3A-FF

   jour du mois = 1 * 2DIGIT (non numérique * OCTET)
   month = ("jan" / "feb" / "mar" / "apr" /
                       "mai" / "juin" / "juillet" / "août" /
                       "sep" / "oct" / "nov" / "dec") * OCTET
   année = 2 * 4DIGIT (non numérique * OCTET)
   time = hms-time (non-digit * OCTET)
   hms-time = time-field ":" time-field ":" time-field
   champ temporel = 1 * 2DIGIT

   2. Traitez chaque jeton de date de manière séquentielle dans l'ordre des jetons de date
       apparaître à la date du cookie:

       1. Si l'indicateur d'heure trouvée n'est pas défini et que le jeton correspond à
           production de temps, activez l'indicateur d'heure trouvée et définissez
           valeur, minute et deuxième valeur aux nombres indiqués
           par les chiffres du jeton de date, respectivement. Sautez le
           sous-étapes restantes et passez au jeton de date suivant.

       2. Si l'indicateur de jour du mois trouvé n'est pas défini et que le jeton de date
           correspond à la production du jour du mois, définissez le jour de
           indicateur de mois et définissez la valeur du jour du mois sur le nombre
           dénoté par le jeton de date. Ignorez les sous-étapes restantes et
           passez au jeton de date suivant.

       3. Si l'indicateur de mois trouvé n'est pas défini et que le jeton de date correspond
           la production du mois, définissez l'indicateur du mois trouvé et définissez
           mois-valeur au mois indiqué par le jeton de date. Sautez le
           sous-étapes restantes et passez au jeton de date suivant.

       4. Si l'indicateur de l'année trouvée n'est pas défini et que le jeton de date correspond
           la production de l'année, définissez le drapeau de l'année de
           valeur-année au nombre indiqué par le jeton de date. Sautez le
           sous-étapes restantes et passez au jeton de date suivant.

   3. Si la valeur de l'année est supérieure ou égale à 70 et inférieure ou
       égal à 99, incrémentez la valeur de l'année de 1900.

   4. Si la valeur de l'année est supérieure ou égale à 0 et inférieure ou
       égal à 69, augmenter la valeur de l'année en 2000.

       1. REMARQUE: certains agents utilisateurs existants interprètent les années à deux chiffres
           différemment.

   5. Abandonnez ces étapes et ne parvenez pas à analyser la date de cookie si:

       * au moins un des mois-trouvés, mois-trouvés, trouvés-
          année, ou les indicateurs de l'heure de découverte ne sont pas définis,

       * la valeur du jour du mois est inférieure à 1 ou supérieure à 31,

       * la valeur de l'année est inférieure à 1601,

       * la valeur horaire est supérieure à 23,

       * la valeur des minutes est supérieure à 59, ou

       * la deuxième valeur est supérieure à 59.

       (Notez que les secondes intercalaires ne peuvent pas être représentées dans cette syntaxe.)

   6. Soit la date du cookie analysé la date dont le jour du mois, le mois,
       année, heure, minute et seconde (en UTC) sont le jour du mois
       valeur, la valeur du mois, la valeur de l'année, la valeur de l'heure, le
       minute et la deuxième valeur, respectivement. Si aucun
       existe, abandonnez ces étapes et ne parvenez pas à analyser la date du cookie.

   7. Renvoyez la date du cookie analysé comme résultat de cet algorithme.

5.1.2. Noms d'hôtes canonisés

   Un nom d'hôte canonisé est la chaîne générée par ce qui suit
   algorithme:

   1. Convertissez le nom d'hôte en une séquence de nom de domaine individuel
       Étiquettes.

   2. Convertissez chaque étiquette qui n'est pas une étiquette LDH non réservée (NR-LDH),
       à une étiquette A (voir la section 2.3.2.1 de [RFC5890] pour l'ancien
       et dernier), ou à une "étiquette punycode" (une étiquette résultant de la
       "ToASCII" conversion dans la section 4 de la [RFC3490]), selon le cas
       (voir la section 6.3 de cette spécification).

   3. Concaténer les étiquettes résultantes, séparées par un% x2E (".")
       personnage.

5.1.3. Correspondance de domaine

   Une chaîne de domaine correspond à une chaîne de domaine donnée si au moins l'un des
   les conditions suivantes sont remplies:

   o La chaîne de domaine et la chaîne sont identiques. (Notez que les deux
      la chaîne de domaine et la chaîne auront été canonisées pour
      minuscules à ce stade.)

   o Toutes les conditions suivantes sont remplies:

      * La chaîne de domaine est un suffixe de la chaîne.

      * Le dernier caractère de la chaîne qui n'est pas inclus dans le
         la chaîne de domaine est un caractère% x2E (".").

      * La chaîne est un nom d'hôte (c'est-à-dire pas une adresse IP).

5.1.4. Chemins et chemin d'accès

   L'agent utilisateur DOIT utiliser un algorithme équivalent au suivant
   algorithme pour calculer le chemin par défaut d'un cookie:

   1. Soit uri-path la portion de chemin du request-uri si un tel
       existe (et vide sinon). Par exemple, si le
       request-uri contient juste un chemin (et une chaîne de requête facultative),
       alors le chemin uri est ce chemin (sans le caractère% x3F ("?")
       ou chaîne de requête), et si la demande-uri contient un plein
       absoluteURI, l'uri-path est le composant de chemin de cet URI.

   2. Si le chemin uri est vide ou si le premier caractère de l'uri-
       le chemin n'est pas un caractère% x2F ("/"), affichez% x2F ("/") et ignorez
       les étapes restantes.

   3. Si le chemin uri ne contient pas plus d'un caractère% x2F ("/"),
       sortie% x2F ("/") et sautez l'étape restante.

   4. Sortez les caractères du chemin uri du premier caractère vers le haut
       à, mais sans inclure, le% x2F le plus à droite ("/").

   Un chemin d'accès de demande correspond à un chemin de cookie donné si au moins l'un des
   les conditions suivantes sont réunies:

   o Le chemin du cookie et le chemin de la demande sont identiques.

   o Le cookie-path est un préfixe du request-path, et le dernier
      le caractère du chemin du cookie est% x2F ("/").

   o Le cookie-path est un préfixe du request-path, et le premier
      caractère du chemin de demande qui n'est pas inclus dans le cookie
      chemin est un caractère% x2F ("/").

5.2. L'en-tête Set-Cookie

   Lorsqu'un agent utilisateur reçoit un champ d'en-tête Set-Cookie dans un HTTP
   réponse, l'agent utilisateur PEUT ignorer le champ d'en-tête Set-Cookie dans
   son intégralité. Par exemple, l'agent utilisateur peut souhaiter bloquer
   les réponses aux demandes "tierces" de la mise en place de cookies (voir
   Section 7.1).

   Si l'agent utilisateur n'ignore pas le champ d'en-tête Set-Cookie dans son
   intégralement, l'agent utilisateur DOIT analyser la valeur de champ du Set-Cookie
   champ d'en-tête sous la forme d'une chaîne de cookies définie (définie ci-dessous).

   REMARQUE: l'algorithme ci-dessous est plus permissif que la grammaire
   Section 4.1. Par exemple, l'algorithme supprime les caractères de début et de fin
   espace à partir du nom et de la valeur du cookie (mais conserve des
   espaces blancs), tandis que la grammaire de la section 4.1 interdit les espaces blancs dans
   ces positions. Les agents utilisateurs utilisent cet algorithme pour
   interagir avec des serveurs qui ne suivent pas les recommandations
   Section 4.

   Un agent utilisateur DOIT utiliser un algorithme équivalent au suivant
   algorithme pour analyser une "set-cookie-string":

   1. Si la chaîne set-cookie contient un caractère% x3B (";"):

          La chaîne nom-valeur-paire se compose des caractères jusqu'à,
          mais sans inclure le premier% x3B (";") et le premier
          les attributs sont constitués du reste de la chaîne set-cookie
          (y compris le% x3B (";") en question).

       Autrement:

          La chaîne nom-valeur-paire se compose de tous les caractères
          contenue dans la chaîne set-cookie, et le
          Attributs est la chaîne vide.

   2. Si la chaîne nom-valeur-paire n'a pas de caractère% x3D ("="),
       ignorer complètement la chaîne set-cookie.

   3. La chaîne de nom (éventuellement vide) se compose des caractères
       au, mais sans inclure, le premier caractère% x3D ("="), et le
       (éventuellement vide) chaîne de valeurs se compose des caractères après
       le premier caractère% x3D ("=").

   4. Supprimez tous les caractères WSP de début ou de fin du nom
       chaîne et la chaîne de valeur.

   5. Si la chaîne de nom est vide, ignorez la chaîne set-cookie
       entièrement.

   6. Le nom du cookie est la chaîne de nom et la valeur du cookie est le
       chaîne de valeur.

   L'agent utilisateur DOIT utiliser un algorithme équivalent au suivant
   algorithme pour analyser les attributs non analysés:

   1. Si la chaîne des attributs non analysés est vide, ignorez le reste de
       ces étapes.

   2. Jetez le premier caractère des attributs non analysés (qui
       sera un caractère% x3B (";")).

   3. Si les attributs non analysés restants contiennent un% x3B (";")
       personnage:

          Consommer les caractères des attributs non analysés jusqu'à, mais
          n'inclut pas le premier caractère% x3B (";").

       Autrement:

          Consommez le reste des attributs non analysés.

       Laissez la chaîne cookie-av être les caractères consommés à cette étape.

   4. Si la chaîne cookie-av contient un caractère% x3D ("="):

          La chaîne de nom d'attribut (éventuellement vide) se compose de la
          caractères jusqu'au premier% x3D ("="), à l'exclusion du premier
          et la chaîne de valeur d'attribut (éventuellement vide)
          se compose des caractères après le premier% x3D ("=")
          personnage.

       Autrement:

          La chaîne de nom d'attribut se compose de l'ensemble cookie-av
          chaîne et la chaîne de valeur d'attribut est vide.

   5. Supprimez tous les caractères WSP de début ou de fin de l'attribut
       chaîne de nom et chaîne de valeur d'attribut.

   6. Traitez le nom-attribut et la valeur-attribut conformément à
       dans les sous-sections suivantes. (Remarquerez que
       les attributs dont le nom d'attribut n'est pas reconnu sont ignorés.)

   7. Revenez à l'étape 1 de cet algorithme.

   Lorsque l'agent utilisateur a fini d'analyser la chaîne set-cookie, l'utilisateur
   l'agent est censé "recevoir un cookie" de la demande-uri avec nom
   nom-cookie, valeur valeur-cookie et attributs attribut-cookie-
   liste. (Voir la section 5.3 pour les exigences supplémentaires déclenchées par
   recevoir un cookie.)

5.2.1. L'attribut Expires

   Si le nom d'attribut ne respecte pas la casse de la chaîne
   "Expire", l'agent utilisateur DOIT traiter le cookie-av comme suit.

   Que l'expiration soit le résultat de l'analyse de la valeur d'attribut comme
   date de cookie (voir la section 5.1.1).

   Si la valeur d'attribut n'a pas pu être analysée en tant que date de cookie, ignorez le
   cookie-av.

   Si l'heure d'expiration est postérieure à la dernière date, l'agent utilisateur peut
   représenter, l'agent utilisateur PEUT remplacer le délai d'expiration par le dernier
   date représentable.

   Si l'heure d'expiration est antérieure à la date la plus ancienne, l'agent utilisateur
   peut représenter, l'agent utilisateur PEUT remplacer le délai d'expiration par le
   date représentative la plus ancienne.

   Ajoutez un attribut à la liste des attributs de cookie avec un attribut
   nom de Expires et une valeur d'attribut d'expiration-time.

5.2.2. L'attribut Max-Age

   Si le nom d'attribut ne respecte pas la casse la chaîne "Max-
   Age ", l'agent utilisateur DOIT traiter le cookie-av comme suit.

   Si le premier caractère de la valeur d'attribut n'est pas un CHIFFRE ou un "-"
   , ignorez le cookie-av.

   Si le reste de la valeur d'attribut contient un caractère non-DIGIT,
   ignorer le cookie-av.

   Soit delta-secondes la valeur d'attribut convertie en entier.

   Si delta-secondes est inférieur ou égal à zéro (0), laissez expiration-time
   être la date et l'heure les plus représentables. Sinon, laissez
   expiration-time soit la date et l'heure actuelles plus les secondes delta secondes.

   Ajoutez un attribut à la liste des attributs de cookie avec un attribut
   nom de Max-Age et une valeur d'attribut de date d'expiration.

5.2.3. L'attribut de domaine

   Si le nom d'attribut ne respecte pas la casse la chaîne "Domaine",
   l'agent utilisateur DOIT traiter le cookie-av comme suit.

   Si la valeur d'attribut est vide, le comportement n'est pas défini. cependant,
   l'agent utilisateur DEVRAIT ignorer complètement le cookie-av.

   Si le premier caractère de la chaîne de valeur d'attribut est% x2E ("."):

      Laissez cookie-domain être la valeur d'attribut sans le premier% x2E
      (".") personnage.

   Autrement:

      Laissez cookie-domain être la valeur d'attribut entière.

   Convertissez le domaine des cookies en minuscules.

   Ajoutez un attribut à la liste des attributs de cookie avec un attribut
   nom de domaine et une valeur d'attribut de domaine de cookie.

5.2.4. L'attribut de chemin

   Si le nom d'attribut ne respecte pas la casse la chaîne "Path",
   l'agent utilisateur DOIT traiter le cookie-av comme suit.

   Si la valeur d'attribut est vide ou si le premier caractère du
   la valeur d'attribut n'est pas% x2F ("/"):

      Laissez cookie-path être le chemin par défaut.

   Autrement:

      Soit cookie-path la valeur d'attribut.

   Ajoutez un attribut à la liste des attributs de cookie avec un attribut
   nom de Path et une valeur d'attribut de cookie-path.

5.2.5. L'attribut sécurisé

   Si le nom d'attribut ne respecte pas la casse la chaîne "Secure",
   l'agent utilisateur DOIT ajouter un attribut à la liste des attributs des cookies
   avec un nom d'attribut Secure et une valeur d'attribut vide.

5.2.6. L'attribut HttpOnly

   Si le nom d'attribut ne respecte pas la casse de la chaîne
   "HttpOnly", l'agent utilisateur DOIT ajouter un attribut au cookie-
   liste d'attributs avec un nom d'attribut HttpOnly et un vide
   valeur-attribut.

5.3. Modèle de stockage

   L'agent utilisateur stocke les champs suivants à propos de chaque cookie: nom,
   valeur, heure d'expiration, domaine, chemin, heure de création, dernière heure d'accès,
   indicateur persistant, indicateur hôte uniquement, indicateur sécurisé uniquement et http uniquement
   drapeau.

   Lorsque l'agent utilisateur "reçoit un cookie" d'une requête-uri avec nom
   nom-cookie, valeur valeur-cookie et attributs attribut-cookie-
   , l'agent utilisateur DOIT traiter le cookie comme suit:

   1. Un agent utilisateur PEUT ignorer un cookie reçu dans son intégralité. Pour
        par exemple, l'agent utilisateur peut souhaiter bloquer la réception de cookies
        des réponses "tierces" ou l'agent utilisateur peut ne pas souhaiter
        stocker des cookies qui dépassent une certaine taille.

   2. Créez un nouveau cookie avec le nom cookie-name, value cookie-value.
        Réglez l'heure de création et la dernière heure d'accès sur le courant
        date et l'heure.

   3. Si la liste d'attributs de cookie contient un attribut avec un
        nom-attribut de "Max-Age":

           Définissez le drapeau persistant du cookie sur true.

           Définissez le délai d'expiration du cookie sur la valeur d'attribut du dernier
           attribut dans la liste des attributs de cookie avec un nom d'attribut
           de "Max-Age".

        Sinon, si la liste d'attributs de cookie contient un attribut
        avec un nom d'attribut "Expire" (et ne contient pas de
        attribut avec un nom d'attribut "Max-Age"):

           Définissez le drapeau persistant du cookie sur true.

           Définissez le délai d'expiration du cookie sur la valeur d'attribut du dernier
           attribut dans la liste des attributs de cookie avec un nom d'attribut
           de "Expire".

        Autrement:

           Définissez le drapeau persistant du cookie sur false.

           Définissez le délai d'expiration du cookie sur le dernier représentant
           Date.

   4. Si la liste d'attributs de cookie contient un attribut avec un
        nom d'attribut de "Domaine":

           Soit l'attribut de domaine la valeur d'attribut du dernier
           attribut dans la liste des attributs de cookie avec un nom d'attribut
           de "Domaine".

        Autrement:

           Laissez l'attribut de domaine être la chaîne vide.

   5. Si l'agent utilisateur est configuré pour rejeter les "suffixes publics" et
        l'attribut de domaine est un suffixe public:

           Si l'attribut de domaine est identique au canonisé
           hôte de la demande:

              Laissez l'attribut de domaine être la chaîne vide.

           Autrement:

              Ignorez complètement le cookie et abandonnez ces étapes.

           REMARQUE: un "suffixe public" est un domaine contrôlé par un
           registre public, tel que "com", "co.uk" et "pvt.k12.wy.us".
           Cette étape est essentielle pour empêcher attacker.com de
           perturber l'intégrité de example.com en créant un cookie
           avec un attribut de domaine "com". Malheureusement, l'ensemble de
           suffixes publics (également appelés "domaines contrôlés par le registre")
           évolue avec le temps. Si possible, les agents utilisateurs DEVRAIENT utiliser un
           liste publique à jour des suffixes, telle que celle maintenue par
           le projet Mozilla à <http://publicsuffix.org/>.

   6. Si l'attribut de domaine n'est pas vide:

           Si l'hôte de requête canonisé ne correspond pas au domaine,
           attribut de domaine:

              Ignorez complètement le cookie et abandonnez ces étapes.

           Autrement:

              Définissez l'indicateur d'hôte uniquement du cookie sur false.

              Définissez le domaine du cookie sur l'attribut de domaine.

        Autrement:

           Définissez l'indicateur d'hôte uniquement du cookie sur true.

           Définissez le domaine du cookie sur l'hôte de demande canonisé.

   7. Si la liste d'attributs de cookie contient un attribut avec un
        nom-attribut de "Chemin", définissez le chemin du cookie sur attribut-
        valeur du dernier attribut de la liste des attributs de cookie avec un
        nom-attribut de "Path". Sinon, définissez le chemin du cookie sur
        le chemin par défaut de l'URI de demande.

   8. Si la liste d'attributs de cookie contient un attribut avec un
        nom d'attribut "Sécurisé", définissez l'indicateur sécurisé uniquement du cookie sur
        vrai. Sinon, définissez l'indicateur de sécurité uniquement du cookie sur false.

   9. Si la liste d'attributs de cookie contient un attribut avec un
        nom-attribut de "HttpOnly", définissez l'indicateur http uniquement du cookie sur
        vrai. Sinon, définissez l'indicateur http-only-cookie du cookie sur false.

   10. Si le cookie a été reçu d'une API "non HTTP" et que le
        l'indicateur http-only-cookie du cookie est défini, abandonnez ces étapes et ignorez le
        cookie entièrement.

   11. Si le magasin de cookies contient un cookie du même nom,
        domaine et chemin en tant que cookie nouvellement créé:

        1. Laissez old-cookie être le cookie existant du même nom,
            domaine et chemin en tant que cookie nouvellement créé. (Remarquerez que
            cet algorithme maintient l'invariant qu'il y a au plus
            un de ces cookies.)

        2. Si le cookie nouvellement créé a été reçu d'un "non-HTTP"
            L'API et l'indicateur http-only-de l'ancien cookie sont définis, abandonnez-les
            étapes et ignorer complètement le cookie nouvellement créé.

        3. Mettez à jour l'heure de création du cookie nouvellement créé en
            correspondre à l'heure de création de l'ancien cookie.

        4. Supprimez l'ancien cookie de la boutique de cookies.

   12. Insérez le cookie nouvellement créé dans le magasin de cookies.

   Un cookie est «expiré» s'il a une date d'expiration dans le passé.

   L'agent utilisateur DOIT expulser tous les cookies expirés de la boutique de cookies
   si, à tout moment, un cookie expiré existe dans le magasin de cookies.

   À tout moment, l'agent utilisateur PEUT "supprimer les cookies en excès" du
   magasin de cookies si le nombre de cookies partageant un champ de domaine dépasse
   une limite supérieure définie par l'implémentation (comme 50 cookies).

   À tout moment, l'agent utilisateur PEUT "supprimer les cookies en excès" du
   magasin de cookies si le magasin de cookies dépasse une partie supérieure prédéterminée
   lié (comme 3000 cookies).

   Lorsque l'agent utilisateur supprime les cookies excédentaires du magasin de cookies, le
   l'agent utilisateur DOIT expulser les cookies dans l'ordre de priorité suivant:

   1. Cookies périmés.

   2. Cookies qui partagent un champ de domaine avec plus d'un champ prédéterminé
       nombre d'autres cookies.

   3. Tous les cookies.

   Si deux cookies ont la même priorité de suppression, l'agent utilisateur DOIT
   supprimer le cookie avec la première date de dernier accès en premier.

   Lorsque "la session en cours est terminée" (telle que définie par l'agent utilisateur),
   l'agent utilisateur DOIT supprimer de la banque de cookies tous les cookies avec le
   indicateur persistant défini sur faux.

5.4. L'en-tête du cookie

   L'agent utilisateur inclut des cookies stockés dans la demande HTTP Cookie
   entête.

   Lorsque l'agent utilisateur génère une requête HTTP, l'agent utilisateur DOIT
   NE PAS joindre plus d'un champ d'en-tête de cookie.

   Un agent utilisateur PEUT omettre l'en-tête Cookie dans son intégralité. Pour
   Par exemple, l'agent utilisateur peut souhaiter bloquer l'envoi de cookies pendant
   demandes "tierces" de la mise en place de cookies (voir Section 7.1).

   Si l'agent utilisateur attache un champ d'en-tête Cookie à un HTTP
   demande, l'agent utilisateur DOIT envoyer la chaîne de cookies (définie ci-dessous)
   comme valeur du champ d'en-tête.

   L'agent utilisateur DOIT utiliser un algorithme équivalent au suivant
   algorithme pour calculer la "chaîne de cookies" à partir d'un magasin de cookies et d'un
   request-uri:

   1. Que cookie-list soit l'ensemble des cookies de la boutique de cookies qui
       répond à toutes les exigences suivantes:

       * Soit:

             L'indicateur d'hôte uniquement du cookie est vrai et canonisé
             l'hôte de demande est identique au domaine du cookie.

          Ou:

             L'indicateur d'hôte uniquement du cookie est faux et canonisé
             le domaine hôte de la demande correspond au domaine du cookie.

       * Le chemin du chemin de l'URI de la demande correspond au chemin du cookie.

       * Si l'indicateur sécurisé uniquement du cookie est vrai, la demande
          Le schéma de uri doit désigner un protocole "sécurisé" (tel que défini par
          l'agent utilisateur).

             REMARQUE: La notion de protocole "sécurisé" n'est pas définie par
             ce document. En règle générale, les agents utilisateurs considèrent un protocole
             sécurisé si le protocole utilise la couche de transport

             sécurité, comme SSL ou TLS. Par exemple, la plupart des utilisateurs
             les agents considèrent que "https" est un schéma qui dénote un
             protocole sécurisé.

       * Si l'indicateur http-only-cookie du cookie est vrai, excluez le
          cookie si la chaîne de cookies est générée pour un "non
          HTTP "API (tel que défini par l'agent utilisateur).

   2. L'agent utilisateur DEVRAIT trier la liste des cookies comme suit
       ordre:

       * Les cookies avec des chemins plus longs sont répertoriés avant les cookies avec
          chemins plus courts.

       * Parmi les cookies qui ont des champs de chemin d'accès de longueur égale, les cookies avec
          les temps de création antérieurs sont répertoriés avant les cookies avec plus tard
          temps de création.

       REMARQUE: tous les agents utilisateurs ne trient pas la liste des cookies dans cet ordre, mais
       cet ordre reflète la pratique courante lorsque ce document était
       écrit, et, historiquement, il y a eu des serveurs qui
       (à tort) dépendait de cet ordre.

   3. Mettez à jour le dernier accès de chaque cookie dans la liste des cookies pour
       la date et l'heure actuelles.

   4. Sérialiser la liste des cookies en une chaîne de cookies en traitant chacun
       cookie dans la liste des cookies dans l'ordre:

       1. Sortez le nom du cookie, le caractère% x3D ("=") et le
           valeur du cookie.

       2. S'il y a un cookie non traité dans la liste des cookies, affichez
           les caractères% x3B et% x20 (";").

   REMARQUE: malgré son nom, la chaîne de cookies est en fait une séquence de
   octets, pas une séquence de caractères. Pour convertir la chaîne de cookies
   (ou leurs composants) en une séquence de caractères (par exemple, pour
   présentation à l'utilisateur), l'agent utilisateur peut souhaiter essayer d'utiliser le
   Codage de caractères UTF-8 [RFC3629] pour décoder la séquence d'octets.
   Ce décodage peut cependant échouer, car toutes les séquences de
   octets est UTF-8 valide.

6. Considérations de mise en œuvre

6.1. Limites

   Les implémentations pratiques des agents utilisateurs ont des limites sur le nombre et
   taille des cookies qu'ils peuvent stocker. Les agents utilisateurs à usage général DEVRAIENT
   fournir chacune des capacités minimales suivantes:

   o Au moins 4096 octets par cookie (mesuré par la somme des
      longueur du nom, de la valeur et des attributs du cookie).

   o Au moins 50 cookies par domaine.

   o Au moins 3000 cookies au total.

   Les serveurs DEVRAIENT utiliser aussi peu et aussi petits cookies que possible pour éviter
   atteindre ces limites de mise en œuvre et minimiser le réseau
   bande passante en raison de l'en-tête Cookie étant inclus dans chaque demande.

   Les serveurs DEVRAIENT se dégrader gracieusement si l'agent utilisateur ne revient pas
   un ou plusieurs cookies dans l'en-tête Cookie, car l'agent utilisateur peut
   expulser tout cookie à tout moment sur les commandes de l'utilisateur.

6.2. Interfaces de programmation d'application

   L'une des raisons pour lesquelles les en-têtes Cookie et Set-Cookie utilisent une telle syntaxe ésotérique
   est que de nombreuses plates-formes (à la fois dans les serveurs et les agents utilisateurs) fournissent un
   interface de programmation d'applications (API) basée sur des chaînes de caractères pour les cookies,
   obligeant les programmeurs de couche application à générer et analyser le
   syntaxe utilisée par les en-têtes Cookie et Set-Cookie, que beaucoup
   les programmeurs ont mal fait, entraînant une interopérabilité
   problèmes.

   Au lieu de fournir des API basées sur des chaînes aux cookies, les plates-formes seraient
   bien servi en fournissant plus d'API sémantiques. C'est au-delà de la portée
   de ce document pour recommander des conceptions d'API spécifiques, mais il
   avantages clairs à accepter un objet "Date" abstrait au lieu d'un
   chaîne de date sérialisée.

6.3. Dépendance et migration IDNA

   IDNA2008 [RFC5890] remplace IDNA2003 [RFC3490]. Cependant, il existe
   différences entre les deux spécifications, et il peut donc y avoir
   différences dans le traitement (par exemple, la conversion) des étiquettes de nom de domaine
   ont été enregistrés sous l'un de ceux enregistrés sous l'autre.
   Il y aura une période de transition d'un certain temps au cours de laquelle IDNA2003-
   les étiquettes de nom de domaine basées existeront dans la nature. Les agents utilisateurs DEVRAIENT
   implémenter IDNA2008 [RFC5890] et PEUT implémenter [UTS46] ou [RFC5895]

   afin de faciliter leur transition IDNA. Si un agent utilisateur ne
   pas implémenter IDNA2008, l'agent utilisateur DOIT implémenter IDNA2003
   [RFC3490].

7. Considérations sur la confidentialité

   Les cookies sont souvent critiqués pour permettre aux serveurs de suivre les utilisateurs. Pour
   Par exemple, un certain nombre de sociétés «d'analyse Web» utilisent des cookies pour
   reconnaître lorsqu'un utilisateur revient sur un site Web ou visite un autre site Web
   site. Bien que les cookies ne soient pas le seul mécanisme que les serveurs peuvent utiliser pour
   suivre les utilisateurs à travers les requêtes HTTP, les cookies facilitent le suivi car
   ils sont persistants sur toutes les sessions d'agent utilisateur et peuvent être partagés
   entre hôtes.

7.1. Cookies tiers

   Les cookies dits "tiers" sont particulièrement inquiétants. Dans
   rendu d'un document HTML, un agent utilisateur demande souvent des ressources
   à partir d'autres serveurs (tels que les réseaux publicitaires). Ces tiers
   les serveurs peuvent utiliser des cookies pour suivre l'utilisateur même si l'utilisateur n'a jamais
   visite directement le serveur. Par exemple, si un utilisateur visite un site
   qui contient du contenu d'un tiers, puis des visites ultérieures
   un autre site qui contient du contenu du même tiers, le
   un tiers peut suivre l'utilisateur entre les deux sites.

   Certains agents utilisateurs restreignent le comportement des cookies tiers. Pour
   Par exemple, certains de ces agents utilisateurs refusent d'envoyer l'en-tête Cookie
   dans les demandes de tiers. D'autres refusent de traiter le Set-Cookie
   en-tête dans les réponses aux demandes de tiers. Les agents utilisateurs varient considérablement
   dans leurs politiques de cookies tiers. Ce document accorde à l'utilisateur
   grande latitude des agents pour expérimenter des politiques de cookies tiers
   qui équilibrent les besoins de confidentialité et de compatibilité de leurs utilisateurs.
   Cependant, ce document ne cautionne aucun tiers particulier
   politique de cookies.

   Les politiques de blocage des cookies tiers sont souvent inefficaces sur
   atteindre leurs objectifs de confidentialité si les serveurs tentent de contourner leur
   restrictions pour suivre les utilisateurs. En particulier, deux collaborateurs
   les serveurs peuvent souvent suivre les utilisateurs sans utiliser de cookies du tout par
   injecter des informations d'identification dans des URL dynamiques.

7.2. Contrôles utilisateur

   Les agents utilisateurs DEVRAIENT fournir aux utilisateurs un mécanisme de gestion des
   les cookies stockés dans la boutique de cookies. Par exemple, un agent utilisateur peut
   permettre aux utilisateurs de supprimer tous les cookies reçus pendant une période spécifiée

   ou tous les cookies liés à un domaine particulier. En outre, de nombreux
   les agents utilisateurs incluent un élément d'interface utilisateur qui permet aux utilisateurs d'examiner
   les cookies stockés dans leur magasin de cookies.

   Les agents utilisateurs DEVRAIENT fournir aux utilisateurs un mécanisme de désactivation
   biscuits. Lorsque les cookies sont désactivés, l'agent utilisateur NE DOIT PAS inclure
   un en-tête de cookie dans les requêtes HTTP sortantes et l'agent utilisateur NE DOIT PAS
   traiter les en-têtes Set-Cookie dans les réponses HTTP entrantes.

   Certains agents utilisateurs offrent aux utilisateurs la possibilité d'empêcher la persistance
   stockage des cookies entre les sessions. Lorsqu'il est configuré ainsi, l'utilisateur
   les agents DOIVENT traiter tous les cookies reçus comme si le drapeau persistant était
   mis à faux. Certains agents utilisateurs populaires exposent cette fonctionnalité via
   mode "navigation privée" [Aggarwal2010].

   Certains agents utilisateurs offrent aux utilisateurs la possibilité d'approuver
   écrit dans le magasin de cookies. Dans de nombreux scénarios d'utilisation courants, ces
   les contrôles génèrent un grand nombre d'invites. Cependant, certains
   les utilisateurs conscients trouvent néanmoins ces commandes utiles.

7.3. Dates de péremption

   Bien que les serveurs puissent définir la date d'expiration des cookies sur
   futur lointain, la plupart des agents utilisateurs ne conservent pas réellement les cookies pour
   plusieurs décennies. Plutôt que de choisir une longue expiration gratuite
   périodes, les serveurs DEVRAIENT promouvoir la confidentialité des utilisateurs en sélectionnant
   les périodes d'expiration des cookies en fonction de l'objectif du cookie. Pour
   Par exemple, un identifiant de session typique peut raisonnablement être défini sur
   expirent dans deux semaines.

8. Considérations de sécurité

8.1. Aperçu

   Les cookies présentent un certain nombre de pièges de sécurité. Cette section présente un
   quelques-uns des problèmes les plus saillants.

   En particulier, les cookies encouragent les développeurs à s'appuyer sur la température ambiante
   autorité d'authentification, devenant souvent vulnérable aux attaques
   comme la falsification de requêtes intersites [CSRF]. Aussi, lors du stockage
   identifiants de session dans les cookies, les développeurs créent souvent des sessions
   vulnérabilités de fixation.

   Le chiffrement de la couche de transport, tel que celui utilisé dans HTTPS, est
   insuffisante pour empêcher un attaquant du réseau d'obtenir ou de modifier
   les cookies d'une victime parce que le protocole de cookie lui-même a divers
   les vulnérabilités (voir "Faible confidentialité" et "Faible intégrité",

   au dessous de). De plus, par défaut, les cookies ne fournissent pas
   confidentialité ou intégrité des attaquants du réseau, même lorsqu'ils sont utilisés
   en collaboration avec HTTPS.

8.2. Autorité ambiante

   Un serveur qui utilise des cookies pour authentifier les utilisateurs peut souffrir de sécurité
   vulnérabilités car certains agents utilisateurs laissent les parties distantes émettre
   Demandes HTTP de l'agent utilisateur (par exemple, via des redirections HTTP ou HTML
   formes). Lors de l'émission de ces demandes, les agents utilisateurs attachent même des cookies
   si la partie distante ne connaît pas le contenu des cookies,
   laisser potentiellement la partie distante exercer son autorité à un
   serveur.

   Bien que ce problème de sécurité passe par un certain nombre de noms (par exemple,
   demande de contrefaçon intersite, député confus), le problème découle de
   les cookies étant une forme d'autorité ambiante. Les cookies encouragent le serveur
   opérateurs pour séparer la désignation (sous forme d'URL) de
   autorisation (sous forme de cookies). Par conséquent, l'agent utilisateur
   pourrait fournir l'autorisation pour une ressource désignée par le
   attaquant, ce qui pourrait amener le serveur ou ses clients à entreprendre
   actions désignées par l'attaquant comme si elles étaient autorisées par
   l'utilisateur.

   Au lieu d'utiliser des cookies pour l'autorisation, les opérateurs de serveur peuvent
   souhaitent envisager de mêler désignation et autorisation en traitant
   URL comme capacités. Au lieu de stocker des secrets dans les cookies, cette
   approche stocke les secrets dans les URL, obligeant l'entité distante à
   fournir le secret lui-même. Bien que cette approche ne soit pas une panacée,
   une application judicieuse de ces principes peut conduire à une
   Sécurité.

8.3. Effacer le texte

   Sauf si elles sont envoyées via un canal sécurisé (tel que TLS), les informations
   les en-têtes Cookie et Set-Cookie sont transmis en clair.

   1. Toutes les informations sensibles véhiculées dans ces en-têtes sont exposées à
       une écoute indiscrète.

   2. Un intermédiaire malveillant pourrait modifier les en-têtes lors de leurs déplacements
       dans les deux sens, avec des résultats imprévisibles.

   3. Un client malveillant pourrait modifier l'en-tête du cookie avant
       transmission, avec des résultats imprévisibles.

   Les serveurs DEVRAIENT crypter et signer le contenu des cookies (en utilisant
   quel que soit le format souhaité par le serveur) lors de leur transmission au
   agent utilisateur (même lors de l'envoi des cookies via un canal sécurisé).
   Cependant, le cryptage et la signature du contenu des cookies n'empêchent pas
   l'attaquant de transplanter un cookie d'un agent utilisateur à un autre
   ou de rejouer le cookie ultérieurement.

   En plus de crypter et de signer le contenu de chaque cookie,
   les serveurs qui nécessitent un niveau de sécurité supérieur DEVRAIENT utiliser le cookie
   et les en-têtes Set-Cookie uniquement sur un canal sécurisé. Lors de l'utilisation
   les cookies sur un canal sécurisé, les serveurs DEVRAIENT définir
   attribut (voir la section 4.1.2.5) pour chaque cookie. Si un serveur ne
   pas défini l'attribut sécurisé, la protection fournie par le sécurisé
   canal sera largement théorique.

   Par exemple, considérons un serveur de messagerie Web qui stocke une session
   identifiant dans un cookie et est généralement accessible via HTTPS. Si la
   serveur ne définit pas l'attribut Secure sur ses cookies, un
   L'attaquant de réseau peut intercepter toute requête HTTP sortante du
   agent utilisateur et rediriger cette demande vers le serveur de messagerie Web via HTTP.
   Même si le serveur de messagerie Web n'écoute pas les connexions HTTP, le
   l'agent utilisateur inclura toujours les cookies dans la demande. Les actifs
   l'attaquant de réseau peut intercepter ces cookies, les rejouer contre le
   serveur et découvrez le contenu de l'e-mail de l'utilisateur. Si, au lieu de cela,
   serveur avait défini l'attribut Secure sur ses cookies, l'agent utilisateur
   n'aurait pas inclus les cookies dans la demande de texte en clair.

8.4. Identifiants de session

   Au lieu de stocker les informations de session directement dans un cookie (où
   pourrait être exposé à un attaquant ou rejoué par un attaquant), les serveurs
   stocker un nonce (ou "identifiant de session") dans un cookie. Lorsque le serveur
   reçoit une requête HTTP avec un nonce, le serveur peut rechercher l'état
   informations associées au cookie utilisant le nonce comme clé.

   L'utilisation de cookies d'identification de session limite les dommages qu'un attaquant peut
   provoquer si l'attaquant apprend le contenu d'un cookie parce que le
   nonce n'est utile que pour interagir avec le serveur (contrairement aux
   contenu non cookie, qui pourrait lui-même être sensible). En outre,
   l'utilisation d'un seul nonce empêche un attaquant de "se raccorder" ensemble
   le contenu des cookies de deux interactions avec le serveur, qui pourraient
   provoquer le comportement inattendu du serveur.

   L'utilisation d'identifiants de session n'est pas sans risque. Par exemple, le
   le serveur DEVRAIT prendre soin d'éviter les vulnérabilités de «fixation de session».
   Une attaque de fixation de session se déroule en trois étapes. Premièrement les
   l'attaquant transplante un identifiant de session de son agent utilisateur
   à l'agent utilisateur de la victime. Deuxièmement, la victime utilise cette session

   identifiant pour interagir avec le serveur, imprégnant éventuellement la session
   identifiant avec les informations d'identification ou les informations confidentielles de l'utilisateur.
   Troisièmement, l'attaquant utilise l'identifiant de session pour interagir avec
   serveur directement, obtenant éventuellement l'autorisation de l'utilisateur ou
   information confidentielle.

8.5. Faible confidentialité

   Les cookies n'offrent pas d'isolement par port. Si un cookie est lisible par
   un service fonctionnant sur un port, le cookie est également lisible par un
   service exécuté sur un autre port du même serveur. Si un cookie est
   accessible en écriture par un service sur un port, le cookie est également accessible en écriture par un
   service exécuté sur un autre port du même serveur. Pour cette raison,
   les serveurs NE DEVRAIENT PAS tous les deux exécuter des services
   différents ports du même hôte et utilisent des cookies pour stocker la sécurité -
   information sensible.

   Les cookies n'offrent pas d'isolement par schéma. Bien que le plus souvent
   utilisés avec les schémas http et https, les cookies pour un hôte donné
   peut également être disponible pour d'autres schémas, tels que ftp et gopher.
   Bien que ce manque d’isolement par régime soit plus apparent dans les
   API HTTP qui permettent d'accéder aux cookies (par exemple, le document.cookie de HTML
   API), le manque d'isolement par schéma est en fait présent dans
   exigences pour le traitement des cookies eux-mêmes (par exemple, envisager
   récupération d'un URI avec le schéma gopher via HTTP).

   Les cookies n'offrent pas toujours un isolement par chemin. Bien que le
   le protocole au niveau du réseau n'envoie pas de cookies stockés pour un seul chemin vers
   un autre, certains agents utilisateurs exposent les cookies via des API non HTTP, telles que
   API document.cookie de HTML. Parce que certains de ces agents utilisateurs (par exemple,
   navigateurs Web) n'isolent pas les ressources reçues de différents chemins,
   une ressource récupérée à partir d'un chemin peut accéder aux cookies
   stocké pour un autre chemin.

8.6. Faible intégrité

   Les cookies ne fournissent pas de garanties d'intégrité pour les domaines frères (et
   leurs sous-domaines). Par exemple, considérez foo.example.com et
   bar.example.com. Le serveur foo.example.com peut définir un cookie avec un
   Attribut de domaine "example.com" (éventuellement écraser un fichier existant
   cookie "example.com" défini par bar.example.com), et l'agent utilisateur
   inclure ce cookie dans les requêtes HTTP à bar.example.com. dans le
   dans le pire des cas, bar.example.com ne pourra pas distinguer ce cookie
   à partir d'un cookie, il s'est installé. Le serveur foo.example.com est peut-être
   capable de tirer parti de cette capacité à monter une attaque contre
   bar.example.com.

   Même si l'en-tête Set-Cookie prend en charge l'attribut Path, le
   L'attribut de chemin ne fournit aucune protection d'intégrité car le
   l'agent utilisateur acceptera un attribut Path arbitraire dans un Set-Cookie
   entête. Par exemple, une réponse HTTP à une demande de
   http://example.com/foo/bar peut définir un cookie avec un attribut Path de
   "/ qux". Par conséquent, les serveurs NE DEVRAIENT PAS s'exécuter mutuellement
   services méfiants sur différents chemins du même hôte et utilisation
   cookies pour stocker des informations sensibles à la sécurité.

   Un attaquant du réseau actif peut également injecter des cookies dans le cookie
   en-tête envoyé à https://example.com/ en usurpant l'identité d'une réponse de
   http://example.com/ et en injectant un en-tête Set-Cookie. Le HTTPS
   serveur d'exemple.com ne pourra pas distinguer ces cookies
   des cookies qu'il s'est mis dans une réponse HTTPS. Un actif
   l'attaquant de réseau pourrait être en mesure de tirer parti de cette capacité à monter un
   attaque contre example.com même si example.com utilise HTTPS
   exclusivement.

   Les serveurs peuvent atténuer partiellement ces attaques en chiffrant et
   signer le contenu de leurs cookies. Cependant, en utilisant la cryptographie
   n'atténue pas complètement le problème car un attaquant peut rejouer
   un cookie qu'il a reçu du serveur authentique example.com dans
   la session de l'utilisateur, avec des résultats imprévisibles.

   Enfin, un attaquant pourrait être en mesure de forcer l'agent utilisateur à supprimer
   cookies en stockant un grand nombre de cookies. Une fois l'agent utilisateur
   atteint sa limite de stockage, l'agent utilisateur sera forcé d'expulser
   quelques biscuits. Les serveurs NE DEVRAIENT PAS compter sur la conservation par les agents utilisateurs
   biscuits.

8.7. Dépendance à DNS

   Les cookies s'appuient sur le système de noms de domaine (DNS) pour la sécurité. Si la
   DNS est partiellement ou totalement compromis, le protocole des cookies peut échouer
   pour fournir les propriétés de sécurité requises par les applications.

9. Considérations IANA

   Le registre de champ d'en-tête de message permanent (voir [RFC3864]) a été
   mis à jour avec les enregistrements suivants.

9.1. Biscuit

   Nom du champ d'en-tête: Cookie

   Protocole applicable: http

   Statut: standard

   Auteur / contrôleur de changement: IETF

   Document de spécification: cette spécification (section 5.4)

9.2. Set-Cookie

   Nom du champ d'en-tête: Set-Cookie

   Protocole applicable: http

   Statut: standard

   Auteur / contrôleur de changement: IETF

   Document de spécification: cette spécification (section 5.2)

9.3. Cookie2

   Nom du champ d'en-tête: Cookie2

   Protocole applicable: http

   Statut: obsolète

   Auteur / contrôleur de changement: IETF

   Document de spécification: [RFC2965]

9.4. Set-Cookie2

   Nom du champ d'en-tête: Set-Cookie2

   Protocole applicable: http

   Statut: obsolète

   Auteur / contrôleur de changement: IETF

   Document de spécification: [RFC2965]

10. Références

10.1. Références normatives

   [RFC1034] Mockapetris, P., "Noms de domaine - concepts et installations",
              STD 13, RFC 1034, novembre 1987.

   [RFC1123] Braden, R., "Configuration requise pour les hôtes Internet - Application
              and Support ", STD 3, RFC 1123, octobre 1989.

   [RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer
              Niveaux d'exigence ", BCP 14, RFC 2119, mars 1997.

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. et T. Berners-Lee, "Hypertexte
              Protocole de transfert - HTTP / 1.1 ", RFC 2616, juin 1999.

   [RFC3490] Faltstrom, P., Hoffman, P. et A. Costello,
              "Internationalisation des noms de domaine dans les applications (IDNA)",
              RFC 3490, mars 2003.

              Voir la section 6.3 pour une explication des raisons pour lesquelles le
              une référence à une spécification obsolète est nécessaire.

   [RFC4790] Newman, C., Duerst, M. et A. Gulbrandsen, "Internet
              Registre de classement des protocoles d'application ", RFC 4790,
              Mars 2007.

   [RFC5234] Crocker, D., Ed. et P. Overell, "BNF augmenté pour la syntaxe
              Spécifications: ABNF ", STD 68, RFC 5234, janvier 2008.

   [RFC5890] Klensin, J., "Noms de domaine internationalisés pour
              Applications (IDNA): Definitions and Document Framework ",
              RFC 5890, août 2010.

   [USASCII] American National Standards Institute, "Caractère codé
              Set - Code standard américain 7 bits pour information
              Interchange ", ANSI X3.4, 1986.

10.2. Références informatives

   [RFC2109] Kristol, D. et L. Montulli, "HTTP State Management
              Mechanism ", RFC 2109, février 1997.

   [RFC2965] Kristol, D. et L. Montulli, "HTTP State Management
              Mechanism ", RFC 2965, octobre 2000.

   [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, mai 2000.

   [Netscape] Netscape Communications Corp., "État client persistant -
              Cookies HTTP ", 1999, <http://web.archive.org/web/
              20020803110822 / http: //wp.netscape.com/newsref/std/
              cookie_spec.html>.

   [Kri2001] Kristol, D., "Cookies HTTP: normes, confidentialité et
              Politics ", ACM Transactions on Internet Technology Vol. 1,
              # 2, novembre 2001, <http://arxiv.org/abs/cs.SE/0105018>.

   [RFC3629] Yergeau, F., "UTF-8, un format de transformation de l'ISO
              10646 ", STD 63, RFC 3629, novembre 2003.

   [RFC4648] Josefsson, S., "Les données Base16, Base32 et Base64
              Encodings ", RFC 4648, octobre 2006.

   [RFC3864] Klyne, G., Nottingham, M. et J. Mogul, "Inscription
              Procédures pour les champs d'en-tête de message ", BCP 90, RFC 3864,
              Septembre 2004.

   [RFC5895] Resnick, P. et P. Hoffman, «Mapping Characters for
              Noms de domaine internationalisés dans les applications (IDNA)
              2008 ", RFC 5895, septembre 2010.

   [UTS46] Davis, M. et M. Suignard, "Compatibilité Unicode IDNA
              Processing ", Unicode Technical Standards # 46, 2010,
              <http://unicode.org/reports/tr46/>.

   [CSRF] Barth, A., Jackson, C. et J. Mitchell, "Robust Defenses
              for Cross-Site Request Forgery ", 2008,
              <http://portal.acm.org/citation.cfm?id=1455770.1455782>.

   [Aggarwal2010]
              Aggarwal, G., Burzstein, E., Jackson, C. et D. Boneh,
              "Une analyse des modes de navigation privée dans les temps modernes
              Browsers ", 2010, <http://www.usenix.org/events/sec10/tech/
              full_papers / Aggarwal.pdf>.

Annexe A. Remerciements

   Ce document emprunte beaucoup à la RFC 2109 [RFC2109]. Nous sommes
   redevable à David M. Kristol et Lou Montulli pour leurs efforts
   spécifiez les cookies. David M. Kristol, en particulier, a fourni
   des conseils précieux pour naviguer dans le processus de l'IETF. Nous aimerions également
   pour remercier Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry,
   corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van
   Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim
   Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller,
   Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre,
   Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro
   Tsujikawa, David Wagner, Dan Winship et Dan Witte pour leur
   commentaires précieux sur ce document.

Adresse de l'auteur

   Adam Barth
   Université de Californie, Berkeley

   Courriel: abarth@eecs.berkeley.edu
   URI: http://www.adambarth.com/