3. Protocol Parameters (Parametri del Protocollo)
3.1 HTTP Version (Versione HTTP)
HTTP utilizza uno schema di numerazione "<major>.<minor>" per indicare le versioni del protocollo. La politica di versione del protocollo è destinata a consentire al mittente di indicare il formato di un messaggio e la sua capacità di comprendere ulteriori comunicazioni HTTP, piuttosto che le funzionalità ottenute tramite tale comunicazione. Nessuna modifica viene apportata al numero di versione per aggiunte ai componenti del messaggio che non influenzano il comportamento di comunicazione o che aggiungono solo a valori di campo estensibili. Il numero <minor> viene incrementato quando le modifiche apportate al protocollo aggiungono funzionalità che non cambiano l'algoritmo generale di analisi del messaggio, ma possono aggiungere alla semantica del messaggio e implicare capacità aggiuntive del mittente. Il numero <major> viene incrementato quando il formato dei messaggi nel protocollo viene modificato. Vedere RFC 2145 [36] per una spiegazione più completa.
La versione di un messaggio HTTP è indicata da un campo HTTP-Version nella prima riga del messaggio.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Si noti che i numeri di versione major e minor devono (MUST) essere trattati come interi separati e che ciascun numero può (MAY) essere incrementato oltre una singola cifra. Pertanto, HTTP/2.4 è una versione inferiore rispetto a HTTP/2.13, che a sua volta è inferiore a HTTP/12.3. Gli zeri iniziali devono (MUST) essere ignorati dai destinatari e non devono (MUST NOT) essere inviati.
Un'applicazione che invia un messaggio di richiesta o risposta contenente "HTTP/1.1" come HTTP-Version deve (MUST) essere almeno condizionalmente conforme a questa specifica. Le applicazioni che sono almeno condizionalmente conformi a questa specifica dovrebbero (SHOULD) utilizzare una HTTP-Version di "HTTP/1.1" nei loro messaggi e devono (MUST) farlo per qualsiasi messaggio che non sia compatibile con HTTP/1.0. Per ulteriori dettagli su quando inviare un valore HTTP-Version specifico, vedere RFC 2145 [36].
La versione HTTP di un'applicazione è la versione HTTP più alta a cui l'applicazione è almeno condizionalmente conforme.
Le applicazioni proxy e gateway devono prestare attenzione quando inoltrano messaggi di una versione di protocollo diversa da quella dell'applicazione. Poiché la versione del protocollo indica la capacità del protocollo del mittente, un proxy/gateway non deve (MUST NOT) inviare un messaggio con un indicatore di versione maggiore della sua versione effettiva. Se viene ricevuta una richiesta di versione superiore, il proxy/gateway deve (MUST) degradare la versione della richiesta, rispondere con un errore o passare al comportamento di tunneling.
A causa di problemi di interoperabilità con i proxy HTTP/1.0 scoperti dalla pubblicazione di RFC 2068 [33], i proxy di caching devono (MUST), i gateway possono (MAY) e i tunnel non devono (MUST NOT) aggiornare la richiesta alla versione più alta che supportano. La risposta del proxy/gateway a tale richiesta deve (MUST) essere nella stessa versione major della richiesta.
Nota: La conversione tra versioni HTTP può comportare la modifica di campi di intestazione richiesti o vietati dalle versioni coinvolte.
3.2 Uniform Resource Identifiers (Identificatori di Risorse Uniformi)
Gli URI hanno molti nomi: indirizzi WWW, Universal Document Identifiers, Universal Resource Identifiers [3], e infine la combinazione di Uniform Resource Locators (URL) [4] e Names (URN) [20]. Per quanto riguarda HTTP, gli Uniform Resource Identifiers sono semplicemente stringhe formattate che identificano una risorsa tramite nome, posizione o qualsiasi altra caratteristica.
3.2.1 General Syntax (Sintassi Generale)
Gli URI in HTTP possono essere rappresentati in forma assoluta o relativamente a un URI di base noto [11], a seconda del contesto del loro utilizzo. La distinzione tra queste due forme è che gli URI assoluti iniziano sempre con un nome di schema seguito da due punti. Per informazioni autorevoli sulla sintassi e la semantica degli URL, vedere "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396 [42] (che sostituisce RFC 1738 [4] e RFC 1808 [11]). Questa specifica adotta le definizioni di "URI-reference", "absoluteURI", "relativeURI", "port", "host", "abs_path", "rel_path" e "authority" da tale specifica.
Il protocollo HTTP non impone alcuna limitazione a priori sulla lunghezza degli URI. I server devono (MUST) essere in grado di gestire gli URI di tutte le risorse che servono e dovrebbero (SHOULD) essere in grado di gestire URI di lunghezza illimitata se forniscono moduli basati su GET che potrebbero generare tali URI. Un server dovrebbe (SHOULD) restituire uno stato 414 (Request-URI Too Long) (vedere sezione 10.4.15) se un URI è più lungo di quanto il server possa gestire.
Nota: I server dovrebbero essere cauti nel fare affidamento su lunghezze di URI superiori a 255 byte, poiché alcune implementazioni di client o proxy più vecchie potrebbero non supportare correttamente tali lunghezze.
3.2.2 http URL
Lo schema "http" viene utilizzato per localizzare risorse di rete tramite il protocollo HTTP. Questa sezione definisce la sintassi e la semantica specifica dello schema dell'URL http.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
Se la porta è vuota o non fornita, si presume la porta 80. La semantica è che la risorsa identificata si trova sul server in ascolto per connessioni TCP su quella porta di quell'host, e la Request-URI della risorsa è abs_path (sezione 5.1.2). L'uso di indirizzi IP negli URL dovrebbe (SHOULD) essere evitato il più possibile (vedere RFC 1900 [24]). Se abs_path non è presente nell'URL, deve (MUST) essere specificato come "/" quando utilizzato come Request-URI per una risorsa (sezione 5.1.2). Se un proxy riceve un nome host che non è un nome di dominio completamente qualificato, può (MAY) aggiungere il suo dominio al nome host ricevuto. Se un proxy riceve un nome di dominio completamente qualificato, il proxy non deve (MUST NOT) modificare il nome host.
3.2.3 URI Comparison (Confronto di URI)
Nel confrontare due URI per determinare se corrispondono, un client dovrebbe (SHOULD) utilizzare un confronto byte per byte sensibile alle maiuscole dell'intero URI, con le seguenti eccezioni:
- Una porta vuota o non fornita è equivalente alla porta predefinita per quel riferimento URI;
- I confronti di nomi host devono (MUST) essere insensibili alle maiuscole;
- I confronti di nomi di schema devono (MUST) essere insensibili alle maiuscole;
- Un abs_path vuoto è equivalente a un abs_path di "/".
I caratteri diversi da quelli negli insiemi "reserved" e "unsafe" (vedere RFC 2396 [42]) sono equivalenti alla loro codifica "%HEX HEX".
Ad esempio, i seguenti tre URI sono equivalenti:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
3.3 Date/Time Formats (Formati Data/Ora)
3.3.1 Full Date (Data Completa)
Le applicazioni HTTP hanno storicamente consentito tre diversi formati di rappresentazione di data/ora:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
Il primo formato è preferito come standard Internet e rappresenta un sottoinsieme di lunghezza fissa di quello definito da RFC 1123 [8] (un aggiornamento di RFC 822 [9]). Il secondo formato è di uso comune, ma si basa sul formato data obsoleto RFC 850 [12] e manca di un anno a quattro cifre. I client e server HTTP/1.1 che analizzano il valore data devono (MUST) accettare tutti e tre i formati (per compatibilità con HTTP/1.0), ma devono (MUST) generare solo il formato RFC 1123 per rappresentare valori HTTP-date nei campi di intestazione. Vedere sezione 19.3 per ulteriori informazioni.
Nota: I destinatari di valori data sono incoraggiati ad essere robusti nell'accettare valori data che potrebbero essere stati inviati da applicazioni non HTTP, il che a volte si verifica quando si recuperano o pubblicano messaggi tramite proxy/gateway a SMTP o NNTP.
Tutti i timestamp data/ora HTTP devono (MUST) essere rappresentati in Greenwich Mean Time (GMT), senza eccezioni. Per HTTP, GMT è esattamente uguale a UTC (Coordinated Universal Time). Questo è indicato nei primi due formati includendo "GMT" come abbreviazione di tre lettere per il fuso orario, e deve (MUST) essere assunto quando si legge il formato asctime. HTTP-date è sensibile alle maiuscole e non deve (MUST NOT) includere LWS aggiuntivo oltre a quello esplicitamente incluso come SP nella grammatica.
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
Nota: I requisiti HTTP per i formati di data/timestamp si applicano solo al loro utilizzo nel flusso di protocollo. I client e i server non sono tenuti a utilizzare questi formati per la presentazione all'utente, i registri delle richieste, ecc.
3.3.2 Delta Seconds (Secondi Delta)
Alcuni campi di intestazione HTTP consentono di specificare un valore temporale come numero intero di secondi, rappresentato in decimale, dopo il momento della ricezione del messaggio.
delta-seconds = 1*DIGIT
3.4 Character Sets (Set di Caratteri)
HTTP utilizza la stessa definizione del termine "set di caratteri" (character set) descritta in MIME:
Il termine "set di caratteri" è utilizzato in questo documento per riferirsi a un metodo utilizzato con una o più tabelle per convertire una sequenza di ottetti in una sequenza di caratteri. Si noti che la conversione incondizionale nella direzione opposta non è richiesta, in quanto non tutti i caratteri devono essere necessariamente disponibili in un dato set di caratteri e un set di caratteri può fornire più sequenze di ottetti per rappresentare un particolare carattere. Questa definizione ha lo scopo di consentire varie codifiche di caratteri, dalle semplici mappature di tabelle singole come US-ASCII ai metodi complessi di cambio di tabella come quelli che utilizzano tecniche ISO-2022. Tuttavia, la definizione associata a un nome di set di caratteri MIME deve (MUST) specificare completamente la mappatura da eseguire dagli ottetti ai caratteri. In particolare, l'uso di informazioni di profilo esterne per determinare la mappatura esatta non è consentito.
Nota: Questo uso del termine "set di caratteri" (character set) è più comunemente chiamato "codifica di caratteri" (character encoding). Tuttavia, poiché HTTP e MIME condividono lo stesso registro, è importante che i termini siano condivisi.
I set di caratteri HTTP sono identificati da token insensibili alle maiuscole. L'insieme completo di token è definito dal registro dei set di caratteri IANA [19].
charset = token
Sebbene HTTP consenta l'uso di un token arbitrario come valore di set di caratteri, qualsiasi token che abbia un valore predefinito nel registro dei set di caratteri IANA [19] deve (MUST) rappresentare il set di caratteri definito da tale registro. Le applicazioni dovrebbero (SHOULD) limitare il loro uso di set di caratteri a quelli definiti dal registro IANA.
Gli implementatori dovrebbero essere consapevoli dei requisiti IETF relativi ai set di caratteri [38] [41].
3.4.1 Missing Charset (Set di Caratteri Mancante)
Alcuni software HTTP/1.0 hanno erroneamente interpretato un'intestazione Content-Type senza parametro charset come "il destinatario dovrebbe indovinare". I mittenti che desiderano sconfiggere questo comportamento possono (MAY) includere un parametro charset quando il set di caratteri è ISO-8859-1 e dovrebbero (SHOULD) farlo se è noto che ciò non confonderà il destinatario.
Sfortunatamente, alcuni vecchi client HTTP/1.0 non hanno gestito correttamente un parametro charset esplicito. I destinatari HTTP/1.1 devono (MUST) rispettare l'etichetta del set di caratteri fornita dal mittente; gli user agent che hanno una disposizione a "indovinare" il set di caratteri devono (MUST) utilizzare il set di caratteri dal campo content-type invece del set di caratteri dedotto dal destinatario, anche se il mittente è un client HTTP/1.0.
3.5 Content Codings (Codifiche di Contenuto)
I valori di codifica del contenuto indicano una trasformazione di codifica che è stata o può essere applicata a un'entità. Le codifiche di contenuto sono utilizzate principalmente per consentire la compressione di un documento senza perdere l'identità del suo tipo di media sottostante e senza perdere informazioni. Le entità sono normalmente archiviate in forma codificata solo quando la loro rappresentazione sottostante è codificata per la trasmissione.
content-coding = token
Tutti i valori di codifica del contenuto sono insensibili alle maiuscole. HTTP/1.1 utilizza valori di codifica del contenuto nei campi di intestazione Accept-Encoding e Content-Encoding. Sebbene il valore descriva la codifica del contenuto applicata al corpo dell'entità, è più importante che indichi quale meccanismo di decodifica può essere applicato per ottenere il tipo di media riferito dal campo di intestazione Content-Type.
L'Internet Assigned Numbers Authority (IANA) funge da registro per i token di valore della codifica del contenuto. Inizialmente, il registro contiene i seguenti token:
gzip Un formato di codifica che utilizza la codifica Lempel-Ziv (LZ77) con un CRC a 32 bit, come descritto in RFC 1952 [25]. Questo formato di codifica è prodotto dal programma UNIX gzip. Gli implementatori HTTP/1.1 sono informati che, per ragioni storiche, alcuni destinatari trattano "x-gzip" e "gzip" come equivalenti.
compress Il formato di codifica prodotto utilizzando l'algoritmo Lempel-Ziv-Welch (LZW). Questo formato di codifica è prodotto dal programma comune di compressione file UNIX "compress". I destinatari dovrebbero trattare "x-compress" e "compress" come equivalenti per ragioni storiche.
deflate La combinazione del formato "zlib" descritto in RFC 1950 [31] e del meccanismo di compressione "deflate" descritto in RFC 1951 [29].
identity La codifica predefinita (identità); l'uso di questa codifica di contenuto indica solo che non è stata eseguita alcuna codifica. Questa codifica di contenuto è utilizzata nel campo di intestazione Accept-Encoding e non dovrebbe (SHOULD NOT) essere utilizzata nel campo di intestazione Content-Encoding.
I nuovi token di codifica del contenuto dovrebbero essere registrati presso l'Internet Assigned Numbers Authority (IANA).
3.6 Transfer Codings (Codifiche di Trasferimento)
I valori di codifica di trasferimento sono utilizzati per indicare una trasformazione di codifica che è stata, può essere o potrebbe dover essere applicata al corpo dell'entità per garantire un "trasferimento sicuro" attraverso la rete. Questo differisce da una codifica di contenuto in quanto la codifica di trasferimento è una proprietà del messaggio, piuttosto che dell'entità originale.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
I parametri assumono la forma di coppie attributo/valore.
parameter = attribute "=" value
attribute = token
value = token | quoted-string
Tutti i valori di codifica di trasferimento sono insensibili alle maiuscole. HTTP/1.1 utilizza valori di codifica di trasferimento nel campo di intestazione TE (sezione 14.39) e nel campo di intestazione Transfer-Encoding (sezione 14.41).
Le codifiche di trasferimento sono una nuova funzionalità di HTTP/1.1. I mittenti non devono (MUST NOT) applicare una codifica di trasferimento al corpo di un messaggio a meno che il messaggio non sia indicato come HTTP/1.1 o superiore.
3.6.1 Chunked Transfer Coding (Codifica di Trasferimento Chunked)
La codifica chunked modifica il corpo del messaggio per trasferirlo come una serie di chunk, ciascuno con il proprio indicatore di dimensione, seguito da un trailer opzionale contenente campi di intestazione di entità. Ciò consente di trasferire contenuti generati dinamicamente insieme alle informazioni di controllo dell'integrità necessarie sul messaggio.
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
Il campo chunk-size è una stringa di cifre esadecimali che indica la dimensione dei dati del chunk. La codifica chunked termina con un chunk di dimensione zero, seguito dal trailer, che termina con una riga vuota.
Il trailer consente al mittente di includere campi di intestazione HTTP aggiuntivi alla fine del messaggio. Il campo di intestazione Trailer (sezione 14.40) può essere utilizzato per indicare quali campi di intestazione sono inclusi nel trailer.
Non è consentito includere campi di intestazione del messaggio nel trailer a meno che non siano esplicitamente autorizzati, come descritto nella sezione 7.1.
Un server può (MAY) utilizzare la codifica di trasferimento chunked se le codifiche di trasferimento accettabili del destinatario includono la codifica di trasferimento chunked. La presenza del trailer può essere indicata includendo un campo di intestazione Trailer nel messaggio.
Un'applicazione che riceve un corpo di messaggio chunked deve (MUST) ignorare le estensioni di chunk che non comprende, a meno che l'estensione di chunk corrispondente non sia definita da un campo di intestazione Trailer.
3.7 Media Types (Tipi di Media)
HTTP utilizza i tipi di media Internet [17] nei campi di intestazione Content-Type (sezione 14.17) e Accept (sezione 14.1) per fornire tipizzazione di dati aperta ed estensibile e negoziazione di tipo relativa ai tipi di dati.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
I tipi, i sottotipi e i nomi degli attributi dei parametri sono insensibili alle maiuscole. I valori dei parametri possono essere sensibili o insensibili alle maiuscole, a seconda della semantica del nome del parametro. Lo spazio lineare (LWS) non deve (MUST NOT) essere utilizzato tra il tipo e il sottotipo, né tra un attributo e il suo valore. Gli user agent dovrebbero (SHOULD) rispettare l'etichetta del set di caratteri identificata dai parametri del tipo di media (sezione 3.4).
La presenza di un valore di tipo di media non implica che debba essere presente un corpo di entità nel messaggio HTTP. Per alcuni metodi o risposte di alcuni codici di risposta, un messaggio di risposta può includere un campo di intestazione Content-Type anche se il messaggio non include un corpo di entità. Tali messaggi di risposta iniziano con una riga vuota che termina i campi di intestazione piuttosto che con un corpo di entità.
3.7.1 Canonicalization and Text Defaults (Canonizzazione e Impostazioni Predefinite del Testo)
I tipi di media Internet registrati con il tipo principale "text" standard adottano le stesse regole di MIME. Ciò significa che se il parametro "charset" non è incluso nel campo di intestazione Content-Type di un tipo di media con tipo principale "text", il destinatario dovrebbe (SHOULD) trattarlo come avente un set di caratteri "ISO-8859-1" (vedere sezione 3.4.1). I dati di un flusso di byte "text" in HTTP sono inviati in "forma canonica" (canonical form); cioè, HTTP non esegue alcuna traduzione delle sequenze di fine riga CRLF.
3.7.2 Multipart Types (Tipi Multipart)
MIME fornisce una serie di tipi multipart - incapsulando una o più entità in un singolo corpo di messaggio. Tutti i tipi multipart condividono una sintassi comune, come definito nella sezione 5.1 di MIME [7], e devono (MUST) includere un parametro boundary come parte del valore del tipo di media. Il corpo del messaggio stesso è un elemento di protocollo e deve (MUST) quindi utilizzare CRLF come separatore di riga tra due parti del corpo. A differenza di MIME, la fine di un corpo multipart in HTTP deve (MUST) essere contrassegnata con un delimitatore boundary finale.
In HTTP, le stesse semantiche dovrebbero (SHOULD) essere seguite per l'intestazione Content-Location per i tipi multipart come in MIME; tuttavia, in HTTP, qualsiasi parte del corpo con un'intestazione Content-Location è trattata come avente un'identità indipendente, anche se corrisponde al Content-Location esterno del suo messaggio contenitore.
In generale, HTTP tratta le parti del corpo multipart come risorse separate, ciascuna con il proprio URI. Ciò consente di inviare più risorse in parallelo o in sequenza in un singolo messaggio e supporta le risposte 206 (Partial Content).
3.8 Product Tokens (Token di Prodotto)
I token di prodotto sono utilizzati per consentire alle applicazioni comunicanti di identificarsi tramite nome e versione del software. La maggior parte dei campi che utilizzano token di prodotto consente anche di elencare sottoprodotti che costituiscono una parte significativa dell'applicazione, separati da spazi. Per convenzione, i prodotti sono elencati in ordine decrescente di importanza per l'applicazione.
product = token ["/" product-version]
product-version = token
Esempi:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
I token di prodotto dovrebbero (SHOULD) essere brevi e insignificanti. Non devono (MUST NOT) essere utilizzati per pubblicità o altre informazioni non essenziali. Sebbene qualsiasi carattere token possa apparire in una versione di prodotto, questo token dovrebbe (SHOULD) essere utilizzato solo per una versione del prodotto (cioè, le versioni successive dovrebbero differire solo nel valore del token della versione del prodotto).
3.9 Quality Values (Valori di Qualità)
La negoziazione del contenuto HTTP (sezione 12) utilizza numeri "in virgola mobile" brevi per indicare l'importanza relativa ("peso") di vari parametri negoziabili. I pesi sono normalizzati a valori reali tra 0 e 1, dove 0 è il valore minimo e 1 il massimo. Le applicazioni HTTP/1.1 non devono (MUST NOT) generare valori di qualità con più di tre decimali. La configurazione utente di questi valori dovrebbe essere limitata in modo simile.
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
Il concetto di "valore di qualità" si applica alla selezione di qualsiasi contenuto (vedere sezione 14.1), set di caratteri (sezione 14.2), codifica di contenuto (sezione 14.3), lingua (sezione 14.4) o codifica di trasferimento (sezione 14.39). Tuttavia, per brevità, il termine "valore di qualità" utilizzato in questa sezione si riferisce a una qualsiasi di queste caratteristiche associate a quel valore di qualità.
3.10 Language Tags (Tag di Lingua)
Un tag di lingua identifica una lingua naturale, come l'inglese o il francese, composta da una o più parti: un tag di lingua primario e possibilmente una serie di sub-tag:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Gli spazi non sono consentiti all'interno del tag e tutti i tag sono insensibili alle maiuscole. Lo spazio dei nomi dei tag è gestito da IANA. I tag di esempio includono:
en, en-US, en-cockney, i-cherokee, x-pig-latin
dove qualsiasi tag primario di due caratteri è un'abbreviazione di lingua ISO-639 [34] e qualsiasi sub-tag iniziale di due caratteri è un codice paese ISO-3166 [35]. (L'ultima versione offline di ISO 639 al momento della stesura di questo documento è [35], ma ci si dovrebbe aspettare che questo standard continui ad evolversi nel tempo.)
3.11 Entity Tags (Tag di Entità)
I tag di entità sono utilizzati per il confronto tra più rappresentazioni della stessa risorsa richiesta. I tag di entità consistono in una stringa opaca tra virgolette, eventualmente preceduta da un indicatore di debolezza (vedere sezione 13.3.3).
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
Un "tag di entità forte" (strong entity tag) può essere utilizzato ogni volta che viene utilizzato un tag di entità, indipendentemente da come cambia il valore dell'entità. Un "tag di entità debole" (weak entity tag) viene utilizzato solo per confronti deboli quando l'equivalenza semantica del valore dell'entità, piuttosto che l'equivalenza di byte, è sufficiente.
Un tag di entità debole può essere utilizzato solo per confronti deboli. Un tag di entità senza prefisso di indicatore di debolezza è un tag di entità forte.
I tag di entità devono (MUST) essere univoci per due entità di una particolare risorsa, a meno che le semantiche di tali entità non siano equivalenti.
3.12 Range Units (Unità di Intervallo)
HTTP/1.1 consente a un client di richiedere che venga trasferita solo una parte (intervallo) dell'entità di risposta. HTTP/1.1 utilizza unità di intervallo nei campi di intestazione Range (sezione 14.35), Content-Range (sezione 14.16) e Accept-Ranges (sezione 14.5). Un'entità può essere suddivisa in sotto-intervalli secondo diverse unità strutturali.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
L'unica unità di intervallo in HTTP/1.1 è "bytes". Le implementazioni HTTP/1.1 possono (MAY) ignorare le specifiche di unità di intervallo che non comprendono.
HTTP/1.1 è stato registrato per l'unità di intervallo "bytes". L'appendice include la registrazione di alcune altre unità di intervallo.