recursal/MDN huggingface dataset:
If-Modified-Since
=================

L'entête de requête HTTP **`If-Modified-Since`** rend la requête conditionnelle : le serveur renverra la ressource demandée, avec un status `200`, seulement si elle a été modifiée pour la dernière fois après la date donnée. Si la ressource n'a pas été modifiée depuis, la réponse sera un `304` sans aucun contenu; le header `Last-Modified` contiendra la date de la dernière modification. À l'inverse de `If-Unmodified-Since` (en-US), `If-Modified-Since` ne peut être utilisé qu'avec un `GET` ou un `HEAD`.

Lorsqu'il est combiné avec `If-None-Match`, il est ignoré, à moins que le serveur ne supporte pas `If-None-Match`.

Le cas d'usage le plus courant est la mise-à-jour d'une entité cachée qui n'a pas de `ETag` associé.

|  |  |
| --- | --- |
| Type d'entête | Request header |
| Forbidden header name | non |

Syntaxe
-------
```

If-Modified-Since: <label-jour>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
```

Directives
----------

<label-jour>

Parmis : "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", ou "Sun" (sensible à la casse).

<jour>

2 chiffres du numéro du jour, par ex. "04" or "23".

<mois>

Parmis : "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).

<année>

4 chiffres de l'année, par ex. "1990" ou "2016".

<heure>

2 chiffres du numéro de l'heure, par ex. "09" ou "23".

<minute>

2 chiffres des minutes, par ex. "04" or "59".

<seconde>

2 chiffres des secondes, par ex. "04" or "59".

`GMT`

*Greenwich Mean Time*. Les dates HTTP sont toujours exprimées en GMT, jamais en temps localisé.

Exemples
--------
```

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.if-modified-since |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `ETag`
* `If-Unmodified-since` (en-US)
* `If-Match` (en-US)
* `If-None-Match`
* `304` `Not Modified`
Authorization
=============

L'en-tête de requête HTTP **`Authorization`** contient les identifiants permettant l'authentification d'un utilisateur auprès d'un serveur, habituellement après que le serveur ait répondu avec un statut `401` `Unauthorized` et l'en-tête `WWW-Authenticate`

|  |  |
| --- | --- |
| Type d'en-tête | Request header |
| Nom d'en-tête interdit | Non |

Syntaxe
-------
```

Authorization: <type> <credentials>
```

Directives
----------

*<type>*

Le type d'authentification. Le type `"Basic"` est souvent utilisé. Pour connaître les autres types :

* IANA registry of Authentication schemes

*<credentials>*

Si c'est le type d'authentification `"Basic"` qui est utilisé, les identifiants sont construits de la manière suivante :

* L'identifiant de l'utilisateur et le mot de passe sont combinés avec deux-points : (`aladdin:sesameOuvreToi`).
* Cette chaîne de caractères est ensuite encodée en base64 (`YWxhZGRpbjpzZXNhbWVPdXZyZVRvaQ==`).

**Note :** L'encodage en Base64 n'est pas un chiffrement ou un hachage ! Cette méthode est aussi peu sûre que d'envoyer les identifiants en clair (l'encodage base64 est un encodage réversible). Il faudra privilégier HTTPS lorsqu'on emploie une authentification "basique".

Exemples
--------
```

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```


Voir aussi l'article authentification HTTP avec des exemples de configuration de serveurs Apache ou nginx pour protéger votre site grâce à un mot de passe et l'authentification HTTP basique.

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.authorization |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir
----

* L'authentification HTTP
* `WWW-Authenticate`
* `Proxy-Authorization` (en-US)
* `Proxy-Authenticate` (en-US)
* `401`, `403`, `407`
Last-Modified
=============

L'entête HTTP de réponse **`Last-Modified`** contient la date et l'heure à laquelle le serveur d'origine pense que la ressource a été modifiée pour la dernière fois. Il est utilisé comme un validateur pour déterminer si une ressource reçue et une stockée sont les mêmes. Moins précis qu'un entête `ETag`, c'est un mécanisme de rechange. Les requêtes conditionnelles contenant des entêtes `If-Modified-Since` ou `If-Unmodified-Since` (en-US) font usage de ce champ.

|  |  |
| --- | --- |
| Type d'entête | Response header |
| Forbidden header name | non |
| CORS-safelisted response-header | oui |

Syntaxe
-------
```

