recursal/MDN huggingface dataset:
Content-Encoding
================

L'en-tête **`Content-Encoding`** indique la compression utilisée sur le média contenu dans le corps de la requête. Il permet au client de savoir comment décoder le contenu afin d'obtenir le type de média référencé par l'entête `Content-Type`.

Il est recommandé de compresser les données autant que possible et donc d'utiliser cet en-tête. Toutefois, certains types de fichiers, comme les images jpeg, sont déjà compressés. Parfois, l'utilisation d'une compression supplémentaire ne réduit pas la taille de la chage utile et peut même la rendre plus longue.

|  |  |
| --- | --- |
| Type d'en-tête | En-tête d'entité |
| Nom d'en-tête interdit | Non |

Syntaxe
-------
```

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

// Plusieurs valeurs selon l'ordre dans lequel ils ont été appliqués
Content-Encoding: gzip, identity
Content-Encoding: deflate, gzip
```

Directives
----------

`gzip`

Un format utilisant le codage Lempel-Ziv (LZ77), avec un CRC de 32 bits. Il s'agit du format original pour le programme UNIX *gzip*. La norme HTTP/1.1 recommande également que les serveurs prenant en charge cet encodage reconnaissent `x-gzip` comme alias, à des fins de compatibilité.

`compress`

Un format utilisant l'algorithme Lempel-Ziv-Welch (LZW). Le nom de la valeur a été tiré du programme de compression UNIX, qui a mis en œuvre cet algorithme. Comme le programme de compression, qui a disparu de la plupart des distributions UNIX, ce codage de contenu n'est pas utilisé par de nombreux navigateurs aujourd'hui, en partie à cause d'un problème de brevet (il a expiré en 2003).

`deflate`

Utilisant la structure zlib (définie dans la RFC 1950) avec l'algorithme de compression *deflate* (défini dans la RFC 1951).

`identity`

