8. Considerazioni IANA (IANA Considerations)
Questa specifica aggiorna i registri stabiliti da [RFC2817], [RFC2818] e [RFC4229], oltre a definire nuovi registri per nomi di metodo, codici di stato e semantiche associate.
8.1. Registrazione dei metodi (Method Registration)
Il "Registro dei metodi del protocollo di trasferimento ipertestuale (HTTP)" definisce lo spazio dei nomi per il token del metodo di richiesta (Sezione 4). Il registro dei metodi è stato creato ed è ora mantenuto su http://www.iana.org/assignments/http-methods.
8.1.1. Procedura (Procedure)
Le registrazioni DEVONO (MUST) includere i seguenti campi:
- Nome del metodo (Method Name)
- Sicuro (Safe) (sì/no)
- Idempotente (Idempotent) (sì/no)
- Puntatore al testo della specifica (Pointer to specification text)
I valori da aggiungere a questo spazio dei nomi richiedono la revisione IETF (vedere Sezione 4.1 di [RFC5226]).
8.1.2. Considerazioni per i nuovi metodi (Considerations for New Methods)
I metodi standardizzati sono generici; cioè, sono potenzialmente applicabili a qualsiasi risorsa, non solo a un particolare tipo di media, tipo di risorsa o applicazione. Pertanto, è preferibile che i nuovi metodi siano registrati in un documento che non è specifico per una singola applicazione o formato di dati, poiché le tecnologie ortogonali meritano specifiche ortogonali.
Poiché l'analisi del messaggio (Sezione 3 di [RFC7230]) deve essere indipendente dalla semantica del metodo (a parte le risposte a HEAD), le definizioni di nuovi metodi non possono modificare l'algoritmo di analisi o vietare la presenza di un corpo del messaggio sul messaggio di richiesta o di risposta. Le definizioni di nuovi metodi possono specificare che è consentito solo un corpo del messaggio di lunghezza zero richiedendo un campo di intestazione Content-Length con un valore di "0".
Una nuova definizione di metodo deve indicare se è sicuro (Sezione 4.2.1), idempotente (Sezione 4.2.2), memorizzabile nella cache (Sezione 4.2.3), quale semantica deve essere associata al corpo del messaggio di richiesta (se presente) e quale semantica deve essere associata al corpo del messaggio di risposta (se presente). Si noti che l'idempotenza di un metodo di richiesta è una proprietà dell'implementazione sul server di origine. Poiché le implementazioni possono discostarsi dal comportamento previsto, il client non può fare affidamento sul fatto che un metodo sia idempotente o sicuro.
Se un nuovo metodo è memorizzabile nella cache, la sua definizione dovrebbe (ought to) descrivere come e in quali condizioni una cache può memorizzare una risposta e utilizzarla per soddisfare una richiesta successiva. Un nuovo metodo dovrebbe (ought to) descrivere se può essere reso condizionale (Sezione 5 di [RFC7232]) e, in tal caso, come un server risponde quando la condizione è falsa. Allo stesso modo, se un nuovo metodo potrebbe avere qualche utilità per la semantica di risposta parziale ([RFC7233]), dovrebbe (ought to) documentarlo anche questo.
Nota: Evitare di definire un nome di metodo che inizia con "M-", poiché tale prefisso potrebbe essere erroneamente interpretato come avente la semantica assegnatagli da [RFC2774].
8.1.3. Registrazioni (Registrations)
La procedura di registrazione del metodo per HTTP è stata aggiornata secondo questa specifica. Il registro dei metodi HTTP è stato aggiornato con le registrazioni seguenti:
| Nome del metodo | Sicuro | Idempotente | Riferimento |
|---|---|---|---|
| GET | sì | sì | Sezione 4.3.1 |
| HEAD | sì | sì | Sezione 4.3.2 |
| POST | no | no | Sezione 4.3.3 |
| PUT | no | sì | Sezione 4.3.4 |
| DELETE | no | sì | Sezione 4.3.5 |
| CONNECT | no | no | Sezione 4.3.6 |
| OPTIONS | sì | sì | Sezione 4.3.7 |
| TRACE | sì | sì | Sezione 4.3.8 |
8.2. Registrazione del codice di stato (Status Code Registration)
Il "Registro dei codici di stato del protocollo di trasferimento ipertestuale (HTTP)" definisce lo spazio dei nomi per il token del codice di stato di risposta (Sezione 6). Il registro dei codici di stato è stato creato ed è ora mantenuto su http://www.iana.org/assignments/http-status-codes.
8.2.1. Procedura (Procedure)
Le registrazioni DEVONO (MUST) includere i seguenti campi:
- Codice di stato (Status Code) (3 cifre)
- Breve descrizione (Short Description)
- Puntatore al testo della specifica (Pointer to specification text)
I valori da aggiungere allo spazio dei nomi del codice di stato HTTP richiedono la revisione IETF (vedere Sezione 4.1 di [RFC5226]).
8.2.2. Considerazioni per i nuovi codici di stato (Considerations for New Status Codes)
Quando è necessario esprimere la semantica per una risposta che non è definita dai codici di stato attuali, può essere registrato un nuovo codice di stato. I codici di stato sono generici; sono potenzialmente applicabili a qualsiasi risorsa, non solo a un particolare tipo di media, tipo di risorsa o applicazione di HTTP. Pertanto, è preferibile che i nuovi codici di stato siano registrati in un documento che non è specifico per una singola applicazione.
I nuovi codici di stato devono rientrare in una delle categorie definite nella Sezione 6. Per consentire ai parser esistenti di elaborare il messaggio di risposta, i nuovi codici di stato non possono vietare un payload, sebbene possano imporre un corpo del payload di lunghezza zero.
Le proposte per nuovi codici di stato che non sono ancora ampiamente diffuse dovrebbero (ought to) evitare di allocare un numero specifico per il codice fino a quando non vi è un chiaro consenso che sarà registrato; invece, le bozze iniziali possono utilizzare una notazione come "4NN" o "3N0" per indicare la classe dei codici di stato proposti senza consumare prematuramente un numero.
La definizione di un nuovo codice di stato dovrebbe (ought to) spiegare la semantica delle risposte con quel codice di stato, incluse eventuali precondizioni richieste, le caratteristiche della richiesta che hanno attivato lo stato e il comportamento client previsto per l'elaborazione di tali risposte.
8.2.3. Registrazioni (Registrations)
Il registro dei codici di stato è stato aggiornato con le registrazioni seguenti:
| Valore | Descrizione | Riferimento |
|---|---|---|
| 100 | Continue | Sezione 6.2.1 |
| 101 | Switching Protocols | Sezione 6.2.2 |
| 200 | OK | Sezione 6.3.1 |
| 201 | Created | Sezione 6.3.2 |
| 202 | Accepted | Sezione 6.3.3 |
| 203 | Non-Authoritative Information | Sezione 6.3.4 |
| 204 | No Content | Sezione 6.3.5 |
| 205 | Reset Content | Sezione 6.3.6 |
| 206 | Partial Content | [RFC7233], Sezione 4.1 |
| 300 | Multiple Choices | Sezione 6.4.1 |
| 301 | Moved Permanently | Sezione 6.4.2 |
| 302 | Found | Sezione 6.4.3 |
| 303 | See Other | Sezione 6.4.4 |
| 304 | Not Modified | [RFC7232], Sezione 4.1 |
| 305 | Use Proxy | Sezione 6.4.5 |
| 306 | (Unused) | Sezione 6.4.6 |
| 307 | Temporary Redirect | Sezione 6.4.7 |
| 400 | Bad Request | Sezione 6.5.1 |
| 401 | Unauthorized | [RFC7235], Sezione 3.1 |
| 402 | Payment Required | Sezione 6.5.2 |
| 403 | Forbidden | Sezione 6.5.3 |
| 404 | Not Found | Sezione 6.5.4 |
| 405 | Method Not Allowed | Sezione 6.5.5 |
| 406 | Not Acceptable | Sezione 6.5.6 |
| 407 | Proxy Authentication Required | [RFC7235], Sezione 3.2 |
| 408 | Request Timeout | Sezione 6.5.7 |
| 409 | Conflict | Sezione 6.5.8 |
| 410 | Gone | Sezione 6.5.9 |
| 411 | Length Required | Sezione 6.5.10 |
| 412 | Precondition Failed | [RFC7232], Sezione 4.2 |
| 413 | Payload Too Large | Sezione 6.5.11 |
| 414 | URI Too Long | Sezione 6.5.12 |
| 415 | Unsupported Media Type | Sezione 6.5.13 |
| 416 | Range Not Satisfiable | [RFC7233], Sezione 4.4 |
| 417 | Expectation Failed | Sezione 6.5.14 |
| 426 | Upgrade Required | Sezione 6.5.15 |
| 500 | Internal Server Error | Sezione 6.6.1 |
| 501 | Not Implemented | Sezione 6.6.2 |
| 502 | Bad Gateway | Sezione 6.6.3 |
| 503 | Service Unavailable | Sezione 6.6.4 |
| 504 | Gateway Timeout | Sezione 6.6.5 |
| 505 | HTTP Version Not Supported | Sezione 6.6.6 |
8.3. Registrazione del campo di intestazione (Header Field Registration)
Questa specifica aggiorna il registro dei campi di intestazione HTTP definito in [RFC4229] con la procedura di registrazione di [RFC3864].
8.3.1. Considerazioni per i nuovi campi di intestazione (Considerations for New Header Fields)
I campi di intestazione sono componenti chiave del framework di estensibilità HTTP. Definiscono dati aggiuntivi associati a un messaggio o a una risorsa. Ci sono molte considerazioni che devono essere fatte quando si definisce un nuovo campo di intestazione.
I nuovi campi di intestazione devono almeno definire:
- Il nome del campo (Sezione 3.2 di [RFC7230])
- La grammatica attesa del valore del campo
- La semantica del campo
- Per i campi di intestazione di richiesta, come possono sovrascrivere o aumentare la semantica del messaggio
- Per i campi di intestazione di risposta, come modificano l'interpretazione della risposta
- Se il campo deve essere memorizzato da una cache e se può essere restituito nelle risposte a richieste successive
- Se il campo deve essere inoltrato dai proxy
È anche utile documentare:
- Se il campo di intestazione è destinato all'uso da parte di intermediari o solo end-to-end
- Considerazioni sulla sicurezza e sulla privacy (vedere Sezione 9)
- Interazione con altri campi di intestazione
Consigli dettagliati per la definizione di nuovi campi di intestazione sono disponibili in "Linee guida per le specifiche dei campi di intestazione HTTP" [RFC6648bis].
8.3.2. Registrazioni (Registrations)
Il "Registro dei campi di intestazione del protocollo di trasferimento ipertestuale (HTTP)" situato su http://www.iana.org/assignments/message-headers/ dovrebbe essere aggiornato con le registrazioni permanenti seguenti (vedere [RFC3864]):
| Nome del campo di intestazione | Protocollo | Stato | Riferimento |
|---|---|---|---|
| Accept | http | standard | Sezione 5.3.2 |
| Accept-Charset | http | standard | Sezione 5.3.3 |
| Accept-Encoding | http | standard | Sezione 5.3.4 |
| Accept-Language | http | standard | Sezione 5.3.5 |
| Allow | http | standard | Sezione 7.4.1 |
| Content-Encoding | http | standard | Sezione 3.1.2.2 |
| Content-Language | http | standard | Sezione 3.1.3.2 |
| Content-Location | http | standard | Sezione 3.1.4.2 |
| Content-Type | http | standard | Sezione 3.1.1.5 |
| Date | http | standard | Sezione 7.1.1.2 |
| Expect | http | standard | Sezione 5.1.1 |
| From | http | standard | Sezione 5.5.1 |
| Location | http | standard | Sezione 7.1.2 |
| Max-Forwards | http | standard | Sezione 5.1.2 |
| MIME-Version | http | standard | Appendice A.1 |
| Referer | http | standard | Sezione 5.5.2 |
| Retry-After | http | standard | Sezione 7.1.3 |
| Server | http | standard | Sezione 7.4.2 |
| User-Agent | http | standard | Sezione 5.5.3 |
| Vary | http | standard | Sezione 7.1.4 |
Il controller delle modifiche è: "IETF ([email protected]) - Internet Engineering Task Force".
8.4. Registrazione della codifica del contenuto (Content Coding Registration)
Il "Registro della codifica del contenuto HTTP" definisce lo spazio dei nomi per i nomi di codifica del contenuto (Sezione 3.1.2.1). Il registro della codifica del contenuto è stato creato ed è ora mantenuto su http://www.iana.org/assignments/http-parameters.
8.4.1. Procedura (Procedure)
Le registrazioni DEVONO (MUST) includere i seguenti campi:
- Nome (Name)
- Descrizione (Description)
- Puntatore al testo della specifica (Pointer to specification text)
I nomi che iniziano con "x-" sono riservati per uso privato (come definito da [RFC5226]) e pertanto non possono essere registrati.
I valori da aggiungere a questo spazio dei nomi richiedono la revisione IETF (vedere Sezione 4.1 di [RFC5226]).
8.4.2. Registrazioni (Registrations)
Il registro della codifica del contenuto è stato aggiornato con le registrazioni seguenti:
| Nome | Descrizione | Riferimento |
|---|---|---|
| compress | Formato dati "compress" UNIX | Sezione 3.1.2.1 |
| deflate | Dati compressi "deflate" | Sezione 3.1.2.1 |
| gzip | Formato file GZIP | Sezione 3.1.2.1 |
| identity | Riservato (sinonimo per nessuna codifica) | Sezione 3.1.2.1 |