Last-Modified: <nom-jour>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
```

Directives
----------

<nom-jour>

Un nom parmi "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", ou "Sun" (sensible à la casse).

<jour>

Jour sur 2 chiffres, par ex. "04" ou "23".

<mois>

Un mois parmi "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).

<année>

Millésime sur 4 chiffres, par ex. "1990" ou "2016".

<heure>

Heure sur 2 chiffres, par ex. "09" ou "23".

<minute>

Minute sur 2 chiffres, par ex. "04" ou "59".

<seconde>

Seconde sur 2 chiffres, par ex. "04" ou "59".

`GMT`

Greenwich Mean Time. Les dates HTTP sont toujours exprimées en GMT, jamais en heure locale.

Exemples
--------
```

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.last-modified |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `If-Modified-Since`
* `If-Unmodified-Since` (en-US)
* `Etag`
Allow
=====

L'entête **`Allow`** liste les méthodes supportées par une ressource.

Cet entête doit être envoyée si le serveur répond avec un statut `405` `Method Not Allowed` pour indiquer quelles méthodes peuvent être utilisées pour la requête. Une entête `Allow` vide indique que la ressource n'autorise aucune méthode, ce qui peut erriver temporairement pour une ressource donnée, par exemple.

|  |  |
| --- | --- |
| Type d'entête | Entity header |
| Forbidden header name | non |

Syntaxe
-------
```

Allow: <methodes-http>
```

Directives
----------

<methodes-http>

La liste des méthodes de requête HTTP autorisées, séparées par des virgules.

Exemples
--------
```

Allow: GET, POST, HEAD
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.allow |

Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* `405`
* `Server`
Accept-Charset
==============

L'en-tête HTTP de la requête **`Accept-Charset`** indique le jeu de caractères que le client est capable de comprendre. À l'aide de la content negotiation, le serveur sélectionne l'une des propositions, l'utilise et informe le client de son choix dans l'en-tête de réponse `Content-Type`. Les navigateurs ne définissent généralement pas cet en-tête car la valeur par défaut de chaque type de contenu est généralement correcte et sa transmission permettrait une empreinte digitale plus facile.

Si le serveur ne peut servir aucun jeu de caractères correspondant, il peut théoriquement renvoyer un code d'erreur `406` (non acceptable). Cependant, pour une meilleure expérience utilisateur, cela est rarement fait et le moyen le plus courant consiste à ignorer l'en-tête `Accept-Charset` dans ce cas.

**Note :** Dans les premières versions de HTTP / 1.1, un jeu de caractères par défaut (ISO-8859-1) était défini. Ce n'est plus le cas et maintenant chaque type de contenu peut avoir sa propre valeur par défaut.


|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntaxe
-------
```

Accept-Charset: <charset>

// Multiple types, weighted with the quality value syntax:
Accept-Charset: utf-8, iso-8859-1;q=0.5
```

Les directives
--------------

`<charset>`

Un jeu de caractères comme utf-8 ou iso-8859-15.

`*`

Tout jeu de caractères non mentionné ailleurs dans l'en-tête; '\*' utilisé comme un joker.

`;q=` (q-factor weighting)

Toute valeur est placée dans un ordre de préférence exprimé à l'aide d'une valeur de qualité relative appelée *weight*.

Examples
--------
```

Accept-Charset: iso-8859-1

Accept-Charset: utf-8, iso-8859-1;q=0.5

Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
```

Spécifications
--------------

{{Specifications}}Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* HTTP content negotiation
* Header avec le résultat de la négociation de contenu : `Content-Type`
* Autres Header similaires : `TE` (en-US), `Accept-Encoding`, `Accept-Language`, `Accept`
Expires
=======

Le header **`Expires`** contient la date/heure après laquelle la réponse est considérée comme dépréciée.

Les dates invalides, telles que la valeur 0, représentent une date dans le passé et signifient que la ressource est expirée.

Si un header `Cache-Control` contient une directive "max-age" ou "s-max-age" dans la réponse, le header `Expires` sera ignoré.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |
| CORS-safelisted response-header | yes |

Syntaxe
-------
```

Expires: <http-date>
```

Directives
----------

<http-date>

An HTTP-date timestamp.

Exemples
--------
```

Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Caching # field.expires |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Cache-Control`
* `Age`
Access-Control-Allow-Origin
===========================

L'entête **`Access-Control-Allow-Origin`** renvoie une réponse indiquant si les ressources peuvent être partagées avec une origine donnée.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntaxe
-------
```

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null
```

Directives
----------

\*

Pour les demandes sans informations d'identification, le serveur peut spécifier « \* » comme un caractère générique, permettant ainsi à n'importe quelle origine d'accéder à la ressource.

<origin>

Spécifie un URI qui peut accéder à la ressource. Il n'est possible de spécifier qu'une seule origine.

Exemples
--------

Pour permettre à n'importe quelle ressource d'accéder à vos ressources, vous pouvez indiquer :
```

Access-Control-Allow-Origin: *
```


