Aller au contenu principal

9. Constructing an Effective Request URI (Construction d'un URI de Requête Effectif)

Cette section spécifie comment les hôtes HSTS doivent construire l'URI de requête effectif pour les requêtes HTTP reçues.

Les requêtes HTTP ne portent généralement pas l'absoluteURI de la ressource cible; au lieu de cela, l'URI doit être déduit du Request-URI, du champ d'en-tête Host et du contexte de connexion ([RFC2616], sections 3.2.1, 5.1.2 et 5.2). Le résultat de ce processus est appelé l'"URI de requête effectif (effective request URI, ERU)". La "ressource cible (target resource)" est la ressource identifiée par l'URI de requête effectif.

9.1. ERU Fundamental Definitions (Définitions Fondamentales de l'ERU)​

La première ligne Request-Line d'un message de requête HTTP est spécifiée par l'ABNF suivant de la section 5.1 de [RFC2616] :

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

Le Request-URI dans le Request-Line est spécifié par l'ABNF suivant de la section 5.1.2 de [RFC2616] :

Request-URI    = "*" | absoluteURI | abs_path | authority

Le champ d'en-tête de requête Host est spécifié par l'ABNF suivant de la section 14.23 de [RFC2616] :

Host = "Host" ":" host [ ":" port ]

9.2. Determining the Effective Request URI (Détermination de l'URI de Requête Effectif)​

Si le Request-URI est un absoluteURI, alors l'URI de requête effectif est le Request-URI.

Si le Request-URI utilise la forme abs_path ou astérisque, et que le champ d'en-tête Host est présent, alors l'URI de requête effectif est construit en concaténant ce qui suit :

  • Le nom de schéma : "http" si la requête est reçue via une connexion TCP non sécurisée, ou "https" lorsqu'elle est reçue via une connexion TCP protégée par TLS/SSL, et

  • La séquence d'octets "://", et

  • L'hôte et le port (s'il est présent) du champ d'en-tête Host, et

  • Le Request-URI obtenu du Request-Line, sauf si le Request-URI n'est que l'astérisque "*".

Si le Request-URI utilise la forme abs_path ou astérisque, et que le champ d'en-tête Host n'est pas présent, alors l'URI de requête effectif est indéfini.

Sinon, lorsque le Request-URI utilise la forme authority, l'URI de requête effectif est indéfini.

Les URI de requête effectifs sont comparés en utilisant les règles décrites dans la section 3.2.3 de [RFC2616], mais un composant de chemin vide ne doit pas (MUST NOT) être traité comme équivalent à un chemin absolu de "/".

9.2.1. Effective Request URI Examples (Exemples d'URI de Requête Effectif)​

Exemple 1 : L'URI de requête effectif du message

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080

(reçu via une connexion TCP non sécurisée) est "http", plus "://", plus le composant d'autorité "www.example.org:8080", plus la cible de requête "/pub/WWW/TheProject.html". Donc, c'est http://www.example.org:8080/pub/WWW/TheProject.html.

Exemple 2 : L'URI de requête effectif du message

OPTIONS * HTTP/1.1
Host: www.example.org

(reçu via une connexion TCP protégée par SSL/TLS) est "https", plus "://", plus le composant d'autorité "www.example.org". Donc, c'est https://www.example.org.

Dernière mise à jour le