RFC: 1945
Statut : Information
Retour à l'index des normes : INDEX FRANCAIS
Ces appendices ont été ajoutés par souci d'information - Ils ne forment pas partie intégrante de la spécification HTTP/1.0.
Outre la définition du protocole HTTP/1.0, ce document sert à la spécification de l'Internet Media Type "message/http". La spécification suivante est enregistrée auprès de l'IANA [13].
Media Type : message
Media subtype : http
Paramètres obligatoires: none
Paramètres optionnels: version, msgtype
| version: | Version du protocole HTTP utilisé pour le message courant (e.g., "1.0"). Si ce paramètre est absent, la version peut être déduite par analyse de la première ligne du corps. |
| msgtype: | Le type de message -- "request" ou "response". Si ce paramètre est absent, la version peut être déduite par analyse de la première ligne du corps. |
| Considérations d'encodage: | seulement "7bits", "8bits", ou "binary" permis |
| Considérations en termes de sécurité: | aucune |
Bien que ce document donne toutes les spécifications pour la génération de messages HTTP/1.0, toutes les applications ne présenteront pas une implémentation correcte. Nous recommandons de ce fait que les applications opérationnelles puissent tolérer certaines déviation de ce protocole, dans la mesure où celles-ci gardent un caractère univoque.
Les clients devront faire preuve de tolérance dans l'interprétation de la ligne d'état. Les serveurs devront à leur tour se montrer ouverts dans l'interprétation de la ligne de Requête. En particulier, ils devront accepter tout nombre d'espaces ou de tabulations entre les champs, même lorsqu'un espace simple est requis.
La fin de ligne dans les en-têtes HTTP est marquée par la séquence CRLF. Cependant, nous conseillons aux applications interprétant de telles en-têtes de reconnaître une fin de ligne sur LF simple en ignorant le CR de tête.
HTTP/1.0 utilise de nombreuses syntaxes déjà employées pour le Mail Internet (RFC 822 [7]) et entre autres les Multipurpose Internet Mail Extensions (MIME [5]) permettant aux entités d'être transmises sous une grande quantité de formes tout en respectant le principe d'évolutivité. Cependant, la RFC 1521 concerne le mail, et HTTP implémente certaines fonctions d'une façon différente de la RFC 1521. Ces différences ont été soigneusement contrôlées afin d'optimiser la transmission en mode binaire, pour ouvrir le champ d'application offert par des nouveaux types de média, pour faciliter la comparaison de dates, tout en restant compatibles avec des serveurs et clients HTTP antérieurs.
A cette heure, nous espérons une révision de la RFC 1521. Cette révision pourrait intégré quelques unes des pratiques utilisées par HTTP/1.0 mais ne faisant pas partie de la RFC 1521.
Cet appendice décrit les points spécifiques pour lesquels HTTP et la RFC 1521 diffèrent. Les proxies et routeurs dirigeant des messages HTTP vers un environnement MIME strict devront connaître ces différences et propose une conversion appropriée si nécessaire. A l'inverse Les proxies et routeurs accédant à un environnement HTTP à partir d'un environnement MIME strict, devront de même se charger de la conversion, et donc connaître ces différences.
La RFC 1521 impose qu'une entité Internet Mail soit convertie dans sa forme canonique avant d'être transmise, (Appendice G de la RFC 1521 [5]). La Section 3.6.1 de ce document décrit toutes les formes admises du sous-type "texte" transmis sous HTTP.
La RFC 1521 impose que le contenu d'un message dont le Content-Type est "text" représente les fins de ligne par la séquence CRLF et interdise l'usage de CR ou de LF en dehors de ce contexte de fin de ligne. HTTP permet l'usage de séquences CRLF, de CR et LF seuls pour marquer la fin de ligne du texte dans le corps du document envoyé sous HTTP.
Là où c'est possible, un proxy ou un routeur du HTTP vers un environnement strictement RFC 1521 devra traduire toutes les fins de ligne du texte contenu dans ces documents concernés par la Section 3.6.1 dans ce document en forme canonique selon la RFC 1521: une séquence CRLF. Notez, cependant, que cette règle peut se compliquer dans le cas où un champ Content-Encoding est présent et par le fait qu'HTTP permettent l'utilisation de tables de caractères tant que le caractère 13 et 10 continuent à représenter les équivalents de CR et LF (comme c'est le cas pour certaines tables utilisant plusieurs octets par caractère).
HTTP/1.0 utilise un ensemble de formats de date restreint (Section 3.3) pour simplifier l'implémentation des comparaisons de date. Les proxies et routeurs agissant à partir d'autres protocoles devront s'assurer que tout champ d'en-tête de Date dans un message reste conforme à l'un des formats reconnus par HTTP/1.0, et réécriront les dates si nécessaire.
La RFC 1521 n'introduit aucun concept équivalent au champ d'en-tête Content-Encoding défini par HTTP/1.0. Comme celui-ci fait fonction de modificateur du type de média, les proxies et routeurs depuis HTTP vers des protocoles compatibles MIME doivent soit changer la valeur indiquée dans le champ Content-Type, soit analyser le corps d'entité avant de faire suivre le message. (Certaines implémentations expérimentales du champ Content-Type pour la messagerie Internet ont utilisé une valeur ";conversions= HTTP n'exploite pas le champ Content-Transfer-Encoding (CTE) utilisé par la RFC 1521. Les proxies et routeurs depuis un protocole MIME vers un protocole HTTP devront supprimer tout CTE à l'exclusion éventuellement du CTE "identity" ("quoted-printable" ou "base64") avant de faire suivre le message vers un client HTTP client.
Les proxies et routeurs depuis HTTP vers un protocole compatible MIME ont la responsabilité de s'assurer que le message envoyé est au format correct pour un transfert en toute sécurité sous ce protocole, cette sécurité étant naturellement limitée aux limitations propres du protocole utilisé. Un tel proxy ou routeur devra ajouter un Content-Transfer-Encoding approprié, de façon à présenter les données conformément aux attentes de ce protocole.
Sous RFC 1521, la plupart des champs d'en-tête placés dans les sous-parties d'un corps Multipart sont en général ignorés sauf si le nom du champ débute par "Content-". En HTTP/1.0, les sous-parties de corps Multipart peuvent contenir tout champ d'en-tête HTTP dont la signification est pertinente pour cette partie de message.
Cet appendice liste quelques éléments de protocole parfois employés dans certaines implémentations HTTP, mais qui ne sont pas considérées comme "légitimes" par la plupart des applications HTTP/1.0. Les développeurs ont un intérêt à connaître ces fonctions, mais ne peuvent être sûrs de leur présence effective, ni de leur implémentation par d'autres applications HTTP/1.0.
D.1.1 PUT
La méthode PUT demande à ce que l'entité jointe soit enregistrée par le serveur sous l'URI-visée. Si cette URI pointe vers une ressource déjà existante, l'entité jointe sera considérée comme une nouvelle version de celle jusqu'alors présente sur le serveur origine. Si l'URI-visée pointe sur une ressource inexistante, et à la condition que cette URI puisse être définie en tant que nouvelle ressource du serveur, ce dernier créera une nouvelle ressource sous cette URI.
La différence fondamentale entre les méthodes POST et PUT réside dans la signification donnée à l'URI-visée. Celle-ci, pour une méthode POST désigne la ressource "active" à laquelle l'entité doit être confiée dans le but d'un traitement. Cette ressource peut être un programme, un routeur ou un autre protocole, ou encore une entité acceptant des annotations. Par contre, L'URI précisée dans une méthode PUT nomme l'entité incluse dans la requête - Le client sait parfaitement de quelle URI il s'agit et le serveur n'applique la méthode à aucune autre ressource.
D.1.2 DELETE
La méthode DELETE demande au serveur de supprimer la ressource pointée par l'URI-visée.
D.1.3 LINK
La méthode LINK établit une ou plusieurs liaisons entre la ressource existante définie par l'URI-visée et d'autres ressources.
D.1.4 UNLINK
A contrario, cette méthode supprime des liaisons entre la ressource définie par l'URI-visée, et d'autres ressources qui lui sont liées.
D.2.1 Accept
Le champ d'en-tête Accept (requête) peut être utilisé pour définir une liste de types de média acceptés en réponse à la requête. L'astérisque "*" est utilisée pour grouper des types de média par classe, "*/*" indiquant tous les types de média, et "type/*" indiquant tous les sous-types du type "type". La gamme de types signalée par le client sert essentiellement à limiter les documents à des types acceptables par le client dans le contexte de la requête formulée.
D.2.2 Accept-Charset
Le champ d'en-tête Accept-Charset (requête) peut être utilisé pour former une liste de tables de caractères préférentielles, autres que les tables US-ASCII et ISO-8859-1 utilisées par défaut. Ce champ permet à un client de signaler à un serveur qu'il sait accepter d'autres représentations de texte que les représentations par défaut, et est donc en mesure d'exploiter des documents encodés avec ces tables, si le serveur sait les transmettre.
D.2.3 Accept-Encoding
Le champ d'en-tête Accept-Encoding (requête) est similaire au champ Accept, mais restreint la gamme de valeurs Content-Coding attendues dans une réponse.
D.2.4 Accept-Language
Le champ d'en-tête Accept-Encoding (requête) est similaire au champ Accept, mais restreint la gamme de langues attendues dans une réponse.
D.2.5 Content-Language
Le champ d'en-tête Content-Language (entité) décrit la ou les langues naturelles des destinataires potentiels du corps d'entité. Notez que ceci n'a aucun lien avec les langues utilisées dans l'ensemble de l'entité.
D.2.6 Link
Le champ d'en-tête Link (entité) permet de décrire les liaisons entre l'entité jointe et d'autres ressources. Une entité peut se voir attribuer plusieurs valeurs pour le champ Link. Un champ Link, au niveau métainformation, indique typiquement des relations du type dépendance hiérarchique ou des chemins d'accès.
D.2.7 MIME-Version
Les messages HTTP peuvent inclure un champ unique d'en-tête générale indiquant quelle version du protocole MIME a été employé pour construire le message. L'utilisation de ce champ MIME-Version, tel que décrit par la RFC 1521 [5], peut indiquer si le message est compatible MIME. Malheureusement, certaines premières implémentations de serveurs HTTP/1.0 émettent ce champ sans réserve. Il est conseillé de l'ignorer.
D.2.8 Retry-After
Le champ d'en-tête Retry-After (réponse) peut être utilisé dans une réponse 503 (service indisponible) dans le but d'indiquer pendant combien de temps (estimé) le service restera indisponible aux requêtes du client. La valeur de ce champ peut être une date HTTP ou un nombre entier de secondes (en décimal) à partir de l'heure de la réponse.
D.2.9 Title
Le champ d'en-tête Title est purement informatif et donne le titre de l'entité.
D.2.10 URI
Le champ d'en-tête URI (entité) peut contenir toute ou partie des Uniform Resource Identifiers (Section 3.2) par laquelle la ressource définie par l'URI-visée peut être identifiée. Aucune garantie n'est cependant donnée que la ressource soit effectivement accessible par l'une des URI spécifiées.
C.4 Pas de champ Content-Transfer-Encoding
C.5 Champs d'en-tête HTTP dans des parties de corps Multipart
D. Fonctions supplémentaires
D.1 Méthodes de requètes supplémentaires
D.2 Définitions d'autres champs d'en-tête