Pour permettre `https://developer.mozilla.org` d'accéder à vos ressources, vous pouvez indiquer :
```

Access-Control-Allow-Origin: https://developer.mozilla.org
```

### CORS et le cache

Si le serveur spécifie un hôte d'origine plutôt que "\*", il doit également inclure "*Origin*" dans l'en-tête de réponse "*Vary*" pour indiquer aux clients que les réponses du serveur seront différentes en fonction de la valeur de la demande d'origine entête.
```

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin
```

Spécifications
--------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-origin |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Origin`
* `Vary`
DNT
===

Le header de requête **`DNT`** (**D**o **N**ot **T**rack) indique que les préférences de l'utilisateur concernant le suivi publicitaire. Il permet aux utilisateurs d'indiquer s'ils préfèrent leur vie privée au lieu d'un contenu personnalisé.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntaxe
-------
```

DNT: 0
DNT: 1
```

Directives
----------

0

L'utilisateur préfère autoriser son suivi sur le site cible.

1

L'utilisateur préfère ne pas être suivi sur le site cible.

Exemples
--------

### Lire le statut Do Not Track avec JavaScript

La préférence de l'utilisateur pour DNT peut également être lue depuis JavaScript en utilisant la proriété `Navigator.doNotTrack` :


```js
navigator.doNotTrack; // "0" ou "1"
```

Spécifications
--------------

#### No specification found

No specification data found for `http.headers.DNT`.  
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voyez aussi
-----------

* `Navigator.doNotTrack`
* `Tk` header
* *Do Not Track* sur Wikipédia
* What Does the "Track" in "Do Not Track" Mean? – EFF
* donottrack.us
* DNT browser settings help:
    + Firefox
    + Chrome
Age
===

L'entête HTTP `Age` indique le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy.

Sa valeur est généralement proche de zéro. Elle vaut 0 lorsque la ressource vient d'être rapatriée du serveur d'origine; autrement, sa valeur équivaut à la différence entre la date courante du proxy et la valeur de l'entête `Date` inclus dans la réponse HTTP.

|  |  |
| --- | --- |
| Type d'entête | Entête de réponse |
| Nom d'entête interdit | non |

Syntaxe
-------
```

Age: <valeur-en-secondes>
```

Directive
---------

<valeur-en-secondes>

Un entier positif indiquant le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy.

Exemple
-------
```

Age: 24
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Caching # field.age |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Cache-Control`
* `Expires`
Vary
====

L'en-tête HTTP **`Vary`** détermine comment les en-têtes de requêtes futures sont associés pour décider si une réponse en cache peut être réutilisée plutôt que de solliciter à nouveau le serveur d'origine. Il est utilisé par le serveur pour indiquer quels en-têtes sont utilisés pour représenter une resource dans un algorithme de négociation de contenu.

L'en-tête `Vary` doit être renseigné de manière identique sur une réponse `304` `Not Modified` à ce qu'elle aurait été sur la réponse `200` `OK` correspondante.

|  |  |
| --- | --- |
| Type d'en-tête | Response header |
| Forbidden header name | non |

Syntaxe
-------
```

Vary: *
Vary: <header-name>, <header-name>, ...
```

Directives
----------

\*

Chaque requête pour une URL doit être traitée comme une requête unique à ne pas mettre en cache. Une meilleure manière de l'indiquer est d'utiliser `Cache-Control``: private`, qui est plus clair à lire et signale aussi que l'objet ne doit jamais être mis en cache.

<header-name>

Une liste séparé par des virgules de noms d'en-tête à prendre en compte lorsqu'il est décidé si une réponse en cache peut être utilisée ou non.

Examples
--------

### Service dynamique

Lorsque l'en-tête `Vary: User-Agent` est utilisée, les serveurs de cache doivent prendre en compte l'agent de l'utilisateur pour décider de servir la page depuis le cache ou non. Par exemple, si vous servez du contenu différent pour les utilisateurs sur mobile, il aide à éviter qu'une version ordinateur de votre site ne soit distribuée à un utilisateur sur mobile. Il peut aider google et d'autres moteurs de recherche à prendre en compte la version pour mobile d'un site, ainsi que de signaler que le Cloaking n'est pas intentionel.
```

Vary: User-Agent
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.vary |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Cache-Control`
* `User-Agent` (en-US)
* Best Practices for Using the Vary Header – fastly.com
Tk
==

L'entête de réponse `Tk` indique le statut de suivi (tracking) qui s'applique à la demande correspondante.

|  |  |
| --- | --- |
| Type d'entête | Response header |
| Forbidden header name | non |

