7. Server Processing Model (Modèle de Traitement du Serveur)

Cette section décrit le modèle de traitement pour les implémentations d'hôtes HSTS. Le modèle comporte deux aspects : le premier concerne les règles de traitement pour les messages de requête HTTP reçus via un transport sécurisé (TLS [RFC5246] ou SSL [RFC6101]; voir également la section 14.1 ("Underlying Secure Transport Considerations")), et le second concerne les règles de traitement pour les messages de requête HTTP reçus via un transport non sécurisé (par exemple, TCP).

7.1. HTTP-over-Secure-Transport Request Type (Type de Requête HTTP sur Transport Sécurisé)

En répondant à une requête HTTP communiquée via un transport sécurisé, un hôte HSTS devrait (SHOULD) inclure dans son message de réponse un champ d'en-tête STS qui doit (MUST) satisfaire la syntaxe spécifiée dans la section 6.1 ("Strict-Transport-Security HTTP Response Header Field"). Si un champ d'en-tête STS est inclus, l'hôte HSTS doit (MUST) inclure un seul tel champ d'en-tête.

Établir un hôte donné comme hôte HSTS connu, dans le contexte d'un UA donné, peut (MAY) être accompli via HTTP fonctionnant sur un transport sécurisé en retournant correctement (conformément à cette spécification) au moins un champ d'en-tête STS valide au UA. D'autres mécanismes peuvent (MAY) également être utilisés, par exemple, une liste préchargée côté client d'hôtes HSTS connus; voir par exemple la section 12 ("User Agent Implementation Advice").

NOTE : Inclure le champ d'en-tête STS est spécifié comme "devrait (SHOULD)" pour s'adapter à diverses configurations de mise en cache côté serveur et côté réseau et d'équilibrage de charge, dans lesquelles il peut être difficile d'émettre uniformément le champ d'en-tête STS au nom d'un hôte HSTS donné.

7.2. HTTP Request Type (Type de Requête HTTP)

Si un hôte HSTS reçoit un message de requête HTTP via un transport non sécurisé, il devrait (SHOULD) envoyer un message de réponse HTTP contenant un code d'état indiquant une redirection permanente, tel que le code d'état 301 (section 10.3.2 de [RFC2616]), et une valeur de champ d'en-tête Location contenant soit l'URI de requête valide d'origine de la requête HTTP (voir section 9 ("Constructing an Effective Request URI")), modifié au besoin pour avoir un schéma d'URI de "https", soit un URI avec un schéma d'URI de "https" généré selon la politique locale.

NOTE : Le comportement ci-dessus est "devrait (SHOULD)" plutôt que "doit (MUST)" pour les raisons suivantes :

• Risques de redirection non sécurisée à sécurisée côté serveur [OWASP-TLSGuide].

• Caractéristiques de déploiement du site. Par exemple, un site contenant des composants tiers peut ne pas fonctionner correctement lors de l'exécution d'une redirection non sécurisée à sécurisée côté serveur lorsqu'il est accédé via un transport non sécurisé, mais fonctionne correctement lorsqu'il est accédé uniformément via un transport sécurisé. Ce dernier est la situation lorsqu'un UA prenant en charge HSTS a déjà (par quelque moyen que ce soit, par exemple, une interaction préalable ou la configuration du UA) noté le site comme hôte HSTS connu.

Un hôte HSTS ne doit pas (MUST NOT) inclure le champ d'en-tête STS dans les réponses HTTP transmises via un transport non sécurisé.