2. Conformance (Conformità)
2.1. Syntax Notation (Notazione sintattica)
Questa specifica utilizza la notazione della forma di Backus-Naur aumentata (Augmented Backus-Naur Form, ABNF) di [RFC5234], estesa con la notazione per la sensibilità alle maiuscole/minuscole nelle stringhe definita in [RFC7405].
Utilizza anche un'estensione di lista, definita nella sezione 5.6.1, che consente una definizione compatta di elenchi separati da virgole utilizzando un operatore "#" (simile a come l'operatore "*" indica la ripetizione). L'appendice A mostra la grammatica raccolta con tutti gli operatori di lista espansi alla notazione ABNF standard.
Per convenzione, i nomi delle regole ABNF con prefisso "obs-" denotano regole grammaticali obsolete che appaiono per ragioni storiche.
Le seguenti regole di base sono incluse per riferimento, come definito nell'appendice B.1 di [RFC5234]: ALPHA (lettere), CR (ritorno a capo), CRLF (CR LF), CTL (controlli), DIGIT (decimale 0-9), DQUOTE (virgolette doppie), HEXDIG (esadecimale 0-9/A-F/a-f), HTAB (tabulazione orizzontale), LF (avanzamento riga), OCTET (qualsiasi sequenza di dati a 8 bit), SP (spazio) e VCHAR (qualsiasi carattere US-ASCII visibile).
La sezione 5.6 definisce alcuni componenti sintattici generici per i valori dei campi.
Questa specifica utilizza i termini "character" (carattere), "character encoding scheme" (schema di codifica dei caratteri), "charset" (set di caratteri) e "protocol element" (elemento di protocollo) come sono definiti in [RFC6365].
2.2. Requirements Notation (Notazione dei requisiti)
Le parole chiave "MUST" (deve), "MUST NOT" (non deve), "REQUIRED" (richiesto), "SHALL" (deve), "SHALL NOT" (non deve), "SHOULD" (dovrebbe), "SHOULD NOT" (non dovrebbe), "RECOMMENDED" (raccomandato), "NOT RECOMMENDED" (non raccomandato), "MAY" (può) e "OPTIONAL" (opzionale) in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.
Questa specifica mira ai criteri di conformità in base al ruolo di un partecipante nella comunicazione HTTP. Pertanto, i requisiti sono posti su mittenti (Senders), destinatari (Recipients), client (Clients), server (Servers), agenti utente (User Agents), intermediari (Intermediaries), server di origine (Origin Servers), proxy (Proxies), gateway (Gateways) o cache (Caches), a seconda del comportamento vincolato dal requisito. Requisiti aggiuntivi sono posti su implementazioni (Implementations), proprietari di risorse (Resource Owners) e registrazioni di elementi di protocollo (Protocol Element Registrations) quando si applicano oltre l'ambito di una singola comunicazione.
Il verbo "generate" (generare) è usato al posto di "send" (inviare) quando un requisito si applica solo alle implementazioni che creano l'elemento di protocollo, piuttosto che a un'implementazione che inoltra un elemento ricevuto a valle.
Un'implementazione è considerata conforme se rispetta tutti i requisiti associati ai ruoli che svolge in HTTP.
Un mittente non deve (MUST NOT) generare elementi di protocollo che non corrispondono alla grammatica definita dalle regole ABNF corrispondenti. All'interno di un dato messaggio, un mittente non deve (MUST NOT) generare elementi di protocollo o alternative sintattiche che possono essere generati solo da partecipanti in altri ruoli (cioè, un ruolo che il mittente non ha per quel messaggio).
La conformità a HTTP include sia la conformità alla particolare sintassi di messaggistica della versione del protocollo in uso sia la conformità alla semantica degli elementi di protocollo inviati. Ad esempio, un client che dichiara conformità a HTTP/1.1 ma non riesce a riconoscere le funzionalità richieste dai destinatari HTTP/1.1 non riuscirà a interoperare con i server che adattano le loro risposte in conformità con tali dichiarazioni. Le funzionalità che riflettono le scelte dell'utente, come la negoziazione del contenuto (Content Negotiation) e le estensioni selezionate dall'utente, possono influenzare il comportamento dell'applicazione oltre il flusso del protocollo; l'invio di elementi di protocollo che riflettono in modo impreciso le scelte di un utente confonderà l'utente e inibirà la scelta.
Quando un'implementazione non riesce a conformarsi semanticamente, i destinatari dei messaggi di tale implementazione svilupperanno eventualmente soluzioni alternative (Workarounds) per adattare il loro comportamento di conseguenza. Un destinatario può (MAY) impiegare tali soluzioni alternative rimanendo conforme a questo protocollo se le soluzioni alternative sono limitate alle implementazioni difettose. Ad esempio, i server spesso scansionano porzioni del valore del campo User-Agent, e gli agenti utente spesso scansionano il valore del campo Server, per adattare il proprio comportamento rispetto a bug noti o valori predefiniti scelti male.
2.3. Length Requirements (Requisiti di lunghezza)
Un destinatario dovrebbe (SHOULD) analizzare un elemento di protocollo ricevuto in modo difensivo, con solo aspettative marginali che l'elemento si conformi alla sua grammatica ABNF e rientri in una dimensione di buffer ragionevole.
HTTP non ha limitazioni di lunghezza specifiche per molti dei suoi elementi di protocollo perché le lunghezze che potrebbero essere appropriate varieranno ampiamente, a seconda del contesto di distribuzione e dello scopo dell'implementazione. Pertanto, l'interoperabilità tra mittenti e destinatari dipende da aspettative condivise riguardo a ciò che è una lunghezza ragionevole per ciascun elemento di protocollo. Inoltre, ciò che è comunemente inteso come una lunghezza ragionevole per alcuni elementi di protocollo è cambiato nel corso degli ultimi tre decenni di utilizzo di HTTP e si prevede che continuerà a cambiare in futuro.
Come minimo, un destinatario deve (MUST) essere in grado di analizzare e elaborare lunghezze di elementi di protocollo che sono almeno lunghe quanto i valori che genera per quegli stessi elementi di protocollo in altri messaggi. Ad esempio, un server di origine che pubblica riferimenti URI molto lunghi alle proprie risorse deve essere in grado di analizzare e elaborare quegli stessi riferimenti quando ricevuti come URI di destinazione.
Molti elementi di protocollo ricevuti vengono analizzati solo nella misura necessaria per identificare e inoltrare quell'elemento a valle. Ad esempio, un intermediario potrebbe analizzare un campo ricevuto nei suoi componenti nome campo e valore campo, ma poi inoltrare il campo senza ulteriori analisi all'interno del valore del campo.
2.4. Error Handling (Gestione degli errori)
Un destinatario deve (MUST) interpretare un elemento di protocollo ricevuto secondo la semantica definita per esso da questa specifica, incluse le estensioni a questa specifica, a meno che il destinatario non abbia determinato (attraverso l'esperienza o la configurazione) che il mittente implementa in modo errato ciò che è implicato da quella semantica. Ad esempio, un server di origine potrebbe ignorare il contenuto di un campo di intestazione Accept-Encoding ricevuto se l'ispezione del campo di intestazione User-Agent indica una versione di implementazione specifica nota per fallire alla ricezione di determinate codifiche di contenuto.
Salvo diversa indicazione, un destinatario può (MAY) tentare di recuperare un elemento di protocollo utilizzabile da un costrutto non valido. HTTP non definisce meccanismi specifici di gestione degli errori tranne quando hanno un impatto diretto sulla sicurezza, poiché diverse applicazioni del protocollo richiedono diverse strategie di gestione degli errori. Ad esempio, un browser Web potrebbe desiderare di recuperare in modo trasparente da una risposta in cui il campo di intestazione Location non viene analizzato secondo l'ABNF, mentre un client di controllo dei sistemi potrebbe considerare qualsiasi forma di recupero degli errori come pericolosa.
Alcune richieste possono essere automaticamente ritentate da un client in caso di guasto della connessione sottostante, come descritto nella sezione 9.2.2.
2.5. Protocol Version (Versione del protocollo)
Il numero di versione di HTTP è composto da due cifre decimali separate da un "." (punto o virgola decimale). La prima cifra (versione maggiore, Major Version) indica la sintassi di messaggistica, mentre la seconda cifra (versione minore, Minor Version) indica la versione minore più alta all'interno di quella versione maggiore a cui il mittente è conforme (in grado di comprendere per comunicazioni future).
Mentre la semantica di base di HTTP non cambia tra le versioni del protocollo, la loro espressione "sul filo" può cambiare, e quindi il numero di versione HTTP cambia quando vengono apportate modifiche incompatibili al formato del filo. Inoltre, HTTP consente modifiche incrementali e retrocompatibili al protocollo senza cambiarne la versione attraverso l'uso di punti di estensione definiti (sezione 16).
La versione del protocollo nel suo insieme indica la conformità del mittente con l'insieme di requisiti stabiliti nelle specifiche corrispondenti di quella versione. Ad esempio, la versione "HTTP/1.1" è definita dalle specifiche combinate di questo documento, "HTTP Caching" [CACHING] e "HTTP/1.1" [HTTP/1.1].
Il numero di versione maggiore di HTTP viene incrementato quando viene introdotta una sintassi di messaggio incompatibile. Il numero minore viene incrementato quando le modifiche apportate al protocollo hanno l'effetto di aggiungere alla semantica del messaggio o di implicare capacità aggiuntive del mittente.
La versione minore pubblicizza le capacità di comunicazione del mittente anche quando il mittente utilizza solo un sottoinsieme retrocompatibile del protocollo, consentendo così al destinatario di sapere che funzionalità più avanzate possono essere utilizzate in risposta (dai server) o in richieste future (dai client).