Syntaxe
-------
```

Tk: !  (en construction)
Tk: ?  (dynamique)
Tk: G  (passerelle ou multiples parties)
Tk: N  (pas de suivi)
Tk: T  (suivi)
Tk: C  (suivi avec consentement)
Tk: P  (consentement potentiel)
Tk: D  (ne tient pas compte de DNT)
Tk: U  (mis à jour)
```

### Directives

!

En construction. Le serveur d'origine teste actuellement sa communication de l'état du suivi.

?

Dynamique. Le serveur d'origine a besoin de plus d'informations pour déterminer l'état du suivi.

G

Passerelle ou multiples parties. Le serveur fait office de passerelle vers un échange impliquant plusieurs parties.

N

Pas de suivi.

T

Suivi.

C

Suivi avec consentement. Le serveur d'origine pense avoir reçu un consentement préalable pour le suivi de cet utilisateur, user-agent ou appareil.

P

Consentement potentiel. Le serveur d'origine ne sait pas, en temps réel, s'il a reçu un consentement préalable pour le suivi de cet utilisateur, user-agent ou appareil, mais promet de ne pas utiliser ou partager de données DNT:1 jusqu'à ce que ce consentement ait été déterminé. Il promet en outre de supprimer ou d'anonymiser de manière permanente dans les 48 heures toute donnée DNT:1 reçue pour laquelle ce consentement n'a pas été reçu.

D

Ne tient pas compte de DNT. Le serveur d'origine ne peut ou ne veut pas respecter une préférence de suivi reçue de l'user-agent demandeur.

U

Mis à jour. La demande a entraîné un changement potentiel du statut de suivi applicable à cet utilisateur, user-agent ou appareil.

Exemple
-------

Un entête `Tk` pour une ressource qui prétend ne pas être suivie :
```

Tk: N
```

Spécifications
--------------

#### No specification found

No specification data found for `http.headers.Tk`.  
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `DNT` header
* `Navigator.doNotTrack`
Content-Type
============

L'en-tête **`Content-Type`** sert à indiquer le type MIME de la ressource.

Dans les réponses, un en-tête `Content-Type` indique au client le type de contenu réellement renvoyé. Il peut arriver que les navigateurs cherchent à détecter le type MIME du contenu en l'inspectant plutôt qu'en respectant la valeur de cet en-tête. Pour empêcher ce comportement, on peut paramétrer l'en-tête `X-Content-Type-Options` avec la valeur `nosniff`.

Dans les requêtes, (telles que `POST` ou `PUT`), le client indique au serveur quel type de données a réellement été envoyé.

|  |  |
| --- | --- |
| Type d'en-tête | En-tête d'entité |
| Nom d'en-tête interdit | Non |
| En-tête de réponse simple pour le CORS | Oui |

Syntaxe
-------
```

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
```

Directives
----------

`media-type`

Le type MIME de la ressource ou des données.

`charset`

L'encodage utilisé pour les caractères des données.

`boundary`

Pour les entités fragmentées (*multipart*), la directive `boundary` est nécessaire. Elle ne se termine pas par un espace et est composée de 1 à 70 caractères qui proviennent d'un ensemble de caractères connus pour ne pas être transformés/modifiés par les différents composants au travers desquels transitent les emails. Cette directive est utilisée afin d'encapsuler les limites des différents fragments d'un message fragmenté.

Exemples
--------

### `Content-Type` dans les formulaires HTML

Dans une requête `POST`, qui vient d'une soumission d'un formulaire HTML, le `Content-Type` de la requête est précisé par l'attribut `enctype` de l'élément `<form>`.


```html
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="du texte" />
  <input type="file" name="monFichier" />
  <button type="submit">Envoyer</button>
</form>
```


La requête ressemble à peu près à ceci (les en-têtes moins intéressants ont été ici volontairement omis) :
```

POST /toto HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"

---------------------------974767299852498929531610575

du texte par ici

---------------------------974767299852498929531610575
Content-Disposition: form-data; name="monFichier"; filename="toto.txt"
Content-Type: text/plain

(contenu du fichier envoyé en ligne toto.txt)

---------------------------974767299852498929531610575
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.206 |
| HTTP Semantics # field.content-type |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Accept` et `Accept-Charset`
* `Content-Disposition`
* `206` `Partial Content`
* `X-Content-Type-Options`
Content-Length
==============

L'en-tête (*header*) **`Content-Length`** indique la taille en octets (exprimée en base 10) du corps de la réponse envoyée au client.

|  |  |
| --- | --- |
| Type d'en-tête | Entity header |
| Forbidden header name | oui |

Syntaxe
-------
```

Content-Length: <longueur>
```

Directives
----------

<longueur>

La longueur en octet (en base 10).

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.content-length |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Transfer-Encoding` (en-US)