8. Considérations IANA (IANA Considerations)
Cette spécification met à jour les registres établis par [RFC2817], [RFC2818] et [RFC4229], en plus de définir de nouveaux registres pour les noms de méthode, les codes d'état et les sémantiques associées.
8.1. Enregistrement des méthodes (Method Registration)
Le "Registre des méthodes du protocole de transfert hypertexte (HTTP)" définit l'espace de noms pour le jeton de méthode de requête (Section 4). Le registre des méthodes a été créé et est maintenant maintenu à http://www.iana.org/assignments/http-methods.
8.1.1. Procédure (Procedure)
Les enregistrements DOIVENT (MUST) inclure les champs suivants:
- Nom de la méthode (Method Name)
- Sûre (Safe) (oui/non)
- Idempotente (Idempotent) (oui/non)
- Pointeur vers le texte de spécification (Pointer to specification text)
Les valeurs à ajouter à cet espace de noms nécessitent une révision IETF (voir Section 4.1 de [RFC5226]).
8.1.2. Considérations pour les nouvelles méthodes (Considerations for New Methods)
Les méthodes standardisées sont génériques; c'est-à-dire qu'elles sont potentiellement applicables à toute ressource, pas seulement à un type de média particulier, un type de ressource ou une application. En tant que tel, il est préférable que les nouvelles méthodes soient enregistrées dans un document qui n'est pas spécifique à une seule application ou format de données, car les technologies orthogonales méritent une spécification orthogonale.
Étant donné que l'analyse syntaxique des messages (Section 3 de [RFC7230]) doit être indépendante de la sémantique des méthodes (à l'exception des réponses à HEAD), les définitions de nouvelles méthodes ne peuvent pas modifier l'algorithme d'analyse syntaxique ni interdire la présence d'un corps de message sur le message de requête ou de réponse. Les définitions de nouvelles méthodes peuvent spécifier qu'un seul corps de message de longueur nulle est autorisé en exigeant un champ d'en-tête Content-Length avec une valeur de "0".
Une nouvelle définition de méthode doit indiquer si elle est sûre (Section 4.2.1), idempotente (Section 4.2.2), cacheable (Section 4.2.3), quelle sémantique doit être associée au corps du message de requête (le cas échéant), et quelle sémantique doit être associée au corps du message de réponse (le cas échéant). Notez que l'idempotence d'une méthode de requête est une propriété de l'implémentation sur le serveur d'origine. Étant donné que les implémentations peuvent s'écarter du comportement prévu, le client ne peut pas compter sur le fait qu'une méthode soit idempotente ou sûre.
Si une nouvelle méthode est cacheable, sa définition devrait (ought to) décrire comment et dans quelles conditions un cache peut stocker une réponse et l'utiliser pour satisfaire une requête ultérieure. Une nouvelle méthode devrait (ought to) décrire si elle peut être rendue conditionnelle (Section 5 de [RFC7232]) et, si oui, comment un serveur répond lorsque la condition est fausse. De même, si une nouvelle méthode peut avoir une utilité pour la sémantique de réponse partielle ([RFC7233]), elle devrait (ought to) le documenter également.
Note: Évitez de définir un nom de méthode qui commence par "M-", car ce préfixe pourrait être mal interprété comme ayant la sémantique qui lui est attribuée par [RFC2774].
8.1.3. Enregistrements (Registrations)
La procédure d'enregistrement des méthodes pour HTTP a été mise à jour selon cette spécification. Le registre des méthodes HTTP a été mis à jour avec les enregistrements ci-dessous:
| Nom de la méthode | Sûre | Idempotente | Référence |
|---|---|---|---|
| GET | oui | oui | Section 4.3.1 |
| HEAD | oui | oui | Section 4.3.2 |
| POST | non | non | Section 4.3.3 |
| PUT | non | oui | Section 4.3.4 |
| DELETE | non | oui | Section 4.3.5 |
| CONNECT | non | non | Section 4.3.6 |
| OPTIONS | oui | oui | Section 4.3.7 |
| TRACE | oui | oui | Section 4.3.8 |
8.2. Enregistrement des codes d'état (Status Code Registration)
Le "Registre des codes d'état du protocole de transfert hypertexte (HTTP)" définit l'espace de noms pour le jeton de code d'état de réponse (Section 6). Le registre des codes d'état a été créé et est maintenant maintenu à http://www.iana.org/assignments/http-status-codes.
8.2.1. Procédure (Procedure)
Les enregistrements DOIVENT (MUST) inclure les champs suivants:
- Code d'état (Status Code) (3 chiffres)
- Description courte (Short Description)
- Pointeur vers le texte de spécification (Pointer to specification text)
Les valeurs à ajouter à l'espace de noms des codes d'état HTTP nécessitent une révision IETF (voir Section 4.1 de [RFC5226]).
8.2.2. Considérations pour les nouveaux codes d'état (Considerations for New Status Codes)
Lorsqu'il est nécessaire d'exprimer une sémantique pour une réponse qui n'est pas définie par les codes d'état actuels, un nouveau code d'état peut être enregistré. Les codes d'état sont génériques; ils sont potentiellement applicables à toute ressource, pas seulement à un type de média particulier, un type de ressource ou une application de HTTP. En tant que tel, il est préférable que les nouveaux codes d'état soient enregistrés dans un document qui n'est pas spécifique à une seule application.
Les nouveaux codes d'état doivent appartenir à l'une des catégories définies à la Section 6. Pour permettre aux analyseurs syntaxiques existants de traiter le message de réponse, les nouveaux codes d'état ne peuvent pas interdire une charge utile, bien qu'ils puissent imposer un corps de charge utile de longueur nulle.
Les propositions de nouveaux codes d'état qui ne sont pas encore largement déployés devraient (ought to) éviter d'attribuer un numéro spécifique au code jusqu'à ce qu'il y ait un consensus clair qu'il sera enregistré; au lieu de cela, les premiers projets peuvent utiliser une notation telle que "4NN" ou "3N0" pour indiquer la classe du ou des codes d'état proposés sans consommer prématurément un numéro.
La définition d'un nouveau code d'état devrait (ought to) expliquer la sémantique des réponses avec ce code d'état, y compris toutes les conditions préalables requises, les caractéristiques de la requête qui ont déclenché l'état, et le comportement client attendu pour traiter de telles réponses.
8.2.3. Enregistrements (Registrations)
Le registre des codes d'état a été mis à jour avec les enregistrements ci-dessous:
| Valeur | Description | Référence |
|---|---|---|
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | [RFC7233], Section 4.1 |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | [RFC7232], Section 4.1 |
| 305 | Use Proxy | Section 6.4.5 |
| 306 | (Unused) | Section 6.4.6 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | [RFC7235], Section 3.1 |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | [RFC7235], Section 3.2 |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | [RFC7232], Section 4.2 |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | [RFC7233], Section 4.4 |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
8.3. Enregistrement des champs d'en-tête (Header Field Registration)
Cette spécification met à jour le registre des champs d'en-tête HTTP défini dans [RFC4229] avec la procédure d'enregistrement de [RFC3864].
8.3.1. Considérations pour les nouveaux champs d'en-tête (Considerations for New Header Fields)
Les champs d'en-tête sont des composants clés du cadre d'extensibilité HTTP. Ils définissent des données supplémentaires associées soit à un message, soit à une ressource. De nombreuses considérations doivent être prises en compte lors de la définition d'un nouveau champ d'en-tête.
Les nouveaux champs d'en-tête doivent au moins définir:
- Le nom du champ (Section 3.2 de [RFC7230])
- La grammaire attendue de la valeur du champ
- La sémantique du champ
- Pour les champs d'en-tête de requête, comment ils peuvent remplacer ou augmenter la sémantique des messages
- Pour les champs d'en-tête de réponse, comment ils modifient l'interprétation de la réponse
- Si le champ doit être stocké par un cache et s'il peut être renvoyé dans les réponses aux requêtes ultérieures
- Si le champ doit être transféré par les proxys
Il est également utile de documenter:
- Si le champ d'en-tête est destiné à être utilisé par des intermédiaires ou uniquement de bout en bout
- Considérations de sécurité et de confidentialité (voir Section 9)
- Interaction avec d'autres champs d'en-tête
Des conseils détaillés pour définir de nouveaux champs d'en-tête sont disponibles dans "Directives pour les spécifications des champs d'en-tête HTTP" [RFC6648bis].
8.3.2. Enregistrements (Registrations)
Le "Registre des champs d'en-tête du protocole de transfert hypertexte (HTTP)" situé à http://www.iana.org/assignments/message-headers/ devrait être mis à jour avec les enregistrements permanents ci-dessous (voir [RFC3864]):
| Nom du champ d'en-tête | Protocole | Statut | Référence |
|---|---|---|---|
| Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 |
| Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 |
| Max-Forwards | http | standard | Section 5.1.2 |
| MIME-Version | http | standard | Annexe A.1 |
| Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 |
| Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 |
Le contrôleur de changement est: "IETF ([email protected]) - Internet Engineering Task Force".
8.4. Enregistrement des codages de contenu (Content Coding Registration)
Le "Registre des codages de contenu HTTP" définit l'espace de noms pour les noms de codage de contenu (Section 3.1.2.1). Le registre des codages de contenu a été créé et est maintenant maintenu à http://www.iana.org/assignments/http-parameters.
8.4.1. Procédure (Procedure)
Les enregistrements DOIVENT (MUST) inclure les champs suivants:
- Nom (Name)
- Description
- Pointeur vers le texte de spécification (Pointer to specification text)
Les noms qui commencent par "x-" sont réservés pour un usage privé (tel que défini par [RFC5226]) et ne peuvent donc pas être enregistrés.
Les valeurs à ajouter à cet espace de noms nécessitent une révision IETF (voir Section 4.1 de [RFC5226]).
8.4.2. Enregistrements (Registrations)
Le registre des codages de contenu a été mis à jour avec les enregistrements ci-dessous:
| Nom | Description | Référence |
|---|---|---|
| compress | Format de données "compress" UNIX | Section 3.1.2.1 |
| deflate | Données compressées "deflate" | Section 3.1.2.1 |
| gzip | Format de fichier GZIP | Section 3.1.2.1 |
| identity | Réservé (synonyme de pas d'encodage) | Section 3.1.2.1 |