Indicates the identity function (c'est-à-dire qu'il n'y a eu aucune compression ou modification). Sauf mention contraire, cette valeur est toujours considérée comme acceptable.

`br`

Un format utilisant l'algorithme de Brotli.

Exemples
--------

### Compression avec gzip

Côté client, on peut fournir la liste des mécanismes de compression pris en charge en envoyant l'en-tête `Accept-Encoding` lors de la négociation de l'encodage.
```

Accept-Encoding: gzip, deflate
```


Le serveur répondra avec le schéma utilisé avec l'en-tête de réponse `Content-Encoding`.
```

Content-Encoding: gzip
```


À noter que le serveur n'est pas obligé d'utiliser de méthode de compression. La compression dépend fortement des paramètres du serveur et des modules de serveur utilisés.

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

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

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

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

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

* `Accept-Encoding`
* `Transfer-Encoding` (en-US)
Date
====

L'en-tête général HTTP **`Date`** contient la date et l'heure d'origine du message.

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

Syntaxe
-------
```

Date: <day-name>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
```

Directives
----------

<day-name>

L'un des mots "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" ou "Sun" (sensible à la casse).

<day>

Numéro de jour à 2 chiffres, par ex. "04" ou "23".

<month>

L'un des mots "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).

<year>

Numéro d'année à 4 chiffres, par exemple "1990" ou "2018".

<hour>

Numéro d'heure à 2 chiffres, par exemple "09" or "23".

<minute>

Numéro d'heure à 2 chiffres, par exemple "04" or "59".

<second>

Numéro de seconde à 2 chiffres, par exemple "04" or "59".

GMT

Temps sur le Méridien de Greenwich. Les dates HTTP sont toujours exprimées en GMT, jamais en heure locale.

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

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

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

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

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

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

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

* `Age`
Location
========

L'en-tête de réponse `Location` indique l'URL vers laquelle rediriger une page. Il a un sens seulement lorsqu'il est servi avec une réponse d'état `3xx` (redirection) ou `201` (créé).

En cas de redirection, la méthode HTTP utilisée pour la nouvelle requête de récupération de la page pointée par `Location` dépend la méthode d'origine et du type de redirection :

* Si les réponses `303` (Voir Aussi) conduisent toujours à l'utilisation d'une méthode `GET`, `307` (Redirection Temporaire) et `308` (Redirection Permanente) ne modifient pas la méthode utilisée dans la demande d'origine;
* `301` (Redirection permanente) et `302` (Trouvé) ne change pas la méthode la plupart du temps, bien que les user-agents plus anciens puissent.

Toutes les réponses avec l'un de ces codes d'état envoient un en-tête `Location`.

En cas de création de ressource, il indique l'URL de la ressource nouvellement créée.

`Location` et `Content-Location` (en-US) sont différents : `Location` indique la cible d'une redirection (ou l'URL d'une ressource nouvellement créée), tandis que `Content-Location` (en-US) indique l'URL directe à utiliser pour accéder à la ressource lorsque la négociation de contenu a eu lieu, sans qu'il soit nécessaire de poursuivre la négociation de contenu. L'emplacement est un en-tête associé à la réponse, tandis que `Content-Location` (en-US) est associé à l'entité renvoyée.

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

Syntaxe
-------
```

Location: <url>
```

Directives
----------

<url>

Une URL relative (à l'URL de la demande) ou absolue.

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

Location: /index.html
```

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

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

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

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

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

* `Content-Location` (en-US)
* État des réponses, y compris un en-tête `Location` : `201`, `301`, `302`, `303`, `307`, `308`.
Serveur
=======

Le paramètre d'entête **`Server`** contient des informations à propos du système (ou sous-système) en place sur le serveur qui s'occupe de la requête.

Il est préférable d'éviter les valeurs excessivement longues et/ou détaillées : elles peuvent révéler des détails internes qui pourraient rendre (un peu) plus facile une attaque et l'exploitation d'une éventuelle faille de sécurité.

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

Syntaxe
-------
```

Server: <valeur>
```

Directives
----------

<valeur>

Le nom du système (ou sous-système) qui gère les requêtes.

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

Server: Apache/2.4.1 (Unix)
```

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

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

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

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

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

* `Allow`
Host
====

L'en-tête de requête **`Host`** spécifie le nom de domaine du serveur (pour de l'hébergement virtuel), et (optionnellement) le numéro du port TCP sur lequel le serveur écoute.

Si aucun port n'est donné, le port par défaut du service demandé sera utilisé (par exemple, "80" pour une URL HTTP).

Un champ d'en-tête `Host` doit être envoyé dans tous les messages de requête HTTP/1.1. Un code HTTP `400` (Bad Request) sera envoyé à tout message de requette HTTP/1.1 ne contenant pas un champ d'en-tête `Host` ou qui en contient plus d'un.

|  |  |
| --- | --- |
| Type d'en-tête | En-tête de requête |
|  Nom d'en-tête interdit  | Oui |

Syntaxe
-------
```

Host: <host>:<port>
```

Directives
----------

<host>

le nom de domaine du serveur (pour de l'hébergement virtuel).

<port> Facultatif

numéro de port TCP sur lequel le serveur écoute.

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

Host: developer.mozilla.org
```

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

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

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

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

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

* `400`
* `<base>`
Referer
=======

L'en-tête de requête **`Referer`** contient l'adresse de la page web précédente à partir de laquelle un lien a été suivi pour demander la page courante. L'en-tête `Referer` permet aux serveurs d'identifier la provenance des visiteurs d'une page et cette information peut être utilisée à des fins d'analyse, de journalisation ou pour améliorer la politique de cache par exemple.

**Attention :** Bien que cet en-tête puisse être utilisé à de nombreuses fins légitimes, il peut avoir des effets indésirables sur la sécurité et la vie privée. Voir la page Questions de sécurité et de vie privée : quid de l'en-tête `referer` pour plus d'informations et des méthodes d'atténuation.

Note : le terme `referer` est orthographié ainsi bien qu'il s'agisse d'une erreur à partir du mot anglais "*referrer*". Voir la page Wikipédia sur le référent et la note sur la graphie de *referer* pour plus de détails.

Un en-tête `Referer` n'est pas envoyé par les navigateurs si :

* La ressource d'origine est un fichier local ou une URI de données.
* Une requête non sécurisée HTTP est utilisée alors que la page référente avait été reçue via un protocole sécurisé (HTTPS).

|  |  |
| --- | --- |
| Type d'en-tête | En-tête de requête |
| Nom d'en-tête interdit | Oui |

Syntaxe
-------
```

Referer: <url>
```

Directives
----------

`<url>`

Une adresse absolue ou partielle de la page web à partir de laquelle la requête vers la page courante a été émise. Les fragements d'URL (i.e. "#section") et les informations d'utilisateurs (i.e. "username:password" dans "https://username:password@example.com/toto/truc/") ne sont pas incluses.

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

Referer: https://developer.mozilla.org/fr/docs/Web/JavaScript
```

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

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

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

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

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

* Référent sur Wikipédia
* `Referrer-Policy`
Content-Language
================

L'en-tête **`Content-Language`** est utilisé pour décrire quels langages sont destinés au public, de sorte que cela permette à l'utilisateur de se différencier en fonction de la langue préférée des utilisateurs.

Par exemple, si "`Content-Language: de-DE`" est mis en place, cela signifie que la page est destinée à un public parlant l'allemand (par contre, cela n'indique pas que la page est écrite en allemand. Par exemple, elle pourrait être écrite en anglais dans le cadre d'un cours de langue destiné aux allemands).

Si l'en-tête `Content-Language` n'est pas spécifié, par défaut, cela signifie que la page est destinée à tout public de langue. Plusieurs tags de langue sont également possibles, ainsi que la mise en place de l'en-tête `Content-Language` pour dfférents types de médias, et pas seulement pour les documents texte.

|  |  |
| --- | --- |
| Type d'en-tête | Entity header |
| Forbidden header name | Non |
| CORS-safelisted response-header | Oui |
| CORS-safelisted request-header | 
 Oui, avec comme restriction supplémentaire que les valeurs ne peuvent
 contenir que les
 caractères `0-9`, `A-Z`, `a-z`,
 l'espace ou `*,-.;=`.
  |

Syntaxe
-------
```

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA
```

Directives
----------

`language-tag`

Plusieurs tags de langue sont séparés par paragraphe. Chaque tag de langue est une séquence d'un ou plusieurs sous-tags insensibles à la casse, chacun séparé par un tiret ("`-`", `%x2D`). Dans la plupart des cas, un tag de langue se compose d'un sous-tag de langue principal qui identifie une large famille de langues connexes (par exemple, «en» = anglais), suivi éventuellement d'une série de sous-tags qui affinent ou réduisent la variété de langue. (par exemple, "en-CA" = la variété d'anglais telle que communiquée au Canada).


**Note :** Les tags de langues sont formellement définis dans la RFC 5646, qui repose sur la norme ISO 639 (très souvent la liste de codes ISO 639-1) pour les codes de langue à utiliser.

Exemples
--------

### Indiquer la langue dans laquelle un document est écrit

L'attribut global `lang` est utilisé sur des éléments HTML pour indiquer la langue d'une page HTML entière ou une partie de celle-ci.


```html
<html lang="de"></html>
```


**N'utilisez pas** le meta tag comme ceci pour déclarer la langue d'un document:


```html
<!-- /!\ C'est une mauvaise pratique -->
<meta http-equiv="content-language" content="de" />
```

### Indiquer un public cible pour une ressource

L'en-tête `Content-Language` est utilisé pour spécifier le public destiné à la page, et peut indiquer si cela est plus qu'une seule langue.
```

Content-Language: de, en
```

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

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

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

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

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

* `Accept-Language`
* HTTP headers, meta elements and language information
* HTML `lang` attribute
Trailer
=======

L'en-tête **Trailer** permet à l'expéditeur d'inclure des champs supplémentaires à la fin des blocs de messages pour fournir des métadonnées supplémentaires qui peuvent être générées de manière dynamique pendant que le corps du message sera envoyé, il peut s'agir de la vérification de l'intégrité du message, une signature numérique, ou encore un statut après le traitement.

**Note :** L'en-tête `TE` (en-US) de la requête devra être définie en tant que "trailers" pour autoriser les champs de type "trailer".


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

Syntaxe
-------
```

Trailer: header-names
```

Directives
----------

`header-names`

HTTP header fields which will be present in the trailer part of chunked messages. These header fields are **disallowed**:

* message framing headers (e.g., `Transfer-Encoding` (en-US) and `Content-Length`),
* routing headers (e.g., `Host`),
* request modifiers (e.g., controls and conditionals, like `Cache-Control`, `Max-Forwards` (en-US), or `TE` (en-US)),
* authentication headers (e.g., `Authorization` or `Set-Cookie`),
* or `Content-Encoding`, `Content-Type`, `Content-Range` (en-US), and `Trailer` itself.

Exemple
-------

### Encodage de transfert en bloc en utilisant les en-têtes "trailer"

Dans cet exemple, l'en-tête `Expires` est utilisée à la fin du bloc du message et sert en tant qu'un "trailing header".
```

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Expires

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n
Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

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

| Specification |
| --- |
| HTTP Semantics # field.trailer |
| HTTP/1.1 # chunked.trailer.section |

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

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

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

* `Transfer-Encoding` (en-US)
* `TE` (en-US)
* Encodage de transfert en bloc
Link
====

L'en-tête d'entité HTTP **`Link`** permet de sérialiser un ou plusieurs liens dans un en-tête HTTP. Il est sémantiquement équivalent à l'élément HTML `<link>`.

Syntaxe
-------
```

Link: <uri-reference>; param1=value1; param2="value2"
```


`<uri-reference>`

L'URI de référence qui doit être indiquée entre `<` et `>`.

### Paramètres

L'en-tête `Link` contient des paramètres séparés par un `;` et sont équivalents aux attributs de l'élément `<link>`.

Exemples
--------

L'URI (absolue ou relative) doit être déclarée entre `<` et `>` :


```http
Link: <https://example.com>; rel="preconnect"
```



```http
Link: https://bad.example; rel="preconnect"
```

### Déclarer plusieurs liens

Il est possible de spécifier plusieurs liens, en les séparant par des virgules :
```

Link: <https://one.example.com>; rel="preconnect", <https://two.example.com>; rel="preconnect", <https://three.example.com>; rel="preconnect"
```

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

| Specification |
| --- |
| Web Linking # header |

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

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

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

* `103 Early Hints`
* `<link>`
Accept
======

Le paramètre d'entête de requête HTTP **`Accept`** indique quels sont les types de contenu, exprimés sous la forme de types MIME, que le client sera capable d'interpréter. Par le biais de la résolution de contenu -(content negotiation), le serveur sélectionne ensuite une proposition parmi toutes, l'utilise et informe le client de son choix avec l'entête de réponse `Content-Type`. Les navigateurs fixent des valeurs adéquates pour cet entête selon le contexte où la requête a été exécutée : selon que l'utilisateur souhaite récupérer une feuille de style css, ou qu'il souhaite récupérer une image, une vidéo ou un script, la valeur fixée pour la requête ne sera pas la même.

|  |  |
| --- | --- |
| Type d'entête | Request header |
| Forbidden header name | non |
| CORS-safelisted request-header | oui |

Syntaxe
-------
```

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

// Types multiples, pondérés quality value par la syntaxe :
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

Directives
----------

`<MIME_type>/<MIME_subtype>`

Un type MIME unique et déterminé MIME type, comme par exemple `text/html`.

`<MIME_type>/*`

un type MIME type ne comprenant pas de sous-type. `image/*` prendra en charge `image/png`, `image/svg`, `image/gif` et tous autres types d'image.

`*/*`

Tout type MIME

`;q=` (facteur de pondération q)

N'importe quelle valeur utilisée est placée selon un ordre de préférence exprimé par une valeur de qualité (quality value) relative appelée le *poids*.

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

Accept: text/html

Accept: image/*

Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

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

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

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

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

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

* HTTP content negotiation
* Entête avec le résultat de la résolution de contenu : `Content-Type`
* Autres entêtes similaires : `TE` (en-US), `Accept-Encoding`, `Accept-Charset`, `Accept-Language`
CSP : manifest-src
==================

La directive HTTP `Content-Security-Policy` **`manifest-src`** spécifie le manifeste qui peut être appliqué à la ressource.

|  |  |
| --- | --- |
| Version de CSP | 3 |
| Type de directive | Directive de récupération |
| Utilisation de `default-src` par défaut | Oui, si cette directive est absente, l'agent utilisateur consultera la directive `default-src`. |

Syntaxe
-------

Une ou plusieurs sources peuvent être autorisées pour cette directive :


```http
Content-Security-Policy: manifest-src <source>;
Content-Security-Policy: manifest-src <source> <source>;
```

### Sources

`<source>` peut être n'importe quelle valeur parmi celles énumérées dans l'article sur les valeurs sources CSP (en-US).

On notera que cet ensemble de valeurs peut être utilisé pour toutes les directives de récupération (et pour certaines autres directives (en-US)).

Exemples
--------

### Cas de violation

Soit cet en-tête CSP :


```http
Content-Security-Policy: manifest-src https://example.com/
```


Cet élément `<link>` sera bloqué et ne se chargera pas :


```html
<link rel="manifest" href="https://not-example.com/manifest" />
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-manifest-src |

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

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

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

* `Content-Security-Policy`
* Les manifestes d'application web
* `<link>`
CSP : frame-src
===============

La directive HTTP `Content-Security-Policy` **`frame-src`** spécifie les sources valides pour les contextes de navigation imbriqués chargés avec des éléments tels que `<frame>` et `<iframe>`.

|  |  |
| --- | --- |
| Version de CSP | 1 |
| Type de directive | Directive de récupération |
| Utilisation de `default-src` par défaut | Si cette directive est absente, l'agent utilisateur consultera la directive `child-src`, qui a pour valeur par défaut celle de la directive `default-src`. |

Syntaxe
-------

Une ou plusieurs sources peuvent être autorisées pour cette directive :


```http
Content-Security-Policy: frame-src <source>;
Content-Security-Policy: frame-src <source> <source>;
```

### Sources

`<source>` peut être n'importe quelle valeur parmi celles énumérées dans l'article sur les valeurs sources CSP (en-US).

On notera que cet ensemble de valeurs peut être utilisé pour toutes les directives de récupération (et pour certaines autres directives (en-US)).

Exemples
--------

### Cas de violation

Soit cet en-tête CSP :


```http
Content-Security-Policy: frame-src https://example.com/
```


L'élément `<iframe>` suivant sera bloqué et ne se chargera pas :


```html
<iframe src="https://not-example.com/"></iframe>
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-frame-src |

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

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

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

* `Content-Security-Policy`
* `<frame>` et `<iframe>`
CSP : worker-src
================

La directive HTTP `Content-Security-Policy` **`worker-src`** spécifie les sources valides pour les scripts de type `Worker`, `SharedWorker` et `ServiceWorker`.

|  |  |
| --- | --- |
| Version de CSP | 3 |
| Type de directive | Directive de récupération |
| Valeur par défaut | Si cette directive est absente, l'agent utilisateur consultera d'abord la directive `child-src`, puis la directive `script-src` et enfin la directive `default-src`. |

Syntaxe
-------

Une ou plusieurs sources peuvent être autorisées pour cette directive :


```http
Content-Security-Policy: worker-src <source>;
Content-Security-Policy: worker-src <source> <source>;
```

### Sources

`<source>` peut être n'importe quelle valeur parmi celles énumérées dans l'article sur les valeurs sources CSP (en-US).

On notera que cet ensemble de valeurs peut être utilisé pour toutes les directives de récupération (et pour certaines autres directives (en-US)).

Exemples
--------

### Cas de violation

Soit cet en-tête CSP :


```bash
Content-Security-Policy: worker-src https://example.com/
```


`Worker`, `SharedWorker` et `ServiceWorker` seront bloqués et ne seront pas chargés :


```html
<script>
 let blockedWorker = new Worker("data:application/javascript,...");
 blockedWorker = new SharedWorker("https://not-example.com/");
 navigator.serviceWorker.register("https://not-example.com/sw.js");
</script>
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-worker-src |

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

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

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

* `Content-Security-Policy`
* Utiliser CSP pour les *Web Workers*
* `Worker`, `SharedWorker`, `ServiceWorker`