17. References (Referenzen)
17 Referenzen
Die nachfolgenden Referenzen bewahren die bibliographischen Angaben des ursprünglichen RFC. Um die Genauigkeit der Zitate nicht zu beeinträchtigen, werden Autorennamen, Dokumenttitel, RFC-Nummern, Veröffentlichungsangaben und URLs in ihrer englischen Originalform beibehalten.
[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 Adressen der Autoren (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 Anhänge (Appendices)
19.1 Internet Media Type message/http and application/http (Internet-Medientypen message/http und application/http)
Zusätzlich zur Definition des HTTP/1.1-Protokolls dient dieses Dokument als Spezifikation für die Internet-Medientypen "message/http" und "application/http". Der Typ message/http kann verwendet werden, um eine einzelne HTTP-Anforderungs- oder Antwortnachricht einzuschließen, sofern er die MIME-Beschränkungen für alle "message"-Typen hinsichtlich Zeilenlänge und Kodierung einhält. Der Typ application/http kann verwendet werden, um eine Pipeline aus einer oder mehreren HTTP-Anforderungs- oder Antwortnachrichten (nicht vermischt) einzuschließen. Das Folgende ist bei der IANA [17] zu registrieren.
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 (Internet-Medientyp multipart/byteranges)
Wenn eine HTTP-206-Antwortnachricht (Partial Content) den Inhalt mehrerer Bereiche umfasst (eine Antwort auf eine Anforderung nach mehreren nicht überlappenden Bereichen), werden diese als mehrteiliger Nachrichtenrumpf übertragen. Der hierfür vorgesehene Medientyp wird "multipart/byteranges" genannt.
Der Medientyp multipart/byteranges umfasst zwei oder mehr Teile, von denen jeder eigene Content-Type- und Content-Range-Felder besitzt. Der erforderliche Parameter boundary gibt die Begrenzungszeichenfolge an, die zur Trennung der einzelnen Rumpfteile verwendet wird.
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
Zum Beispiel:
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--
Hinweise:
1) Zusätzliche CRLFs dürfen der ersten Begrenzungszeichenfolge in
der Entität vorausgehen.
2) Obwohl RFC 2046 [40] es erlaubt, die Begrenzungszeichenfolge in
Anführungszeichen zu setzen, behandeln einige bestehende
Implementierungen eine in Anführungszeichen gesetzte
Begrenzungszeichenfolge fehlerhaft.
3) Eine Reihe von Browsern und Servern wurde nach einem frühen
Entwurf der byteranges-Spezifikation programmiert und verwendet
den Medientyp multipart/x-byteranges, der mit der in HTTP/1.1
dokumentierten Version nahezu, aber nicht vollständig kompatibel
ist.
19.3 Tolerant Applications (Tolerante Anwendungen)
Obwohl dieses Dokument die Anforderungen für die Erzeugung von HTTP/1.1-Nachrichten festlegt, werden nicht alle Anwendungen in ihrer Implementierung korrekt sein. Wir empfehlen daher, dass im Betrieb befindliche Anwendungen tolerant gegenüber Abweichungen sind, sofern diese Abweichungen eindeutig interpretiert werden können.
Clients SOLLTEN beim Parsen der Status-Line tolerant sein und Server beim Parsen der Request-Line. Insbesondere SOLLTEN sie eine beliebige Anzahl von SP- oder HT-Zeichen zwischen Feldern akzeptieren, auch wenn nur ein einzelnes SP erforderlich ist.
Das Zeilenendezeichen für Nachrichten-Header-Felder ist die Sequenz CRLF. Wir empfehlen jedoch, dass Anwendungen beim Parsen solcher Header ein einzelnes LF als Zeilenendezeichen erkennen und das vorangehende CR ignorieren.
Der Zeichensatz eines Entitätsrumpfs SOLLTE als der kleinste gemeinsame Nenner der innerhalb dieses Rumpfs verwendeten Zeichencodes gekennzeichnet werden, mit der Ausnahme, dass es vorzuziehen ist, die Entität nicht zu kennzeichnen, statt sie mit den Bezeichnungen US-ASCII oder ISO-8859-1 zu kennzeichnen. Siehe Abschnitte 3.7.1 und 3.4.1.
Zusätzliche Regeln für Anforderungen an das Parsen und Kodieren von Datumsangaben sowie weitere mögliche Probleme bei der Datumskodierung umfassen:
- HTTP/1.1-Clients und -Caches SOLLTEN davon ausgehen, dass ein
RFC-850-Datum, das mehr als 50 Jahre in der Zukunft zu liegen
scheint, tatsächlich in der Vergangenheit liegt (dies hilft bei
der Lösung des „Jahr-2000"-Problems).
- Eine HTTP/1.1-Implementierung DARF ein geparstes Expires-Datum
intern als früher als den korrekten Wert darstellen, sie DARF es
jedoch NICHT intern als später als den korrekten Wert
darstellen.
- Alle ablaufbezogenen Berechnungen MÜSSEN in GMT erfolgen. Die
lokale Zeitzone DARF die Berechnung oder den Vergleich eines
Alters oder Ablaufzeitpunkts NICHT beeinflussen.
- Falls ein HTTP-Header fälschlicherweise einen Datumswert mit
einer anderen Zeitzone als GMT überträgt, MUSS dieser unter
Verwendung der konservativsten möglichen Umrechnung in GMT
umgewandelt werden.
19.4 Differences Between HTTP Entities and RFC 2045 Entities (Unterschiede zwischen HTTP-Entitäten und RFC-2045-Entitäten)
HTTP/1.1 verwendet viele der für Internet-Mail (RFC 822 [9]) und die Multipurpose Internet Mail Extensions (MIME [7]) definierten Konstrukte, um die Übertragung von Entitäten in vielfältigen Darstellungen und mit erweiterbaren Mechanismen zu ermöglichen. RFC 2045 behandelt jedoch E-Mail, und HTTP weist einige Merkmale auf, die sich von den in RFC 2045 beschriebenen unterscheiden. Diese Unterschiede wurden sorgfältig gewählt, um die Leistung über Binärverbindungen zu optimieren, größere Freiheit bei der Verwendung neuer Medientypen zu ermöglichen, Datumsvergleiche zu erleichtern und die Praxis einiger früher HTTP-Server und -Clients anzuerkennen.
Dieser Anhang beschreibt spezifische Bereiche, in denen HTTP von RFC 2045 abweicht. Proxys und Gateways zu strengen MIME-Umgebungen SOLLTEN sich dieser Unterschiede bewusst sein und, wo erforderlich, die entsprechenden Konvertierungen bereitstellen. Proxys und Gateways von MIME-Umgebungen zu HTTP müssen sich dieser Unterschiede ebenfalls bewusst sein, da einige Konvertierungen erforderlich sein können.
19.4.1 MIME-Version
HTTP ist kein MIME-konformes Protokoll. HTTP/1.1-Nachrichten DÜRFEN jedoch ein einzelnes allgemeines Header-Feld MIME-Version enthalten, um anzugeben, welche Version des MIME-Protokolls zur Erstellung der Nachricht verwendet wurde. Die Verwendung des Header-Felds MIME-Version zeigt an, dass die Nachricht vollständig konform zum MIME-Protokoll (wie in RFC 2045[7] definiert) ist. Proxys/Gateways sind dafür verantwortlich, beim Export von HTTP-Nachrichten in strenge MIME-Umgebungen (soweit möglich) die vollständige Konformität sicherzustellen.
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Die MIME-Version "1.0" ist der Standardwert für die Verwendung in HTTP/1.1. Das Parsen und die Semantik von HTTP/1.1-Nachrichten werden jedoch durch dieses Dokument und nicht durch die MIME-Spezifikation definiert.
19.4.2 Conversion to Canonical Form (Umwandlung in die kanonische Form)
RFC 2045 [7] verlangt, dass Internet-Mail-Entitäten vor der Übertragung in die kanonische Form umgewandelt werden, wie in Abschnitt 4 von RFC 2049 [48] beschrieben. Abschnitt 3.7.1 dieses Dokuments beschreibt die zulässigen Formen von Untertypen des Medientyps "text" bei der Übertragung über HTTP. RFC 2046 verlangt, dass Inhalte des Typs "text" Zeilenumbrüche als CRLF darstellen, und untersagt die Verwendung von CR oder LF außerhalb von Zeilenumbruchsequenzen. HTTP erlaubt die Verwendung von CRLF, einem einzelnen CR und einem einzelnen LF zur Kennzeichnung eines Zeilenumbruchs innerhalb von Textinhalten, wenn eine Nachricht über HTTP übertragen wird.
Wo dies möglich ist, SOLLTE ein Proxy oder Gateway von HTTP zu einer strengen MIME-Umgebung alle Zeilenumbrüche innerhalb der in Abschnitt 3.7.1 dieses Dokuments beschriebenen Text-Medientypen in die RFC-2049-Kanonische Form von CRLF umwandeln. Beachten Sie jedoch, dass dies durch das Vorhandensein eines Content-Encoding erschwert werden kann sowie durch den Umstand, dass HTTP die Verwendung einiger Zeichensätze erlaubt, die die Oktette 13 und 10 nicht zur Darstellung von CR und LF verwenden, wie es bei einigen Mehrbyte-Zeichensätzen der Fall ist.
Implementierer sollten beachten, dass die Umwandlung jede auf den Originalinhalt angewandte kryptographische Prüfsumme zerstört, sofern der Originalinhalt nicht bereits in kanonischer Form vorliegt. Daher wird die kanonische Form für alle Inhalte empfohlen, die solche Prüfsummen in HTTP verwenden.
19.4.3 Conversion of Date Formats (Umwandlung von Datumsformaten)
HTTP/1.1 verwendet einen eingeschränkten Satz von Datumsformaten (Abschnitt 3.3.1), um den Vorgang des Datumsvergleichs zu vereinfachen. Proxys und Gateways von anderen Protokollen SOLLTEN sicherstellen, dass jedes in einer Nachricht vorhandene Date-Header-Feld einem der HTTP/1.1-Formate entspricht, und das Datum bei Bedarf umschreiben.
19.4.4 Introduction of Content-Encoding (Einführung von Content-Encoding)
RFC 2045 enthält kein Konzept, das dem Header-Feld Content-Encoding
von HTTP/1.1 entspricht. Da dieses als Modifikator des Medientyps
fungiert, MÜSSEN Proxys und Gateways von HTTP zu MIME-konformen
Protokollen entweder den Wert des Content-Type-Header-Felds ändern
oder den Entitätsrumpf dekodieren, bevor sie die Nachricht
weiterleiten. (Einige experimentelle Anwendungen von Content-Type für
Internet-Mail haben einen Medientyp-Parameter
";conversions=<content-coding>" verwendet, um eine zu
Content-Encoding äquivalente Funktion zu erfüllen. Dieser Parameter
ist jedoch nicht Bestandteil von RFC 2045.)
19.4.5 No Content-Transfer-Encoding (Kein Content-Transfer-Encoding)
HTTP verwendet das Feld Content-Transfer-Encoding (CTE) aus RFC 2045 nicht. Proxys und Gateways von MIME-konformen Protokollen zu HTTP MÜSSEN jede Nicht-identity-CTE-Kodierung ("quoted-printable" oder "base64") entfernen, bevor sie die Antwortnachricht an einen HTTP-Client ausliefern.
Proxys und Gateways von HTTP zu MIME-konformen Protokollen sind dafür verantwortlich sicherzustellen, dass die Nachricht das korrekte Format und die korrekte Kodierung für eine sichere Übertragung über dieses Protokoll aufweist, wobei „sichere Übertragung" durch die Beschränkungen des verwendeten Protokolls definiert wird. Ein solcher Proxy oder Gateway SOLLTE die Daten mit einem geeigneten Content-Transfer-Encoding kennzeichnen, wenn dadurch die Wahrscheinlichkeit einer sicheren Übertragung über das Zielprotokoll erhöht wird.
19.4.6 Introduction of Transfer-Encoding (Einführung von Transfer-Encoding)
HTTP/1.1 führt das Header-Feld Transfer-Encoding ein (Abschnitt 14.41). Proxys/Gateways MÜSSEN jedes Transfer-Coding entfernen, bevor sie eine Nachricht über ein MIME-konformes Protokoll weiterleiten.
Ein Verfahren zum Dekodieren des "chunked" Transfer-Codings (Abschnitt 3.6) kann in Pseudocode wie folgt dargestellt werden:
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 und Beschränkungen der Zeilenlänge)
HTTP-Implementierungen, die Code mit MHTML-Implementierungen [45] gemeinsam nutzen, müssen die MIME-Beschränkungen der Zeilenlänge beachten. Da HTTP diese Beschränkung nicht kennt, führt HTTP keinen Zeilenumbruch bei langen Zeilen durch. Über HTTP transportierte MHTML-Nachrichten folgen sämtlichen Konventionen von MHTML, einschließlich Zeilenlängenbeschränkungen, Zeilenumbruch, Kanonisierung usw., da HTTP alle Nachrichtenrümpfe als Nutzlast transportiert (siehe Abschnitt 3.7.2) und weder den Inhalt noch etwaige darin enthaltene MIME-Header-Zeilen interpretiert.
19.5 Additional Features (Zusätzliche Merkmale)
RFC 1945 und RFC 2068 dokumentieren Protokollelemente, die von einigen bestehenden HTTP-Implementierungen verwendet werden, aber in der Mehrzahl der HTTP/1.1-Anwendungen weder einheitlich noch korrekt implementiert sind. Implementierern wird empfohlen, diese Merkmale zu kennen, sie können sich jedoch weder auf deren Vorhandensein noch auf deren Interoperabilität in anderen HTTP/1.1-Anwendungen verlassen. Einige davon beschreiben vorgeschlagene experimentelle Merkmale, und einige beschreiben Merkmale, die sich beim experimentellen Einsatz als unzureichend erwiesen haben und nun in der HTTP/1.1-Basisspezifikation behandelt werden.
Eine Reihe weiterer Header, wie Content-Disposition und Title, die von SMTP und MIME stammen, werden ebenfalls häufig implementiert (siehe RFC 2076 [37]).
19.5.1 Content-Disposition
Das Antwort-Header-Feld Content-Disposition wurde als Mittel vorgeschlagen, mit dem der Ursprungsserver einen Standarddateinamen vorschlagen kann, falls der Benutzer das Speichern des Inhalts in einer Datei anfordert. Diese Verwendung leitet sich aus der Definition von Content-Disposition in RFC 1806 [35] ab.
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 )
Ein Beispiel ist
Content-Disposition: attachment; filename="fname.ext"
Der empfangende Benutzeragent SOLLTE etwaige im Parameter filename-parm enthaltene Verzeichnispfadinformationen NICHT berücksichtigen; dies ist der einzige Parameter, von dem derzeit angenommen wird, dass er auf HTTP-Implementierungen anwendbar ist. Der Dateiname SOLLTE ausschließlich als abschließende Komponente behandelt werden.
Wird dieser Header in einer Antwort mit dem content-type application/octet-stream verwendet, so besteht die implizite Empfehlung darin, dass der Benutzeragent die Antwort nicht anzeigen, sondern direkt einen Dialog `save response as...' öffnen sollte.
Siehe Abschnitt 15.5 zu Sicherheitsfragen im Zusammenhang mit Content-Disposition.
19.6 Compatibility with Previous Versions (Kompatibilität mit früheren Versionen)
Es geht über den Rahmen einer Protokollspezifikation hinaus, die Konformität mit früheren Versionen vorzuschreiben. HTTP/1.1 wurde jedoch bewusst so entworfen, dass es die Unterstützung früherer Versionen erleichtert. Es sei angemerkt, dass zum Zeitpunkt der Erstellung dieser Spezifikation (1996) von kommerziellen HTTP/1.1-Servern erwartet wurde, dass sie:
- das Format der Request-Line für HTTP/0.9-, 1.0- und
1.1-Anforderungen erkennen;
- jede gültige Anforderung im HTTP/0.9-, 1.0- oder 1.1-Format
verstehen;
- angemessen mit einer Nachricht derselben Hauptversion antworten,
die der Client verwendet hat.
Und von HTTP/1.1-Clients wurde erwartet, dass sie:
- das Format der Status-Line für HTTP/1.0- und
1.1-Antworten erkennen;
- jede gültige Antwort im HTTP/0.9-, 1.0- oder 1.1-Format
verstehen.
Bei den meisten Implementierungen von HTTP/1.0 wird jede Verbindung vor der Anforderung vom Client aufgebaut und nach dem Senden der Antwort vom Server geschlossen. Einige Implementierungen setzen die in Abschnitt 19.7.1 von RFC 2068 [33] beschriebene Keep-Alive-Variante persistenter Verbindungen um.
19.6.1 Changes from HTTP/1.0 (Änderungen gegenüber HTTP/1.0)
Dieser Abschnitt fasst die wesentlichen Unterschiede zwischen den Versionen HTTP/1.0 und HTTP/1.1 zusammen.
19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses (Änderungen zur Vereinfachung von Multi-homed-Webservern und zur Schonung von IP-Adressen)
Die Anforderungen, dass Clients und Server den Host-Anforderungsheader unterstützen, einen Fehler melden, wenn der Host-Anforderungsheader (Abschnitt 14.23) in einer HTTP/1.1-Anforderung fehlt, und absolute URIs akzeptieren (Abschnitt 5.1.2), gehören zu den wichtigsten Änderungen, die durch diese Spezifikation definiert werden.
Ältere HTTP/1.0-Clients gingen von einer Eins-zu-eins-Beziehung zwischen IP-Adressen und Servern aus; es gab keinen anderen etablierten Mechanismus zur Unterscheidung des beabsichtigten Servers einer Anforderung als die IP-Adresse, an die diese Anforderung gerichtet war. Die oben dargelegten Änderungen werden es dem Internet ermöglichen, sobald ältere HTTP-Clients nicht mehr verbreitet sind, mehrere Websites von einer einzigen IP-Adresse aus zu unterstützen, was große betriebliche Webserver erheblich vereinfacht, bei denen die Zuweisung zahlreicher IP-Adressen an einen einzelnen Host schwerwiegende Probleme verursacht hat. Das Internet wird zudem IP-Adressen zurückgewinnen können, die allein zu dem Zweck vergeben wurden, die Verwendung von Sonderdomänennamen in HTTP-URLs der Wurzelebene zu ermöglichen. Angesichts der Wachstumsrate des Web und der Zahl bereits eingesetzter Server ist es äußerst wichtig, dass alle HTTP-Implementierungen (einschließlich Aktualisierungen bestehender HTTP/1.0-Anwendungen) diese Anforderungen korrekt umsetzen:
- Sowohl Clients als auch Server MÜSSEN den
Host-Anforderungsheader unterstützen.
- Ein Client, der eine HTTP/1.1-Anforderung sendet, MUSS einen
Host-Header senden.
- Server MÜSSEN einen Fehler 400 (Bad Request) melden, wenn eine
HTTP/1.1-Anforderung keinen Host-Anforderungsheader enthält.
- Server MÜSSEN absolute URIs akzeptieren.
19.6.2 Compatibility with HTTP/1.0 Persistent Connections (Kompatibilität mit persistenten HTTP/1.0-Verbindungen)
Einige Clients und Server möchten möglicherweise mit einigen früheren Implementierungen persistenter Verbindungen in HTTP/1.0-Clients und -Servern kompatibel bleiben. Persistente Verbindungen in HTTP/1.0 werden explizit ausgehandelt, da sie nicht das Standardverhalten darstellen. Die experimentellen Implementierungen persistenter Verbindungen in HTTP/1.0 waren fehlerhaft, und die neuen Merkmale in HTTP/1.1 wurden entwickelt, um diese Probleme zu beheben. Das Problem bestand darin, dass einige bestehende 1.0-Clients möglicherweise Keep-Alive an einen Proxyserver senden, der Connection nicht versteht, welcher es dann fälschlicherweise an den nächsten eingehenden Server weiterleitet, der daraufhin die Keep-Alive-Verbindung aufbaut und den HTTP/1.0-Proxy in Wartestellung auf das Schließen der Antwort blockiert. Daraus folgt, dass HTTP/1.0-Clients daran gehindert werden müssen, Keep-Alive bei der Kommunikation mit Proxys zu verwenden.
Da jedoch die Kommunikation mit Proxys der wichtigste Anwendungsfall persistenter Verbindungen ist, ist ein solches Verbot eindeutig inakzeptabel. Daher wird ein anderer Mechanismus benötigt, um anzuzeigen, dass eine persistente Verbindung gewünscht wird, und dessen Verwendung selbst bei der Kommunikation mit einem älteren Proxy, der Connection ignoriert, sicher ist. Persistente Verbindungen sind der Standard für HTTP/1.1-Nachrichten; wir führen ein neues Schlüsselwort (Connection: close) ein, um die Nichtpersistenz zu deklarieren. Siehe Abschnitt 14.10.
Die ursprüngliche Form persistenter Verbindungen in HTTP/1.0 (die Header Connection: Keep-Alive und Keep-Alive) ist in RFC 2068 dokumentiert. [33]
19.6.3 Changes from RFC 2068 (Änderungen gegenüber RFC 2068)
Diese Spezifikation wurde sorgfältig geprüft, um die Verwendung von Schlüsselwörtern zu korrigieren und Mehrdeutigkeiten zu beseitigen — RFC 2068 wies zahlreiche Probleme in Bezug auf die durch RFC 2119 [34] festgelegten Konventionen auf.
Klargestellt, welcher Fehlercode bei einem Ausfall eines eingehenden Servers (z. B. einem DNS-Ausfall) zu verwenden ist. (Abschnitt 10.5.5)
CREATE wies eine Wettlaufsituation auf, die erforderte, dass bei der erstmaligen Erstellung einer Ressource ein Etag gesendet wird. (Abschnitt 10.2.2)
Content-Base wurde aus der Spezifikation entfernt: Es war nicht weit verbreitet implementiert, und es gibt keine einfache, sichere Möglichkeit, es ohne einen robusten Erweiterungsmechanismus einzuführen. Zudem wird es in MHTML [45] auf ähnliche, aber nicht identische Weise verwendet.
Transfer-Coding und Nachrichtenlängen wirken auf eine Weise zusammen, die es erforderlich machte, genau zu korrigieren, wann die Chunked-Kodierung verwendet wird (um Transferkodierungen zu ermöglichen, die möglicherweise nicht selbstbegrenzend sind). Es war wichtig, exakt festzulegen, wie Nachrichtenlängen berechnet werden. (Abschnitte 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
Ein Content-Coding "identity" wurde eingeführt, um im Caching entdeckte Probleme zu lösen. (Abschnitt 3.5)
Qualitätswerte von null sollten bedeuten „das möchte ich nicht", damit Clients eine Darstellung ablehnen können. (Abschnitt 3.9)
Die Verwendung und Interpretation von HTTP-Versionsnummern wurde durch RFC 2145 klargestellt. Von Proxys wird verlangt, Anforderungen auf die höchste von ihnen unterstützte Protokollversion hochzustufen, um in HTTP/1.0-Implementierungen entdeckte Probleme zu beheben. (Abschnitt 3.1)
Die Platzhalterangabe für Zeichensätze wurde eingeführt, um eine explosionsartige Zunahme von Zeichensatznamen in Accept-Headern zu vermeiden. (Abschnitt 14.2)
Im Cache-Control-Modell von HTTP/1.1 war ein Fall übersehen worden; s-maxage wurde eingeführt, um diesen fehlenden Fall zu ergänzen. (Abschnitte 13.4, 14.8, 14.9, 14.9.3)
Die Direktive Cache-Control: max-age war für Antworten nicht richtig definiert. (Abschnitt 14.9.3)
Es gibt Situationen, in denen ein Server (insbesondere ein Proxy) die vollständige Länge einer Antwort nicht kennt, aber in der Lage ist, eine Byterange-Anforderung zu bedienen. Wir benötigen daher einen Mechanismus, der Byteranges mit einem Content-Range erlaubt, das nicht die vollständige Nachrichtenlänge angibt. (Abschnitt 14.16)
Antworten auf Range-Anforderungen wären außerordentlich umfangreich, wenn stets alle Metadaten zurückgegeben würden; indem dem Server gestattet wird, in einer 206-Antwort nur die erforderlichen Header zu senden, lässt sich dieses Problem vermeiden. (Abschnitte 10.2.7, 13.5.3 und 14.27)
Ein Problem mit nicht erfüllbaren Range-Anforderungen wurde behoben. Es gibt zwei Fälle: ein syntaktisches Problem und den Fall, dass der Bereich im Dokument nicht existiert. Der Statuscode 416 wurde benötigt, um diese Mehrdeutigkeit aufzulösen, da er erforderlich ist, um einen Fehler bei einer Byte-Range-Anforderung anzuzeigen, die außerhalb des tatsächlichen Dokumentinhalts liegt. (Abschnitte 10.4.17, 14.16)
Die Anforderungen an die Nachrichtenübermittlung wurden neu gefasst, um es Implementierern zu erschweren, Fehler zu machen — da die Folgen von Fehlern in diesem Bereich erhebliche Auswirkungen auf das Internet haben können — und um die folgenden Probleme zu behandeln:
1. „HTTP/1.1 or later" wurde zu „HTTP/1.1" geändert, und zwar in
Kontexten, in denen dies fälschlicherweise Anforderungen an das
Verhalten von Implementierungen zukünftiger Versionen von
HTTP/1.x stellte.
2. Klargestellt, dass Benutzeragenten, nicht „Clients" im
Allgemeinen, Anforderungen wiederholen.
3. Die Anforderungen, dass Clients unerwartete 100-(Continue-)
Antworten ignorieren und dass Proxys 100-Antworten weiterleiten,
wurden in eine allgemeine Anforderung an 1xx-Antworten
umgewandelt.
4. Einige TCP-spezifische Formulierungen wurden korrigiert, um
deutlicher zu machen, dass für HTTP auch Nicht-TCP-Transporte
möglich sind.
5. Es wird verlangt, dass ein Ursprungsserver NICHT auf den
Anforderungsrumpf warten DARF, bevor er eine erforderliche
100-(Continue-)Antwort sendet.
6. Einem Server wird gestattet — statt es zu verlangen —, 100
(Continue) wegzulassen, wenn er bereits einen Teil des
Anforderungsrumpfs empfangen hat.
7. Servern wird ermöglicht, sich gegen Denial-of-Service-Angriffe
und fehlerhafte Clients zu schützen.
Diese Änderung fügt den Expect-Header und den Statuscode 417 hinzu. Die Änderungen der Anforderungen an die Nachrichtenübermittlung finden sich in den Abschnitten 8.2, 10.4.18, 8.1.2.2, 13.11 und 14.20.
Proxys sollten in der Lage sein, Content-Length gegebenenfalls hinzuzufügen. (Abschnitt 13.5.2)
Die Verwechslung zwischen 403- und 404-Antworten wurde bereinigt. (Abschnitte 10.4.4, 10.4.5 und 10.4.11)
Warnungen konnten fälschlicherweise zwischengespeichert oder nicht ordnungsgemäß aktualisiert werden. (Abschnitte 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3 und 14.46) Warning musste außerdem ein allgemeiner Header sein, da PUT und andere Methoden Warnungen in Anforderungen erfordern können.
Transfer-Codings wiesen erhebliche Probleme auf, insbesondere im Zusammenspiel mit der Chunked-Kodierung. Die Lösung besteht darin, Transfer-Codings ebenso vollwertig zu machen wie Content-Codings. Dies umfasst die Aufnahme eines IANA-Registers für Transfer-Codings (getrennt von Content-Codings), eines neuen Headers (TE) sowie die Ermöglichung künftiger Trailer-Header. Transferkodierung stellt einen erheblichen Leistungsgewinn dar, sodass sich die Korrektur lohnte [39]. TE löst zudem ein weiteres, schwer erkennbares Problem der Abwärtskompatibilität, das durch das Zusammenspiel von Authentifizierungs-Trailern, Chunked-Kodierung und HTTP/1.0-Clients hätte auftreten können. (Abschnitte 3.6, 3.6.1 und 14.39)
Die Methoden PATCH, LINK und UNLINK waren in einer früheren Version dieser Spezifikation definiert, wurden jedoch nicht allgemein implementiert. Siehe RFC 2068 [33].
Die Header-Felder Alternates, Content-Version, Derived-From, Link, URI, Public und Content-Base waren in einer früheren Version dieser Spezifikation definiert, wurden jedoch nicht allgemein implementiert. Siehe RFC 2068 [33].
20 Index (Index)
Bitte konsultieren Sie die PostScript-Version dieses RFC für den INDEX.
- Full Copyright Statement (Vollständige Urheberrechtserklärung)
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.