Aller au contenu principal

6. Syntax (Syntaxe)

Cette section définit la syntaxe du champ d'en-tête de réponse HTTP Strict-Transport-Security et de ses directives, et fournit quelques exemples.

Ensuite, la section 7 ("Server Processing Model") détaille comment les hôtes utilisent ce champ d'en-tête pour déclarer leur politique HSTS, et la section 8 ("User Agent Processing Model") détaille comment les agents utilisateurs traitent le champ d'en-tête et appliquent la politique HSTS.

6.1. Strict-Transport-Security HTTP Response Header Field (Champ d'En-tête de Réponse HTTP Strict-Transport-Security)​

Le champ d'en-tête de réponse HTTP Strict-Transport-Security (champ d'en-tête STS) indique au UA qu'il doit (MUST) appliquer une politique HSTS à l'hôte qui a émis le message de réponse contenant ce champ d'en-tête.

La syntaxe ABNF (Forme de Backus-Naur Augmentée (Augmented Backus-Naur Form)) du champ d'en-tête STS est la suivante. Elle est basée sur la syntaxe générique définie dans la section 2 de [RFC2616] (qui inclut le concept d'"espace blanc linéaire implicite (implied linear whitespace)", également connu sous le nom d'"*LWS implicite").

Strict-Transport-Security = "Strict-Transport-Security" ":"
                            [ directive ]  *( ";" [ directive ] )

directive                 = directive-name [ "=" directive-value ]
directive-name            = token
directive-value           = token | quoted-string

où :

token          = <token, defined in [RFC2616], Section 2.2>
quoted-string  = <quoted-string, defined in [RFC2616], Section 2.2>

Les deux directives définies dans cette spécification sont décrites ci-dessous. Les exigences globales pour les directives sont :

  1. L'ordre dans lequel les directives apparaissent n'est pas important.

  2. Toutes les directives doivent (MUST) apparaître une seule fois dans le champ d'en-tête STS. Les directives sont soit optionnelles soit requises, comme stipulé dans leur définition.

  3. Les noms de directive sont insensibles à la casse.

  4. Les UA doivent (MUST) ignorer tout champ d'en-tête STS contenant une directive ou d'autres données de valeur de champ d'en-tête qui ne se conforment pas à la syntaxe définie dans cette spécification.

  5. Si le champ d'en-tête STS contient une directive que le UA ne reconnaît pas, le UA doit (MUST) ignorer la directive non reconnue, et si le champ d'en-tête STS satisfait autrement aux exigences ci-dessus (1 à 4), le UA doit (MUST) traiter les directives reconnues.

Des directives supplémentaires étendant les fonctionnalités sémantiques du champ d'en-tête STS peuvent être définies dans d'autres spécifications, à condition qu'un registre soit défini pour elles (avec la définition de politique IANA de Révision IETF [RFC5226]).

NOTE : De telles directives futures seront ignorées par les UA qui n'implémentent que cette spécification, ainsi que par les UA généralement non conformes. Voir la section 14.2 ("Non-Conformant User Agent Implications") pour une discussion plus approfondie.

6.1.1. The max-age Directive (La Directive max-age)​

La directive "max-age" requise (REQUIRED) spécifie le nombre de secondes, après la réception du champ d'en-tête STS, pendant lesquelles le UA considère l'hôte (à partir duquel le message a été reçu) comme un hôte HSTS connu. Voir également la section 8.1.1 ("Noting an HSTS Host - Storage Model"). La production delta-seconds est spécifiée dans [RFC2616].

La syntaxe de la valeur requise (REQUIRED) de la directive max-age (après l'échappement de la chaîne entre guillemets si nécessaire) est définie comme suit :

max-age-value = delta-seconds

delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

NOTE : Une valeur max-age de zéro (c'est-à-dire, "max-age=0") signale au UA de cesser de traiter l'hôte comme un hôte HSTS connu, y compris la directive includeSubDomains si elle a été affirmée pour cet hôte HSTS. Voir également la section 8.1 ("Strict-Transport-Security Response Header Field Processing").

6.1.2. The includeSubDomains Directive (La Directive includeSubDomains)​

La directive optionnelle (OPTIONAL) "includeSubDomains" est une directive sans valeur qui, si elle est présente (c'est-à-dire, elle est "affirmée"), signale au UA que la politique HSTS s'applique à cet hôte HSTS ainsi qu'à tous les sous-domaines du nom de domaine de l'hôte.

6.2. Examples (Exemples)​

Le champ d'en-tête HSTS suivant stipule que la politique HSTS reste valable pendant un an (environ 31536000 secondes dans une année), et que la politique ne s'applique qu'au domaine de l'hôte HSTS qui l'a émis :

Strict-Transport-Security: max-age=31536000

Le champ d'en-tête HSTS suivant stipule que la politique HSTS reste valable pendant environ six mois, et que la politique s'applique au domaine de l'hôte HSTS émetteur et à tous ses sous-domaines :

Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Dernière mise à jour le