Partager via

Cookies HTTP

  • Article

Les cookies HTTP fournissent au serveur un mécanisme pour stocker et récupérer des informations d’état sur le système de l’application cliente. Ce mécanisme permet aux applications web de stocker des informations sur les articles sélectionnés, les préférences des utilisateurs, les informations d’inscription et d’autres informations pouvant être récupérées ultérieurement.

Il existe deux en-têtes, Set-Cookie et Cookie, qui sont liés aux cookies. L’en-tête Set-Cookie est envoyé par le serveur en réponse à une requête HTTP, qui est utilisée pour créer un cookie sur le système de l’utilisateur. L’en-tête Cookie est inclus par l’application cliente avec une requête HTTP envoyée à un serveur, s’il existe un cookie qui a un domaine et un chemin correspondants.

L’en-tête de réponse Set-Cookie utilise le format suivant :

Set-Cookie: <name>=<value>[; <name>=<value>]...
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; httponly]

Une ou plusieurs séquences de chaînes (séparées par des points-virgules) qui suivent le modèle name=value doivent être incluses dans l’en-tête de réponse Set-Cookie. Le serveur peut utiliser ces séquences de chaînes pour stocker des données sur le système du client.

La date d’expiration est définie en utilisant le format expires=date, où date est la date d’expiration en heure moyenne de Greenwich (GMT). Si la date d’expiration n’est pas définie, le cookie expire après la fin de la session Internet. Sinon, le cookie est conservé dans le cache jusqu’à la date d’expiration. La date doit utiliser le format suivant :

DAY, DD-MMM-YYYY HH:MM:SS GMT

DAY

Le jour de la semaine (Sun, Mon, Tue, Wed, Thu, Fri, Sat).

DD

Le jour du mois (par exemple 01 pour le premier jour du mois).

MMM

L’abréviation de trois lettres pour le mois (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec).

YYYY

Année.

HH

La valeur de l’heure en temps militaire (22 serait 22:00, par exemple).

MM

La valeur de la minute.

SS

Seconde valeur.

La spécification du nom de domaine, en utilisant le modèle domain=domain_name, est facultative pour les cookies persistants et est utilisée pour indiquer la fin du domaine pour lequel le cookie est valide. Les cookies de session qui spécifient un domaine sont rejetés. Si la fin du nom de domaine spécifiée correspond à la requête, le cookie essaie de correspondre au chemin pour déterminer si le cookie doit être envoyé. Par exemple, si la fin du nom de domaine est .microsoft.com, les requêtes vers home.microsoft.com et support.microsoft.com seraient vérifiées pour voir si le modèle spécifié correspond à la requête. Le nom de domaine doit comporter au moins deux ou trois points pour éviter que les cookies ne soient définis pour des terminaisons de noms de domaine largement utilisés, tels que .com, .edu, et co.jp. Les noms de domaine autorisés seraient similaires à .microsoft.com, .someschool.edu, et .someserver.co.jp. Seuls les hôtes du domaine spécifié peuvent définir un cookie pour un domaine.

La définition du chemin, en utilisant le modèle path=some_path, est facultative et peut être utilisée pour spécifier un sous-ensemble des URL pour lesquelles le cookie est valide. Si un chemin est spécifié, le cookie est considéré comme valide pour toutes les requêtes correspondant à ce chemin. Par exemple, si le chemin spécifié est /example, les requêtes avec les chemins /examplecode et /example/code.htm correspondraient. Si aucun chemin n’est spécifié, le chemin est supposé être celui de la ressource associée à l’en-tête Set-Cookie.

Le cookie peut également être marqué comme sécurisé, ce qui spécifie que le cookie ne peut être envoyé qu’aux serveurs https.

Enfin, un cookie peut être marqué comme HttpOnly (les attributs ne sont pas sensibles à la casse), pour indiquer que le cookie n’est pas scriptable et ne doit pas être révélé à l’application cliente, pour des raisons de sécurité. Dans Windows Internet, cela signifie que le cookie ne peut pas être récupéré par la fonction InternetGetCookie.

L’en-tête Cookie est inclus avec toutes les requêtes HTTP qui ont un cookie dont le domaine et le chemin correspondent à la requête. L’en-tête Cookie a le format suivant :

Cookie: <name>=<value> [;<name>=<value>]...

Une ou plusieurs séquences de chaînes, utilisant le format name=value, contiennent les informations qui ont été définies dans le cookie.

Génération de cookies

Il existe trois méthodes pour générer des cookies pour Microsoft Internet Explorer : en utilisant Microsoft JScript, en utilisant les fonctions WinINet, et en utilisant un script CGI. Toutes les méthodes doivent définir les informations incluses dans l’en-tête Set-Cookie.

En utilisant le modèle d’objet Dynamic HTML (DHTML), les cookies peuvent être définis en appelant la propriété cookie de l’objet document, comme montré dans l’exemple suivant.

<SCRIPT language="JavaScript">
<!--
    document.cookie = "SomeValueName = Some_Value";
-->
</SCRIPT>

Les cookies peuvent être créés par les applications en utilisant la fonction InternetSetCookie. Pour plus d’informations, veuillez consulter la section Paramétrer un Cookie.

Les cookies sont générés en incluant un en-tête Set-Cookie dans le cadre d’un script CGI inclus dans la réponse HTTP à une requête.

L’exemple suivant est un script CGI qui inclut un en-tête Set-Cookie en utilisant Perl.

print "Set-Cookie:Test=test_value; 
      expires=Sat, 01-Jan-2000 00:00:00 GMT;
      path=/;"

Remarque

WinINet ne prend pas en charge les implémentations de serveurs. De plus, il ne doit pas être utilisé à partir d’un service. Pour les implémentations de serveurs ou les services, utilisez Microsoft Windows HTTP Services (WinHTTP).