2. Conformance (Conformité)
2.1. Syntax Notation (Notation syntaxique)
Cette spécification utilise la notation de forme de Backus-Naur augmentée (Augmented Backus-Naur Form, ABNF) de [RFC5234], étendue avec la notation pour la sensibilité à la casse dans les chaînes définie dans [RFC7405].
Elle utilise également une extension de liste, définie dans la section 5.6.1, qui permet une définition compacte de listes séparées par des virgules en utilisant un opérateur "#" (similaire à la façon dont l'opérateur "*" indique la répétition). L'annexe A montre la grammaire collectée avec tous les opérateurs de liste étendus à la notation ABNF standard.
Par convention, les noms de règles ABNF préfixés par "obs-" désignent des règles de grammaire obsolètes qui apparaissent pour des raisons historiques.
Les règles de base suivantes sont incluses par référence, telles que définies dans l'annexe B.1 de [RFC5234] : ALPHA (lettres), CR (retour chariot), CRLF (CR LF), CTL (contrôles), DIGIT (décimal 0-9), DQUOTE (guillemet double), HEXDIG (hexadécimal 0-9/A-F/a-f), HTAB (tabulation horizontale), LF (saut de ligne), OCTET (toute séquence de données de 8 bits), SP (espace) et VCHAR (tout caractère US-ASCII visible).
La section 5.6 définit certains composants syntaxiques génériques pour les valeurs de champ.
Cette spécification utilise les termes « character » (caractère), « character encoding scheme » (schéma d'encodage de caractères), « charset » (jeu de caractères) et « protocol element » (élément de protocole) tels qu'ils sont définis dans [RFC6365].
2.2. Requirements Notation (Notation des exigences)
Les mots-clés « MUST » (doit), « MUST NOT » (ne doit pas), « REQUIRED » (requis), « SHALL » (doit), « SHALL NOT » (ne doit pas), « SHOULD » (devrait), « SHOULD NOT » (ne devrait pas), « RECOMMENDED » (recommandé), « NOT RECOMMENDED » (non recommandé), « MAY » (peut) et « OPTIONAL » (optionnel) dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.
Cette spécification cible les critères de conformité en fonction du rôle d'un participant dans la communication HTTP. Par conséquent, les exigences sont placées sur les expéditeurs (Senders), les destinataires (Recipients), les clients (Clients), les serveurs (Servers), les agents utilisateurs (User Agents), les intermédiaires (Intermediaries), les serveurs d'origine (Origin Servers), les proxies (Proxies), les passerelles (Gateways) ou les caches (Caches), selon le comportement contraint par l'exigence. Des exigences supplémentaires sont placées sur les implémentations (Implementations), les propriétaires de ressources (Resource Owners) et les enregistrements d'éléments de protocole (Protocol Element Registrations) lorsqu'elles s'appliquent au-delà de la portée d'une seule communication.
Le verbe « generate » (générer) est utilisé au lieu de « send » (envoyer) lorsqu'une exigence s'applique uniquement aux implémentations qui créent l'élément de protocole, plutôt qu'à une implémentation qui transmet un élément reçu en aval.
Une implémentation est considérée comme conforme si elle se conforme à toutes les exigences associées aux rôles qu'elle joue dans HTTP.
Un expéditeur ne doit pas (MUST NOT) générer d'éléments de protocole qui ne correspondent pas à la grammaire définie par les règles ABNF correspondantes. Dans un message donné, un expéditeur ne doit pas (MUST NOT) générer d'éléments de protocole ou d'alternatives syntaxiques qui ne sont autorisés à être générés que par des participants dans d'autres rôles (c'est-à-dire un rôle que l'expéditeur n'a pas pour ce message).
La conformité à HTTP comprend à la fois la conformité à la syntaxe de messagerie particulière de la version du protocole utilisée et la conformité à la sémantique des éléments de protocole envoyés. Par exemple, un client qui prétend se conformer à HTTP/1.1 mais ne parvient pas à reconnaître les fonctionnalités requises des destinataires HTTP/1.1 ne parviendra pas à interopérer avec les serveurs qui ajustent leurs réponses conformément à ces prétentions. Les fonctionnalités qui reflètent les choix de l'utilisateur, telles que la négociation de contenu (Content Negotiation) et les extensions sélectionnées par l'utilisateur, peuvent avoir un impact sur le comportement de l'application au-delà du flux de protocole ; l'envoi d'éléments de protocole qui reflètent inexactement les choix d'un utilisateur confondra l'utilisateur et inhibera le choix.
Lorsqu'une implémentation échoue à la conformité sémantique, les destinataires des messages de cette implémentation développeront éventuellement des solutions de contournement (Workarounds) pour ajuster leur comportement en conséquence. Un destinataire peut (MAY) employer de telles solutions de contournement tout en restant conforme à ce protocole si les solutions de contournement sont limitées aux implémentations fautives. Par exemple, les serveurs analysent souvent des portions de la valeur du champ User-Agent, et les agents utilisateurs analysent souvent la valeur du champ Server, pour ajuster leur propre comportement par rapport aux bogues connus ou aux valeurs par défaut mal choisies.
2.3. Length Requirements (Exigences de longueur)
Un destinataire devrait (SHOULD) analyser un élément de protocole reçu de manière défensive, avec seulement des attentes marginales que l'élément se conformera à sa grammaire ABNF et tiendra dans une taille de tampon raisonnable.
HTTP n'a pas de limitations de longueur spécifiques pour de nombreux éléments de protocole car les longueurs qui pourraient être appropriées varieront largement, selon le contexte de déploiement et l'objectif de l'implémentation. Par conséquent, l'interopérabilité entre les expéditeurs et les destinataires dépend d'attentes partagées concernant ce qui est une longueur raisonnable pour chaque élément de protocole. De plus, ce qui est généralement compris comme étant une longueur raisonnable pour certains éléments de protocole a changé au cours des trois dernières décennies d'utilisation de HTTP et devrait continuer à changer à l'avenir.
Au minimum, un destinataire doit (MUST) être capable d'analyser et de traiter des longueurs d'éléments de protocole qui sont au moins aussi longues que les valeurs qu'il génère pour ces mêmes éléments de protocole dans d'autres messages. Par exemple, un serveur d'origine qui publie des références URI très longues vers ses propres ressources doit être capable d'analyser et de traiter ces mêmes références lorsqu'elles sont reçues en tant qu'URI cible.
De nombreux éléments de protocole reçus ne sont analysés que dans la mesure nécessaire pour identifier et transmettre cet élément en aval. Par exemple, un intermédiaire peut analyser un champ reçu en ses composants de nom de champ et de valeur de champ, mais ensuite transmettre le champ sans analyse supplémentaire à l'intérieur de la valeur de champ.
2.4. Error Handling (Gestion des erreurs)
Un destinataire doit (MUST) interpréter un élément de protocole reçu selon la sémantique définie pour lui par cette spécification, y compris les extensions à cette spécification, à moins que le destinataire n'ait déterminé (par expérience ou configuration) que l'expéditeur implémente incorrectement ce qui est impliqué par cette sémantique. Par exemple, un serveur d'origine peut ignorer le contenu d'un champ d'en-tête Accept-Encoding reçu si l'inspection du champ d'en-tête User-Agent indique une version d'implémentation spécifique connue pour échouer à la réception de certains codages de contenu.
Sauf indication contraire, un destinataire peut (MAY) tenter de récupérer un élément de protocole utilisable à partir d'une construction invalide. HTTP ne définit pas de mécanismes de gestion des erreurs spécifiques, sauf lorsqu'ils ont un impact direct sur la sécurité, car différentes applications du protocole nécessitent différentes stratégies de gestion des erreurs. Par exemple, un navigateur Web peut souhaiter récupérer de manière transparente d'une réponse où le champ d'en-tête Location ne s'analyse pas selon l'ABNF, alors qu'un client de contrôle de systèmes peut considérer toute forme de récupération d'erreur comme dangereuse.
Certaines requêtes peuvent être automatiquement réessayées par un client en cas de défaillance de connexion sous-jacente, comme décrit dans la section 9.2.2.
2.5. Protocol Version (Version du protocole)
Le numéro de version de HTTP se compose de deux chiffres décimaux séparés par un "." (point ou virgule décimale). Le premier chiffre (version majeure, Major Version) indique la syntaxe de messagerie, tandis que le deuxième chiffre (version mineure, Minor Version) indique la version mineure la plus élevée au sein de cette version majeure à laquelle l'expéditeur est conforme (capable de comprendre pour une communication future).
Bien que la sémantique de base de HTTP ne change pas entre les versions du protocole, leur expression « sur le fil » peut changer, et donc le numéro de version HTTP change lorsque des modifications incompatibles sont apportées au format de fil. De plus, HTTP permet d'apporter des modifications incrémentielles et rétrocompatibles au protocole sans changer sa version grâce à l'utilisation de points d'extension définis (section 16).
La version du protocole dans son ensemble indique la conformité de l'expéditeur avec l'ensemble des exigences énoncées dans la ou les spécifications correspondantes de cette version. Par exemple, la version « HTTP/1.1 » est définie par les spécifications combinées de ce document, « HTTP Caching » [CACHING] et « HTTP/1.1 » [HTTP/1.1].
Le numéro de version majeure de HTTP est incrémenté lorsqu'une syntaxe de message incompatible est introduite. Le numéro mineur est incrémenté lorsque les modifications apportées au protocole ont pour effet d'ajouter à la sémantique du message ou d'impliquer des capacités supplémentaires de l'expéditeur.
La version mineure annonce les capacités de communication de l'expéditeur même lorsque l'expéditeur n'utilise qu'un sous-ensemble rétrocompatible du protocole, permettant ainsi au destinataire de savoir que des fonctionnalités plus avancées peuvent être utilisées en réponse (par les serveurs) ou dans les requêtes futures (par les clients).