Appendix B. Changes from RFC 2616 (Modifications par rapport à RFC 2616)
Les principales modifications de cette révision sont de nature éditoriale: extraction de la syntaxe des messages et partition de la sémantique HTTP en documents séparés pour les fonctionnalités de base, les requêtes conditionnelles, les requêtes partielles, la mise en cache et l'authentification. Le langage de conformité a été révisé pour cibler clairement les exigences et la terminologie a été améliorée pour distinguer la charge utile des représentations et les représentations des ressources.
Une nouvelle exigence a été ajoutée selon laquelle la sémantique intégrée dans un URI doit être désactivée lorsque cette sémantique est incompatible avec la méthode de requête, car cela constitue une cause fréquente d'échec d'interopérabilité. (Section 2)
Un algorithme a été ajouté pour déterminer si une charge utile est associée à un identifiant spécifique. (Section 3.1.4.1)
Le jeu de caractères par défaut ISO-8859-1 pour les types de médias texte a été supprimé; la valeur par défaut est maintenant ce que la définition du type de média spécifie. De même, le traitement spécial d'ISO-8859-1 a été supprimé du champ d'en-tête Accept-Charset. (Section 3.1.1.3 et Section 5.3.3)
La définition de Content-Location a été modifiée pour ne plus affecter l'URI de base utilisé pour résoudre les références d'URI relatives, en raison d'un support d'implémentation médiocre et de l'effet indésirable de potentiellement briser les liens relatifs dans les ressources négociées en contenu. (Section 3.1.4.2)
Pour être cohérent avec l'algorithme d'analyse neutre de méthode de [RFC7230], la définition de GET a été assouplie pour permettre aux requêtes d'avoir un corps, même si un corps n'a pas de signification pour GET. (Section 4.3.1)
Les serveurs ne sont plus tenus de traiter tous les champs d'en-tête Content-* et l'utilisation de Content-Range a été explicitement interdite dans les requêtes PUT. (Section 4.3.4)
La définition de la méthode CONNECT a été déplacée de [RFC2817] vers cette spécification. (Section 4.3.6)
Les méthodes de requête OPTIONS et TRACE ont été définies comme étant sûres. (Section 4.3.7 et Section 4.3.8)
Le mécanisme d'extension du champ d'en-tête Expect a été supprimé en raison d'implémentations défectueuses largement déployées. (Section 5.1.1)
Le champ d'en-tête Max-Forwards a été limité aux méthodes OPTIONS et TRACE; auparavant, les méthodes d'extension pouvaient également l'utiliser. (Section 5.1.2)
L'URI "about:blank" a été suggéré comme valeur pour le champ d'en-tête Referer lorsqu'aucun URI de référence n'est applicable, ce qui distingue ce cas des autres où le champ Referer n'est pas envoyé ou a été supprimé. (Section 5.5.2)
Les codes d'état suivants sont maintenant cachables (c'est-à-dire qu'ils peuvent être stockés et réutilisés par un cache sans information de fraîcheur explicite présente): 204, 404, 405, 414, 501. (Section 6)
La description du statut 201 (Created) a été modifiée pour permettre la possibilité que plus d'une ressource ait été créée. (Section 6.3.2)
La définition de 203 (Non-Authoritative Information) a été élargie pour inclure également les cas de transformations de charge utile. (Section 6.3.4)
L'ensemble des méthodes de requête qui peuvent être redirigées automatiquement en toute sécurité n'est plus fermé; les agents utilisateur sont capables de faire cette détermination en fonction de la sémantique de la méthode de requête. Les codes d'état de redirection 301, 302 et 307 n'ont plus d'exigences normatives sur les charges utiles de réponse et l'interaction utilisateur. (Section 6.4)
Les codes d'état 301 et 302 ont été modifiés pour permettre aux agents utilisateur de réécrire la méthode de POST en GET. (Sections 6.4.2 et 6.4.3)
La description du code d'état 303 (See Other) a été modifiée pour permettre sa mise en cache si des informations de fraîcheur explicites sont fournies, et une définition spécifique a été ajoutée pour une réponse 303 à GET. (Section 6.4.4)
Le code d'état 305 (Use Proxy) a été déprécié en raison de problèmes de sécurité concernant la configuration intrabande d'un proxy. (Section 6.4.5)
Le code d'état 400 (Bad Request) a été assoupli pour ne plus se limiter aux erreurs de syntaxe. (Section 6.5.1)
Le code d'état 426 (Upgrade Required) a été incorporé depuis [RFC2817]. (Section 6.5.15)
La cible des exigences sur HTTP-date et le champ d'en-tête Date a été réduite aux systèmes générant la date, plutôt qu'à tous les systèmes envoyant une date. (Section 7.1.1)
La syntaxe du champ d'en-tête Location a été modifiée pour permettre toutes les références d'URI, y compris les références relatives et les fragments, ainsi que quelques clarifications sur les cas où l'utilisation de fragments ne serait pas appropriée. (Section 7.1.2)
Allow a été reclassé comme un champ d'en-tête de réponse, supprimant l'option de le spécifier dans une requête PUT. Les exigences relatives au contenu d'Allow ont été assouplies; en conséquence, les clients ne sont pas tenus de toujours faire confiance à sa valeur. (Section 7.4.1)
Un registre de méthodes a été défini. (Section 8.1)
Le registre des codes d'état a été redéfini par cette spécification; auparavant, il était défini dans la section 7.1 de [RFC2817]. (Section 8.2)
L'enregistrement des codages de contenu a été modifié pour nécessiter une révision IETF. (Section 8.4)
Le champ d'en-tête Content-Disposition a été supprimé car il est maintenant défini par [RFC6266].
Le champ d'en-tête Content-MD5 a été supprimé car il était implémenté de manière incohérente en ce qui concerne les réponses partielles.