17. References (Riferimenti)
17 Riferimenti
I riferimenti seguenti conservano le informazioni bibliografiche dell'RFC originale. Per non compromettere l'accuratezza delle citazioni, i nomi degli autori, i titoli dei documenti, i numeri di RFC, i dati di pubblicazione e gli URL sono mantenuti nella loro forma originale in inglese.
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D. and B. Alberti, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", RFC 1436, March 1993.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC 1630, June 1994.
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1123, October 1989.
[9] Crocker, D., "Standard for The Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype Functional Specification," (v1.5), Thinking Machines Corporation, April 1990.
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[12] Horton, M. and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987.
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995.
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, November 1996.
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[20] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[22] ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[25] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat ency.html.
[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>, ISI Research Report ISI/RR-98-463, (original report dated Aug. 1996), USC/Information Sciences Institute, August 1998.
[28] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[30] S. Spero, "Analysis of HTTP Performance Problems," http://sunsite.unc.edu/mdma-release/http-prob.html.
[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[35] Troost, R. and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997. [jg639]
[37] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [jg640]
[38] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO-10646", RFC 2279, January 1998. [jg641]
[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., Lie, H., and C. Lilley. "Network Performance Effects of HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes France, September 1997.[jg642]
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [jg643]
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [jg644]
[42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396, August 1998. [jg645]
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [jg646]
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers," Work in Progress. [jg647]
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997.
[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998.
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
18 Indirizzi degli autori (Authors' Addresses)
Roy T. Fielding Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA
Fax: +1 (949) 824-1715 EMail: [email protected]
James Gettys World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, USA
EMail: [email protected]
Henrik Frystyk Nielsen World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94034, USA
EMail: [email protected]
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
EMail: [email protected]
Tim Berners-Lee Director, World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
19 Appendici (Appendices)
19.1 Internet Media Type message/http and application/http (Tipi di media Internet message/http e application/http)
Oltre a definire il protocollo HTTP/1.1, questo documento funge da specifica per i tipi di media Internet "message/http" e "application/http". Il tipo message/http può essere utilizzato per racchiudere un singolo messaggio di richiesta o di risposta HTTP, purché rispetti le restrizioni MIME relative alla lunghezza delle righe e alle codifiche valide per tutti i tipi "message". Il tipo application/http può essere utilizzato per racchiudere una pipeline di uno o più messaggi di richiesta o di risposta HTTP (non mescolati tra loro). Quanto segue deve essere registrato presso la IANA [17].
Media Type name: message
Media subtype name: http
Required parameters: none
Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed message
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first
line of the body.
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
Media Type name: application
Media subtype name: http
Required parameters: none
Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed messages
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first
line of the body.
Encoding considerations: HTTP messages enclosed by this type
are in "binary" format; use of an appropriate
Content-Transfer-Encoding is required when
transmitted via E-mail.
Security considerations: none
19.2 Internet Media Type multipart/byteranges (Tipo di media Internet multipart/byteranges)
Quando un messaggio di risposta HTTP 206 (Partial Content) include il contenuto di più intervalli (una risposta a una richiesta di più intervalli non sovrapposti), questi vengono trasmessi come corpo di messaggio multiparte. Il tipo di media utilizzato a tale scopo si chiama "multipart/byteranges".
Il tipo di media multipart/byteranges comprende due o più parti, ciascuna con i propri campi Content-Type e Content-Range. Il parametro boundary, obbligatorio, specifica la stringa di delimitazione utilizzata per separare ciascuna parte del corpo.
Media Type name: multipart
Media subtype name: byteranges
Required parameters: boundary
Optional parameters: none
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
Per esempio:
HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 500-999/8000
...the first range... --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 7000-7999/8000
...the second range --THIS_STRING_SEPARATES--
Note:
1) Ulteriori CRLF possono precedere la prima stringa di
delimitazione nell'entità.
2) Sebbene l'RFC 2046 [40] consenta di racchiudere tra virgolette
la stringa di delimitazione, alcune implementazioni esistenti
gestiscono in modo errato una stringa di delimitazione tra
virgolette.
3) Diversi browser e server sono stati programmati sulla base di
una prima bozza della specifica byteranges e utilizzano il tipo
di media multipart/x-byteranges, che è quasi, ma non del tutto,
compatibile con la versione documentata in HTTP/1.1.
19.3 Tolerant Applications (Applicazioni tolleranti)
Sebbene questo documento specifichi i requisiti per la generazione dei messaggi HTTP/1.1, non tutte le applicazioni saranno corrette nella loro implementazione. Raccomandiamo pertanto che le applicazioni operative siano tolleranti verso le deviazioni ogniqualvolta tali deviazioni possano essere interpretate in modo non ambiguo.
I client DOVREBBERO essere tolleranti nell'analisi della Status-Line e i server nell'analisi della Request-Line. In particolare, DOVREBBERO accettare un numero qualsiasi di caratteri SP o HT tra i campi, anche se è richiesto un solo SP.
Il terminatore di riga per i campi di intestazione del messaggio è la sequenza CRLF. Tuttavia, raccomandiamo che le applicazioni, nell'analizzare tali intestazioni, riconoscano un singolo LF come terminatore di riga e ignorino il CR che lo precede.
Il set di caratteri di un corpo di entità DOVREBBE essere etichettato come il minimo comune denominatore dei codici di carattere utilizzati all'interno di tale corpo, con l'eccezione che è preferibile non etichettare l'entità piuttosto che etichettarla con le etichette US-ASCII o ISO-8859-1. Si vedano le sezioni 3.7.1 e 3.4.1.
Ulteriori regole relative ai requisiti di analisi e codifica delle date, nonché altri potenziali problemi legati alla codifica delle date, comprendono:
- I client e le cache HTTP/1.1 DOVREBBERO presumere che una data
RFC-850 che sembra collocarsi a più di 50 anni nel futuro sia in
realtà nel passato (ciò contribuisce a risolvere il problema
dell'"anno 2000").
- Un'implementazione HTTP/1.1 PUÒ rappresentare internamente una
data Expires analizzata come anteriore al valore corretto, ma NON
DEVE rappresentarla internamente come posteriore al valore
corretto.
- Tutti i calcoli relativi alla scadenza DEVONO essere effettuati
in GMT. Il fuso orario locale NON DEVE influenzare il calcolo o
il confronto di un'età o di un istante di scadenza.
- Se un'intestazione HTTP trasmette erroneamente un valore di data
con un fuso orario diverso da GMT, esso DEVE essere convertito in
GMT utilizzando la conversione più conservativa possibile.
19.4 Differences Between HTTP Entities and RFC 2045 Entities (Differenze tra le entità HTTP e le entità RFC 2045)
HTTP/1.1 utilizza molti dei costrutti definiti per la posta Internet (RFC 822 [9]) e le Multipurpose Internet Mail Extensions (MIME [7]) per consentire la trasmissione di entità in una molteplicità di rappresentazioni e mediante meccanismi estensibili. Tuttavia, l'RFC 2045 tratta della posta elettronica, e HTTP presenta alcune caratteristiche che differiscono da quelle descritte nell'RFC 2045. Tali differenze sono state scelte con cura al fine di ottimizzare le prestazioni su connessioni binarie, consentire maggiore libertà nell'uso di nuovi tipi di media, facilitare i confronti tra date e riconoscere la prassi di alcuni dei primi server e client HTTP.
Questa appendice descrive aree specifiche in cui HTTP differisce dall'RFC 2045. I proxy e i gateway verso ambienti MIME rigorosi DOVREBBERO essere consapevoli di queste differenze e fornire le conversioni appropriate ove necessario. Anche i proxy e i gateway da ambienti MIME verso HTTP devono essere consapevoli di tali differenze, poiché alcune conversioni potrebbero rendersi necessarie.
19.4.1 MIME-Version
HTTP non è un protocollo conforme a MIME. Tuttavia, i messaggi HTTP/1.1 POSSONO includere un singolo campo di intestazione generale MIME-Version per indicare quale versione del protocollo MIME è stata utilizzata per costruire il messaggio. L'uso del campo di intestazione MIME-Version indica che il messaggio è in piena conformità con il protocollo MIME (come definito nell'RFC 2045[7]). I proxy/gateway sono responsabili di garantire la piena conformità (ove possibile) quando esportano messaggi HTTP verso ambienti MIME rigorosi.
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
La versione MIME "1.0" è quella predefinita per l'uso in HTTP/1.1. Tuttavia, l'analisi e la semantica dei messaggi HTTP/1.1 sono definite dal presente documento e non dalla specifica MIME.
19.4.2 Conversion to Canonical Form (Conversione nella forma canonica)
L'RFC 2045 [7] richiede che le entità di posta Internet siano convertite nella forma canonica prima di essere trasferite, come descritto nella sezione 4 dell'RFC 2049 [48]. La sezione 3.7.1 del presente documento descrive le forme consentite per i sottotipi del tipo di media "text" quando trasmessi tramite HTTP. L'RFC 2046 richiede che il contenuto di tipo "text" rappresenti le interruzioni di riga come CRLF e vieta l'uso di CR o LF al di fuori delle sequenze di interruzione di riga. HTTP consente l'uso di CRLF, di un CR isolato e di un LF isolato per indicare un'interruzione di riga all'interno di un contenuto testuale quando un messaggio è trasmesso tramite HTTP.
Ove possibile, un proxy o un gateway da HTTP verso un ambiente MIME rigoroso DOVREBBE convertire tutte le interruzioni di riga presenti nei tipi di media testuali descritti nella sezione 3.7.1 del presente documento nella forma canonica CRLF dell'RFC 2049. Si noti tuttavia che ciò può essere complicato dalla presenza di un Content-Encoding e dal fatto che HTTP consente l'uso di alcuni set di caratteri che non impiegano gli ottetti 13 e 10 per rappresentare CR e LF, come avviene per taluni set di caratteri multibyte.
Gli implementatori devono tenere presente che la conversione distruggerà qualsiasi checksum crittografico applicato al contenuto originale, a meno che tale contenuto originale non sia già in forma canonica. Pertanto, la forma canonica è raccomandata per qualsiasi contenuto che faccia uso di tali checksum in HTTP.
19.4.3 Conversion of Date Formats (Conversione dei formati di data)
HTTP/1.1 utilizza un insieme ristretto di formati di data (sezione 3.3.1) al fine di semplificare il processo di confronto tra date. I proxy e i gateway provenienti da altri protocolli DOVREBBERO assicurarsi che qualsiasi campo di intestazione Date presente in un messaggio sia conforme a uno dei formati HTTP/1.1 e riscrivere la data se necessario.
19.4.4 Introduction of Content-Encoding (Introduzione di Content-Encoding)
L'RFC 2045 non contempla alcun concetto equivalente al campo di
intestazione Content-Encoding di HTTP/1.1. Poiché esso funge da
modificatore del tipo di media, i proxy e i gateway da HTTP verso
protocolli conformi a MIME DEVONO o modificare il valore del campo di
intestazione Content-Type, oppure decodificare il corpo dell'entità
prima di inoltrare il messaggio. (Alcune applicazioni sperimentali di
Content-Type per la posta Internet hanno impiegato un parametro di
tipo di media ";conversions=<content-coding>" per svolgere una
funzione equivalente a Content-Encoding. Tuttavia, tale parametro non
fa parte dell'RFC 2045.)
19.4.5 No Content-Transfer-Encoding (Assenza di Content-Transfer-Encoding)
HTTP non utilizza il campo Content-Transfer-Encoding (CTE) dell'RFC 2045. I proxy e i gateway da protocolli conformi a MIME verso HTTP DEVONO rimuovere qualsiasi codifica CTE non identity ("quoted-printable" o "base64") prima di consegnare il messaggio di risposta a un client HTTP.
I proxy e i gateway da HTTP verso protocolli conformi a MIME sono responsabili di garantire che il messaggio sia nel formato corretto e con la codifica corretta per un trasporto sicuro su tale protocollo, dove per "trasporto sicuro" si intende quanto definito dai limiti del protocollo utilizzato. Tale proxy o gateway DOVREBBE etichettare i dati con un Content-Transfer-Encoding appropriato se ciò aumenta la probabilità di un trasporto sicuro sul protocollo di destinazione.
19.4.6 Introduction of Transfer-Encoding (Introduzione di Transfer-Encoding)
HTTP/1.1 introduce il campo di intestazione Transfer-Encoding (sezione 14.41). I proxy/gateway DEVONO rimuovere qualsiasi transfer-coding prima di inoltrare un messaggio tramite un protocollo conforme a MIME.
Una procedura per decodificare il transfer-coding "chunked" (sezione 3.6) può essere rappresentata in pseudocodice come segue:
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
19.4.7 MHTML and Line Length Limitations (MHTML e limitazioni sulla lunghezza delle righe)
Le implementazioni HTTP che condividono codice con implementazioni MHTML [45] devono tenere conto delle limitazioni MIME sulla lunghezza delle righe. Poiché HTTP non presenta tale limitazione, HTTP non manda a capo le righe lunghe. I messaggi MHTML trasportati da HTTP seguono tutte le convenzioni di MHTML, comprese le limitazioni sulla lunghezza delle righe, l'andata a capo, la canonizzazione ecc., poiché HTTP trasporta tutti i corpi dei messaggi come payload (si veda la sezione 3.7.2) e non interpreta né il contenuto né le eventuali righe di intestazione MIME che esso potrebbe contenere.
19.5 Additional Features (Funzionalità aggiuntive)
L'RFC 1945 e l'RFC 2068 documentano elementi di protocollo utilizzati da alcune implementazioni HTTP esistenti, ma non implementati in modo coerente e corretto nella maggior parte delle applicazioni HTTP/1.1. Si raccomanda agli implementatori di conoscere tali funzionalità, ma essi non possono fare affidamento né sulla loro presenza né sulla loro interoperabilità nelle altre applicazioni HTTP/1.1. Alcune di esse descrivono funzionalità sperimentali proposte, altre descrivono funzionalità che l'impiego sperimentale ha rivelato inadeguate e che sono ora trattate nella specifica di base di HTTP/1.1.
Anche numerose altre intestazioni, come Content-Disposition e Title, derivate da SMTP e MIME, sono frequentemente implementate (si veda l'RFC 2076 [37]).
19.5.1 Content-Disposition
Il campo di intestazione di risposta Content-Disposition è stato proposto come mezzo con cui il server di origine può suggerire un nome di file predefinito nel caso in cui l'utente richieda che il contenuto sia salvato in un file. Tale utilizzo deriva dalla definizione di Content-Disposition contenuta nell'RFC 1806 [35].
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
Un esempio è
Content-Disposition: attachment; filename="fname.ext"
L'agente utente ricevente NON DOVREBBE tenere conto di eventuali informazioni di percorso di directory presenti nel parametro filename-parm, che è l'unico parametro attualmente ritenuto applicabile alle implementazioni HTTP. Il nome del file DOVREBBE essere trattato esclusivamente come componente terminale.
Se questa intestazione viene utilizzata in una risposta con content-type application/octet-stream, il suggerimento implicito è che l'agente utente non dovrebbe visualizzare la risposta, bensì aprire direttamente una finestra di dialogo `save response as...'.
Si veda la sezione 15.5 per le questioni di sicurezza relative a Content-Disposition.
19.6 Compatibility with Previous Versions (Compatibilità con le versioni precedenti)
Esula dall'ambito di una specifica di protocollo imporre la conformità con le versioni precedenti. HTTP/1.1 è stato tuttavia progettato deliberatamente in modo da agevolare il supporto delle versioni precedenti. Vale la pena osservare che, al momento della stesura della presente specifica (1996), ci si attendeva che i server HTTP/1.1 commerciali:
- riconoscessero il formato della Request-Line per le richieste
HTTP/0.9, 1.0 e 1.1;
- comprendessero qualsiasi richiesta valida nel formato HTTP/0.9,
1.0 o 1.1;
- rispondessero in modo appropriato con un messaggio della stessa
versione principale utilizzata dal client.
E ci si attendeva che i client HTTP/1.1:
- riconoscessero il formato della Status-Line per le risposte
HTTP/1.0 e 1.1;
- comprendessero qualsiasi risposta valida nel formato HTTP/0.9,
1.0 o 1.1.
Nella maggior parte delle implementazioni di HTTP/1.0, ciascuna connessione viene stabilita dal client prima della richiesta e chiusa dal server dopo l'invio della risposta. Alcune implementazioni realizzano la variante Keep-Alive delle connessioni persistenti descritta nella sezione 19.7.1 dell'RFC 2068 [33].
19.6.1 Changes from HTTP/1.0 (Modifiche rispetto a HTTP/1.0)
Questa sezione riassume le principali differenze tra le versioni HTTP/1.0 e HTTP/1.1.
19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses (Modifiche volte a semplificare i server Web multi-homed e a preservare gli indirizzi IP)
I requisiti secondo cui i client e i server devono supportare l'intestazione di richiesta Host, segnalare un errore qualora l'intestazione di richiesta Host (sezione 14.23) sia assente da una richiesta HTTP/1.1 e accettare URI assoluti (sezione 5.1.2) figurano tra le modifiche più importanti definite dalla presente specifica.
I client HTTP/1.0 più datati presupponevano una relazione biunivoca tra indirizzi IP e server; non esisteva alcun altro meccanismo consolidato per distinguere il server destinatario di una richiesta se non l'indirizzo IP al quale tale richiesta era inviata. Le modifiche sopra delineate consentiranno a Internet, una volta che i client HTTP più datati non saranno più diffusi, di supportare più siti Web da un singolo indirizzo IP, semplificando notevolmente i grandi server Web operativi, per i quali l'assegnazione di numerosi indirizzi IP a un singolo host ha causato seri problemi. Internet potrà inoltre recuperare gli indirizzi IP che erano stati assegnati al solo scopo di consentire l'uso di nomi di dominio dedicati negli URL HTTP di livello radice. Dato il ritmo di crescita del Web e il numero di server già installati, è estremamente importante che tutte le implementazioni di HTTP (compresi gli aggiornamenti delle applicazioni HTTP/1.0 esistenti) implementino correttamente questi requisiti:
- Sia i client sia i server DEVONO supportare l'intestazione di
richiesta Host.
- Un client che invia una richiesta HTTP/1.1 DEVE inviare
un'intestazione Host.
- I server DEVONO segnalare un errore 400 (Bad Request) se una
richiesta HTTP/1.1 non contiene un'intestazione di richiesta
Host.
- I server DEVONO accettare URI assoluti.
19.6.2 Compatibility with HTTP/1.0 Persistent Connections (Compatibilità con le connessioni persistenti HTTP/1.0)
Alcuni client e server potrebbero voler mantenere la compatibilità con alcune implementazioni precedenti delle connessioni persistenti nei client e nei server HTTP/1.0. Le connessioni persistenti in HTTP/1.0 vengono negoziate esplicitamente, in quanto non costituiscono il comportamento predefinito. Le implementazioni sperimentali delle connessioni persistenti in HTTP/1.0 erano difettose, e le nuove funzionalità di HTTP/1.1 sono state progettate per correggere tali problemi. Il problema consisteva nel fatto che alcuni client 1.0 esistenti potevano inviare Keep-Alive a un server proxy che non comprendeva Connection, il quale lo inoltrava erroneamente al successivo server in entrata, che stabiliva quindi la connessione Keep-Alive, provocando il blocco del proxy HTTP/1.0 in attesa della chiusura della risposta. Ne consegue che ai client HTTP/1.0 deve essere impedito di utilizzare Keep-Alive quando comunicano con i proxy.
Tuttavia, poiché la comunicazione con i proxy costituisce l'impiego più importante delle connessioni persistenti, un simile divieto è chiaramente inaccettabile. Occorre pertanto un meccanismo diverso per indicare che si desidera una connessione persistente, il cui utilizzo risulti sicuro anche quando si comunica con un vecchio proxy che ignora Connection. Le connessioni persistenti costituiscono l'impostazione predefinita per i messaggi HTTP/1.1; introduciamo una nuova parola chiave (Connection: close) per dichiarare la non persistenza. Si veda la sezione 14.10.
La forma originaria delle connessioni persistenti in HTTP/1.0 (le intestazioni Connection: Keep-Alive e Keep-Alive) è documentata nell'RFC 2068. [33]
19.6.3 Changes from RFC 2068 (Modifiche rispetto all'RFC 2068)
Questa specifica è stata sottoposta a un attento controllo al fine di correggere l'uso delle parole chiave e di eliminare le ambiguità: l'RFC 2068 presentava numerosi problemi rispetto alle convenzioni stabilite dall'RFC 2119 [34].
È stato chiarito quale codice di errore utilizzare in caso di guasto di un server in entrata (ad esempio un guasto DNS). (Sezione 10.5.5)
CREATE presentava una condizione di competizione che richiedeva l'invio di un Etag al momento della creazione iniziale di una risorsa. (Sezione 10.2.2)
Content-Base è stato rimosso dalla specifica: non era ampiamente implementato e non esiste un modo semplice e sicuro per introdurlo in assenza di un solido meccanismo di estensione. Inoltre, esso viene utilizzato in MHTML [45] in modo simile ma non identico.
Il transfer-coding e la lunghezza dei messaggi interagiscono in un modo che ha reso necessario correggere con precisione i casi in cui viene utilizzata la codifica chunked (al fine di consentire codifiche di trasferimento che potrebbero non essere auto-delimitanti). Era importante definire esattamente il modo in cui vengono calcolate le lunghezze dei messaggi. (Sezioni 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
È stato introdotto un content-coding "identity" per risolvere problemi rilevati nel caching. (Sezione 3.5)
I valori di qualità pari a zero dovrebbero significare "non lo desidero", in modo da consentire ai client di rifiutare una rappresentazione. (Sezione 3.9)
L'uso e l'interpretazione dei numeri di versione HTTP sono stati chiariti dall'RFC 2145. Si richiede ai proxy di aggiornare le richieste alla versione di protocollo più elevata da essi supportata, al fine di affrontare problemi rilevati nelle implementazioni HTTP/1.0. (Sezione 3.1)
È stata introdotta la specificazione tramite carattere jolly dei set di caratteri, per evitare la proliferazione dei nomi dei set di caratteri nelle intestazioni accept. (Sezione 14.2)
Nel modello Cache-Control di HTTP/1.1 era stato trascurato un caso; è stato introdotto s-maxage per aggiungere tale caso mancante. (Sezioni 13.4, 14.8, 14.9, 14.9.3)
La direttiva Cache-Control: max-age non era definita correttamente per le risposte. (Sezione 14.9.3)
Esistono situazioni in cui un server (in particolare un proxy) non conosce la lunghezza completa di una risposta, ma è in grado di soddisfare una richiesta byterange. Occorre pertanto un meccanismo che consenta i byteranges con un content-range che non indichi la lunghezza completa del messaggio. (Sezione 14.16)
Le risposte alle richieste Range risulterebbero estremamente prolisse se tutti i metadati venissero sempre restituiti; consentendo al server di inviare in una risposta 206 soltanto le intestazioni necessarie, questo problema può essere evitato. (Sezioni 10.2.7, 13.5.3 e 14.27)
È stato corretto un problema relativo alle richieste di intervallo non soddisfacibili. Esistono due casi: un problema sintattico e il caso in cui l'intervallo non esiste nel documento. Il codice di stato 416 si è reso necessario per risolvere questa ambiguità, in quanto occorre segnalare un errore per una richiesta di intervallo di byte che si collochi al di fuori del contenuto effettivo del documento. (Sezioni 10.4.17, 14.16)
I requisiti relativi alla trasmissione dei messaggi sono stati riscritti per rendere più difficile agli implementatori commettere errori — poiché le conseguenze di un errore in questo ambito possono avere un impatto significativo su Internet — e per affrontare i seguenti problemi:
1. "HTTP/1.1 or later" è stato modificato in "HTTP/1.1", in
contesti in cui ciò imponeva erroneamente requisiti sul
comportamento delle implementazioni di future versioni di
HTTP/1.x.
2. È stato chiarito che sono gli agenti utente, e non i "client" in
generale, a ritentare le richieste.
3. I requisiti secondo cui i client ignorano le risposte 100
(Continue) inattese e i proxy inoltrano le risposte 100 sono
stati convertiti in un requisito generale relativo alle risposte
1xx.
4. Alcune formulazioni specifiche di TCP sono state corrette, per
chiarire meglio che per HTTP sono possibili anche trasporti
diversi da TCP.
5. Si richiede che un server di origine NON DEBBA attendere il
corpo della richiesta prima di inviare una risposta 100
(Continue) richiesta.
6. Si consente — anziché richiedere — a un server di omettere 100
(Continue) qualora abbia già ricevuto una parte del corpo della
richiesta.
7. Si consente ai server di difendersi da attacchi denial-of-service
e da client difettosi.
Questa modifica aggiunge l'intestazione Expect e il codice di stato 417. Le modifiche ai requisiti di trasmissione dei messaggi si trovano nelle sezioni 8.2, 10.4.18, 8.1.2.2, 13.11 e 14.20.
I proxy dovrebbero poter aggiungere Content-Length ove appropriato. (Sezione 13.5.2)
È stata chiarita la confusione tra le risposte 403 e 404. (Sezioni 10.4.4, 10.4.5 e 10.4.11)
Le avvertenze potevano essere memorizzate nella cache in modo errato o non essere aggiornate correttamente. (Sezioni 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3 e 14.46) Warning doveva inoltre essere un'intestazione generale, poiché PUT e altri metodi possono richiedere avvertenze nelle richieste.
I transfer-coding presentavano problemi rilevanti, in particolare nelle loro interazioni con la codifica chunked. La soluzione consiste nel conferire ai transfer-coding lo stesso status a pieno titolo dei content-coding. Ciò comporta l'aggiunta di un registro IANA per i transfer-coding (distinto da quello dei content coding), di una nuova intestazione (TE) e l'abilitazione di future intestazioni trailer. La codifica di trasferimento rappresenta un notevole vantaggio in termini di prestazioni, sicché valeva la pena correggerla [39]. TE risolve inoltre un altro problema poco evidente di compatibilità con le versioni precedenti, che avrebbe potuto insorgere dall'interazione tra i trailer di autenticazione, la codifica chunked e i client HTTP/1.0. (Sezioni 3.6, 3.6.1 e 14.39)
I metodi PATCH, LINK e UNLINK erano definiti in una versione precedente della presente specifica, ma non erano comunemente implementati. Si veda l'RFC 2068 [33].
I campi di intestazione Alternates, Content-Version, Derived-From, Link, URI, Public e Content-Base erano definiti in una versione precedente della presente specifica, ma non erano comunemente implementati. Si veda l'RFC 2068 [33].
20 Indice (Index)
Si prega di consultare la versione PostScript di questo RFC per l'INDICE.
- Full Copyright Statement (Dichiarazione integrale di copyright)
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.