draft-ietf-httpbis-p1-messaging-03.txt   draft-ietf-httpbis-p1-messaging-04.txt 
Network Working Group R. Fielding, Ed. Network Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: December 19, 2008 J. Mogul Expires: March 2, 2009 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
June 17, 2008 August 29, 2008
HTTP/1.1, part 1: URIs, Connections, and Message Parsing HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-ietf-httpbis-p1-messaging-03 draft-ietf-httpbis-p1-messaging-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 19, 2008. This Internet-Draft will expire on March 2, 2009.
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
an overview of HTTP and its associated terminology, defines the an overview of HTTP and its associated terminology, defines the
skipping to change at page 2, line 26 skipping to change at page 2, line 26
frames, and describes general security concerns for implementations. frames, and describes general security concerns for implementations.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://www.tools.ietf.org/wg/httpbis/>. <http://www.tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.4. The changes in this draft are summarized in Appendix D.4.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9
2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. ABNF Rules defined in other Parts of the Specification . . 16 2.3. ABNF Rules defined in other Parts of the Specification . . 16
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 19
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 20 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 21
3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 21 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 22
3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 23 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 24
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 24 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 25
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 26 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 27
4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 29 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 30
5.2. The Resource Identified by a Request . . . . . . . . . . . 30 5.2. The Resource Identified by a Request . . . . . . . . . . . 31
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 32
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 32
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 33
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 33 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 34
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 35
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35
7.2. Message Transmission Requirements . . . . . . . . . . . . 36 7.2. Message Transmission Requirements . . . . . . . . . . . . 36
7.2.1. Persistent Connections and Flow Control . . . . . . . 36 7.2.1. Persistent Connections and Flow Control . . . . . . . 37
7.2.2. Monitoring Connections for Error Status Messages . . . 36 7.2.2. Monitoring Connections for Error Status Messages . . . 37
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 37
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 38 Connection . . . . . . . . . . . . . . . . . . . . . . 39
8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 39 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 40
8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 43
8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 45
8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
9.1. Message Header Registration . . . . . . . . . . . . . . . 47 9.1. Message Header Registration . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 49
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48 9.3. Internet Media Type Registrations . . . . . . . . . . . . 49
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48 9.3.1. Internet Media Type message/http . . . . . . . . . . . 49
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 49 9.3.2. Internet Media Type application/http . . . . . . . . . 50
10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 50 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 52
10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 52
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 52
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . . 52 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 53
12.2. Informative References . . . . . . . . . . . . . . . . . . 53 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 54
Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 55 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
A.1. Internet Media Type message/http . . . . . . . . . . . . . 55 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2. Internet Media Type application/http . . . . . . . . . . . 56 12.1. Normative References . . . . . . . . . . . . . . . . . . . 55
Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57 12.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 59
Appendix D. Compatibility with Previous Versions . . . . . . . . 58 Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 59
D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59 Appendix C. Compatibility with Previous Versions . . . . . . . . 60
D.1.1. Changes to Simplify Multi-homed Web Servers and C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 60
Conserve IP Addresses . . . . . . . . . . . . . . . . 59 C.1.1. Changes to Simplify Multi-homed Web Servers and
D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 60 Conserve IP Addresses . . . . . . . . . . . . . . . . 60
D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 61
D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61 C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 62
Appendix E. Change Log (to be removed by RFC Editor before C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 62
publication) . . . . . . . . . . . . . . . . . . . . 61 Appendix D. Change Log (to be removed by RFC Editor before
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 publication) . . . . . . . . . . . . . . . . . . . . 63
E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 63
E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 63 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 63
E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 64 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 64
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 66
Intellectual Property and Copyright Statements . . . . . . . . . . 71 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . . . . 73
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World-Wide Web global systems. HTTP has been in use by the World-Wide Web global
information initiative since 1990. The first version of HTTP, information initiative since 1990. The first version of HTTP,
commonly referred to as HTTP/0.9, was a simple protocol for raw data commonly referred to as HTTP/0.9, was a simple protocol for raw data
transfer across the Internet with only a single method and no transfer across the Internet with only a single method and no
metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol
skipping to change at page 14, line 27 skipping to change at page 14, line 27
LF = %x0A LF = %x0A
; US-ASCII LF, linefeed (10) ; US-ASCII LF, linefeed (10)
SP = %x20 SP = %x20
; US-ASCII SP, space (32) ; US-ASCII SP, space (32)
HTAB = %x09 HTAB = %x09
; US-ASCII HT, horizontal-tab (9) ; US-ASCII HT, horizontal-tab (9)
DQUOTE = %x22 DQUOTE = %x22
; US-ASCII double-quote mark (34) ; US-ASCII double-quote mark (34)
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see Appendix B for tolerant protocol elements except the entity-body (see Appendix A for tolerant
applications). The end-of-line marker within an entity-body is applications). The end-of-line marker within an entity-body is
defined by its associated media type, as described in Section 3.3 of defined by its associated media type, as described in Section 3.3 of
[Part3]. [Part3].
CRLF = CR LF CRLF = CR LF
HTTP/1.1 header field values can be folded onto multiple lines if the HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before recipient MAY replace any linear white space with a single SP before
skipping to change at page 15, line 8 skipping to change at page 15, line 8
TEXT = %x20-7E | %x80-FF | LWS TEXT = %x20-7E | %x80-FF | LWS
; any OCTET except CTLs, but including LWS ; any OCTET except CTLs, but including LWS
A CRLF is allowed in the definition of TEXT only as part of a header A CRLF is allowed in the definition of TEXT only as part of a header
field continuation. It is expected that the folding LWS will be field continuation. It is expected that the folding LWS will be
replaced with a single SP before interpretation of the TEXT value. replaced with a single SP before interpretation of the TEXT value.
Hexadecimal numeric characters are used in several protocol elements. Hexadecimal numeric characters are used in several protocol elements.
HEX = "A" | "B" | "C" | "D" | "E" | "F" HEXDIG = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Many HTTP/1.1 header field values consist of words separated by LWS Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted or special characters. These special characters MUST be in a quoted
string to be used within a parameter value (as defined in string to be used within a parameter value (as defined in
Section 3.4). Section 3.4).
separators = "(" | ")" | "<" | ">" | "@" separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | DQUOTE | "," | ";" | ":" | "\" | DQUOTE
| "/" | "[" | "]" | "?" | "=" | "/" | "[" | "]" | "?" | "="
skipping to change at page 18, line 48 skipping to change at page 18, line 48
for TCP connections on that port of that host, and the Request-URI for TCP connections on that port of that host, and the Request-URI
for the resource is path-absolute (Section 5.1.2). The use of IP for the resource is path-absolute (Section 5.1.2). The use of IP
addresses in URLs SHOULD be avoided whenever possible (see addresses in URLs SHOULD be avoided whenever possible (see
[RFC1900]). If the path-absolute is not present in the URL, it MUST [RFC1900]). If the path-absolute is not present in the URL, it MUST
be given as "/" when used as a Request-URI for a resource be given as "/" when used as a Request-URI for a resource
(Section 5.1.2). If a proxy receives a host name which is not a (Section 5.1.2). If a proxy receives a host name which is not a
fully qualified domain name, it MAY add its domain to the host name fully qualified domain name, it MAY add its domain to the host name
it received. If a proxy receives a fully qualified domain name, the it received. If a proxy receives a fully qualified domain name, the
proxy MUST NOT change the host name. proxy MUST NOT change the host name.
Note: the "https" scheme is defined in [RFC2818].
3.2.3. URI Comparison 3.2.3. URI Comparison
When comparing two URIs to decide if they match or not, a client When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions: URIs, with these exceptions:
o A port that is empty or not given is equivalent to the default o A port that is empty or not given is equivalent to the default
port for that URI-reference; port for that URI-reference;
o Comparisons of host names MUST be case-insensitive; o Comparisons of host names MUST be case-insensitive;
o Comparisons of scheme names MUST be case-insensitive; o Comparisons of scheme names MUST be case-insensitive;
o An empty path-absolute is equivalent to an path-absolute of "/". o An empty path-absolute is equivalent to an path-absolute of "/".
Characters other than those in the "reserved" set (see [RFC2396]) are Characters other than those in the "reserved" set (see [RFC2396],
equivalent to their ""%" HEX HEX" encoding. Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding.
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
3.3. Date/Time Formats 3.3. Date/Time Formats
3.3.1. Full Date 3.3.1. Full Date
skipping to change at page 19, line 42 skipping to change at page 19, line 47
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The first format is preferred as an Internet standard and represents The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by [RFC1123] (an update to a fixed-length subset of that defined by [RFC1123] (an update to
[RFC822]). The other formats are described here only for [RFC822]). The other formats are described here only for
compatibility with obsolete implementations. HTTP/1.1 clients and compatibility with obsolete implementations. HTTP/1.1 clients and
servers that parse the date value MUST accept all three formats (for servers that parse the date value MUST accept all three formats (for
compatibility with HTTP/1.0), though they MUST only generate the RFC compatibility with HTTP/1.0), though they MUST only generate the RFC
1123 format for representing HTTP-date values in header fields. See 1123 format for representing HTTP-date values in header fields. See
Appendix B for further information. Appendix A for further information.
Note: Recipients of date values are encouraged to be robust in Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP accepting date values that may have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP. messages via proxies/gateways to SMTP or NNTP.
All HTTP date/time stamps MUST be represented in Greenwich Mean Time All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly (GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time). This is indicated in the equal to UTC (Coordinated Universal Time). This is indicated in the
first two formats by the inclusion of "GMT" as the three-letter first two formats by the inclusion of "GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include asctime format. HTTP-date is case sensitive and MUST NOT include
additional LWS beyond that specifically included as SP in the additional LWS beyond that specifically included as SP in the
grammar. grammar.
HTTP-date = rfc1123-date | obsolete-date HTTP-date = rfc1123-date | obsolete-date
obsolete-date = rfc850-date | asctime-date obsolete-date = rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc1123-date = wkday "," SP date1 SP time SP GMT
rfc850-date = weekday "," SP date2 SP time SP "GMT" rfc850-date = weekday "," SP date2 SP time SP GMT
asctime-date = wkday SP date3 SP time SP 4DIGIT asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982) ; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82) ; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2) ; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59 ; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed" wkday = s-Mon | s-Tue | s-Wed
| "Thu" | "Fri" | "Sat" | "Sun" | s-Thu | s-Fri | s-Sat | s-Sun
weekday = "Monday" | "Tuesday" | "Wednesday" weekday = l-Mon | l-Tue | l-Wed
| "Thursday" | "Friday" | "Saturday" | "Sunday" | l-Thu | l-Fri | l-Sat | l-Sun
month = "Jan" | "Feb" | "Mar" | "Apr" month = s-Jan | s-Feb | s-Mar | s-Apr
| "May" | "Jun" | "Jul" | "Aug" | s-May | s-Jun | s-Jul | s-Aug
| "Sep" | "Oct" | "Nov" | "Dec" | s-Sep | s-Oct | s-Nov | s-Dec
GMT = %x47.4D.54 ; "GMT", case-sensitive
s-Mon = %x4D.6F.6E ; "Mon", case-sensitive
s-Tue = %x54.75.65 ; "Tue", case-sensitive
s-Wed = %x57.65.64 ; "Wed", case-sensitive
s-Thu = %x54.68.75 ; "Thu", case-sensitive
s-Fri = %x46.72.69 ; "Fri", case-sensitive
s-Sat = %x53.61.74 ; "Sat", case-sensitive
s-Sun = %x53.75.6E ; "Sun", case-sensitive
l-Mon = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
l-Thu = %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
l-Fri = %x46.72.69.64.61.79 ; "Friday", case-sensitive
l-Sat = %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
l-Sun = %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
s-Jan = %x4A.61.6E ; "Jan", case-sensitive
s-Feb = %x46.65.62 ; "Feb", case-sensitive
s-Mar = %x4D.61.72 ; "Mar", case-sensitive
s-Apr = %x41.70.72 ; "Apr", case-sensitive
s-May = %x4D.61.79 ; "May", case-sensitive
s-Jun = %x4A.75.6E ; "Jun", case-sensitive
s-Jul = %x4A.75.6C ; "Jul", case-sensitive
s-Aug = %x41.75.67 ; "Aug", case-sensitive
s-Sep = %x53.65.70 ; "Sep", case-sensitive
s-Oct = %x4F.63.74 ; "Oct", case-sensitive
s-Nov = %x4E.6F.76 ; "Nov", case-sensitive
s-Dec = %x44.65.63 ; "Dec", case-sensitive
Note: HTTP requirements for the date/time stamp format apply only to Note: HTTP requirements for the date/time stamp format apply only to
their usage within the protocol stream. Clients and servers are not their usage within the protocol stream. Clients and servers are not
required to use these formats for user presentation, request logging, required to use these formats for user presentation, request logging,
etc. etc.
3.4. Transfer Codings 3.4. Transfer Codings
Transfer-coding values are used to indicate an encoding Transfer-coding values are used to indicate an encoding
transformation that has been, can be, or may need to be applied to an transformation that has been, can be, or may need to be applied to an
skipping to change at page 21, line 4 skipping to change at page 21, line 38
property of the message, not of the original entity. property of the message, not of the original entity.
transfer-coding = "chunked" | transfer-extension transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter ) transfer-extension = token *( ";" parameter )
Parameters are in the form of attribute/value pairs. Parameters are in the form of attribute/value pairs.
parameter = attribute "=" value parameter = attribute "=" value
attribute = token attribute = token
value = token | quoted-string value = token | quoted-string
All transfer-coding values are case-insensitive. HTTP/1.1 uses All transfer-coding values are case-insensitive. HTTP/1.1 uses
transfer-coding values in the TE header field (Section 8.5) and in transfer-coding values in the TE header field (Section 8.5) and in
the Transfer-Encoding header field (Section 8.7). the Transfer-Encoding header field (Section 8.7).
Whenever a transfer-coding is applied to a message-body, the set of Whenever a transfer-coding is applied to a message-body, the set of
transfer-codings MUST include "chunked", unless the message is transfer-codings MUST include "chunked", unless the message indicates
terminated by closing the connection. When the "chunked" transfer- it is terminated by closing the connection. When the "chunked"
coding is used, it MUST be the last transfer-coding applied to the transfer-coding is used, it MUST be the last transfer-coding applied
message-body. The "chunked" transfer-coding MUST NOT be applied more to the message-body. The "chunked" transfer-coding MUST NOT be
than once to a message-body. These rules allow the recipient to applied more than once to a message-body. These rules allow the
determine the transfer-length of the message (Section 4.4). recipient to determine the transfer-length of the message
(Section 4.4).
Transfer-codings are analogous to the Content-Transfer-Encoding Transfer-codings are analogous to the Content-Transfer-Encoding
values of MIME [RFC2045], which were designed to enable safe values of MIME [RFC2045], which were designed to enable safe
transport of binary data over a 7-bit transport service. However, transport of binary data over a 7-bit transport service. However,
safe transport has a different focus for an 8bit-clean transfer safe transport has a different focus for an 8bit-clean transfer
protocol. In HTTP, the only unsafe characteristic of message-bodies protocol. In HTTP, the only unsafe characteristic of message-bodies
is the difficulty in determining the exact body length (Section 4.4), is the difficulty in determining the exact body length (Section 4.4),
or the desire to encrypt data over a shared transport. or the desire to encrypt data over a shared transport.
The Internet Assigned Numbers Authority (IANA) acts as a registry for The Internet Assigned Numbers Authority (IANA) acts as a registry for
skipping to change at page 22, line 12 skipping to change at page 22, line 42
the information necessary for the recipient to verify that it has the information necessary for the recipient to verify that it has
received the full message. received the full message.
Chunked-Body = *chunk Chunked-Body = *chunk
last-chunk last-chunk
trailer-part trailer-part
CRLF CRLF
chunk = chunk-size [ chunk-extension ] CRLF chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF chunk-data CRLF
chunk-size = 1*HEX chunk-size = 1*HEXDIG
last-chunk = 1*("0") [ chunk-extension ] CRLF last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token | quoted-string chunk-ext-val = token | quoted-string
chunk-data = 1*OCTET ; a sequence of chunk-size octets chunk-data = 1*OCTET ; a sequence of chunk-size octets
trailer-part = *(entity-header CRLF) trailer-part = *(entity-header CRLF)
The chunk-size field is a string of hex digits indicating the size of The chunk-size field is a string of hex digits indicating the size of
the chunk-data in octets. The chunked encoding is ended by any chunk the chunk-data in octets. The chunked encoding is ended by any chunk
skipping to change at page 25, line 38 skipping to change at page 26, line 21
present in a message if and only if the entire field-value for that present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)]. header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the "field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded. change the order of these field values when a message is forwarded.
Note: the "Set-Cookie" header as implemented in practice (as
opposed to how it is specified in [RFC2109]) can occur multiple
times, but does not use the list syntax, and thus cannot be
combined into a single line. (See Appendix A.2.3 of [Kri2001] for
details.) Also note that the Set-Cookie2 header specified in
[RFC2965] does not share this problem.
4.3. Message Body 4.3. Message Body
The message-body (if any) of an HTTP message is used to carry the The message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message- entity-body associated with the request or response. The message-
body differs from the entity-body only when a transfer-coding has body differs from the entity-body only when a transfer-coding has
been applied, as indicated by the Transfer-Encoding header field been applied, as indicated by the Transfer-Encoding header field
(Section 8.7). (Section 8.7).
message-body = entity-body message-body = entity-body
| <entity-body encoded as per Transfer-Encoding> | <entity-body encoded as per Transfer-Encoding>
skipping to change at page 26, line 46 skipping to change at page 27, line 36
been applied. When a message-body is included with a message, the been applied. When a message-body is included with a message, the
transfer-length of that body is determined by one of the following transfer-length of that body is determined by one of the following
(in order of precedence): (in order of precedence):
1. Any response message which "MUST NOT" include a message-body 1. Any response message which "MUST NOT" include a message-body
(such as the 1xx, 204, and 304 responses and any response to a (such as the 1xx, 204, and 304 responses and any response to a
HEAD request) is always terminated by the first empty line after HEAD request) is always terminated by the first empty line after
the header fields, regardless of the entity-header fields present the header fields, regardless of the entity-header fields present
in the message. in the message.
2. If a Transfer-Encoding header field (Section 8.7) is present, 2. If a Transfer-Encoding header field (Section 8.7) is present and
then the transfer-length is defined by use of the "chunked" the "chunked" transfer-coding (Section 3.4) is used, the
transfer-coding (Section 3.4), unless the message is terminated transfer-length is defined by the use of this transfer-coding.
by closing the connection. If a Transfer-Encoding header field is present and the "chunked"
transfer-coding is not present, the transfer-length is defined by
the sender closing the connection.
3. If a Content-Length header field (Section 8.2) is present, its 3. If a Content-Length header field (Section 8.2) is present, its
decimal value in OCTETs represents both the entity-length and the decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be transfer-length. The Content-Length header field MUST NOT be
sent if these two lengths are different (i.e., if a Transfer- sent if these two lengths are different (i.e., if a Transfer-
Encoding header field is present). If a message is received with Encoding header field is present). If a message is received with
both a Transfer-Encoding header field and a Content-Length header both a Transfer-Encoding header field and a Content-Length header
field, the latter MUST be ignored. field, the latter MUST be ignored.
4. If the message uses the media type "multipart/byteranges", and 4. If the message uses the media type "multipart/byteranges", and
skipping to change at page 30, line 11 skipping to change at page 31, line 4
resource on an origin server or gateway. In this case the absolute resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see Section 3.2.1, path- path of the URI MUST be transmitted (see Section 3.2.1, path-
absolute) as the Request-URI, and the network location of the URI absolute) as the Request-URI, and the network location of the URI
(authority) MUST be transmitted in a Host header field. For example, (authority) MUST be transmitted in a Host header field. For example,
a client wishing to retrieve the resource above directly from the a client wishing to retrieve the resource above directly from the
origin server would create a TCP connection to port 80 of the host origin server would create a TCP connection to port 80 of the host
"www.example.org" and send the lines: "www.example.org" and send the lines:
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org Host: www.example.org
followed by the remainder of the Request. Note that the absolute followed by the remainder of the Request. Note that the absolute
path cannot be empty; if none is present in the original URI, it MUST path cannot be empty; if none is present in the original URI, it MUST
be given as "/" (the server root). be given as "/" (the server root).
The Request-URI is transmitted in the format specified in The Request-URI is transmitted in the format specified in
Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG
encoding [RFC2396], the origin server MUST decode the Request-URI in HEXDIG" encoding ([RFC2396], Section 2.4.1), the origin server MUST
order to properly interpret the request. Servers SHOULD respond to decode the Request-URI in order to properly interpret the request.
invalid Request-URIs with an appropriate status code. Servers SHOULD respond to invalid Request-URIs with an appropriate
status code.
A transparent proxy MUST NOT rewrite the "path-absolute" part of the A transparent proxy MUST NOT rewrite the "path-absolute" part of the
received Request-URI when forwarding it to the next inbound server, received Request-URI when forwarding it to the next inbound server,
except as noted above to replace a null path-absolute with "/". except as noted above to replace a null path-absolute with "/".
Note: The "no rewrite" rule prevents the proxy from changing the Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using meaning of the request when the origin server is improperly using
a non-reserved URI character for a reserved purpose. Implementors a non-reserved URI character for a reserved purpose. Implementors
should be aware that some pre-HTTP/1.1 proxies have been known to should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI. rewrite the Request-URI.
5.2. The Resource Identified by a Request 5.2. The Resource Identified by a Request
The exact resource identified by an Internet request is determined by The exact resource identified by an Internet request is determined by
examining both the Request-URI and the Host header field. examining both the Request-URI and the Host header field.
An origin server that does not allow resources to differ by the An origin server that does not allow resources to differ by the
requested host MAY ignore the Host header field value when requested host MAY ignore the Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see determining the resource identified by an HTTP/1.1 request. (But see
Appendix D.1.1 for other requirements on Host support in HTTP/1.1.) Appendix C.1.1 for other requirements on Host support in HTTP/1.1.)
An origin server that does differentiate resources based on the host An origin server that does differentiate resources based on the host
requested (sometimes referred to as virtual hosts or vanity host requested (sometimes referred to as virtual hosts or vanity host
names) MUST use the following rules for determining the requested names) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request: resource on an HTTP/1.1 request:
1. If Request-URI is an absoluteURI, the host is part of the 1. If Request-URI is an absoluteURI, the host is part of the
Request-URI. Any Host header field value in the request MUST be Request-URI. Any Host header field value in the request MUST be
ignored. ignored.
skipping to change at page 34, line 9 skipping to change at page 34, line 52
case the client does not want to maintain a connection for more than case the client does not want to maintain a connection for more than
that request, it SHOULD send a Connection header including the that request, it SHOULD send a Connection header including the
connection-token close. connection-token close.
If either the client or the server sends the close token in the If either the client or the server sends the close token in the
Connection header, that request becomes the last one for the Connection header, that request becomes the last one for the
connection. connection.
Clients and servers SHOULD NOT assume that a persistent connection is Clients and servers SHOULD NOT assume that a persistent connection is
maintained for HTTP versions less than 1.1 unless it is explicitly maintained for HTTP versions less than 1.1 unless it is explicitly
signaled. See Appendix D.2 for more information on backward signaled. See Appendix C.2 for more information on backward
compatibility with HTTP/1.0 clients. compatibility with HTTP/1.0 clients.
In order to remain persistent, all messages on the connection MUST In order to remain persistent, all messages on the connection MUST
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 4.4. of the connection), as described in Section 4.4.
7.1.2.2. Pipelining 7.1.2.2. Pipelining
A client that supports persistent connections MAY "pipeline" its A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each requests (i.e., send multiple requests without waiting for each
skipping to change at page 40, line 27 skipping to change at page 41, line 20
An HTTP/1.1 server that does not support persistent connections MUST An HTTP/1.1 server that does not support persistent connections MUST
include the "close" connection option in every response message that include the "close" connection option in every response message that
does not have a 1xx (informational) status code. does not have a 1xx (informational) status code.
A system receiving an HTTP/1.0 (or lower-version) message that A system receiving an HTTP/1.0 (or lower-version) message that
includes a Connection header MUST, for each connection-token in this includes a Connection header MUST, for each connection-token in this
field, remove and ignore any header field(s) from the message with field, remove and ignore any header field(s) from the message with
the same name as the connection-token. This protects against the same name as the connection-token. This protects against
mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
See Appendix D.2. See Appendix C.2.
8.2. Content-Length 8.2. Content-Length
The Content-Length entity-header field indicates the size of the The Content-Length entity-header field indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient or, entity-body, in decimal number of OCTETs, sent to the recipient or,
in the case of the HEAD method, the size of the entity-body that in the case of the HEAD method, the size of the entity-body that
would have been sent had the request been a GET. would have been sent had the request been a GET.
Content-Length = "Content-Length" ":" 1*DIGIT Content-Length = "Content-Length" ":" 1*DIGIT
skipping to change at page 43, line 5 skipping to change at page 43, line 50
A client MUST include a Host header field in all HTTP/1.1 request A client MUST include a Host header field in all HTTP/1.1 request
messages. If the requested URI does not include an Internet host messages. If the requested URI does not include an Internet host
name for the service being requested, then the Host header field MUST name for the service being requested, then the Host header field MUST
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
request message it forwards does contain an appropriate Host header request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy. All field that identifies the service being requested by the proxy. All
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
status code to any HTTP/1.1 request message which lacks a Host header status code to any HTTP/1.1 request message which lacks a Host header
field. field.
See Sections 5.2 and D.1.1 for other requirements relating to Host. See Sections 5.2 and C.1.1 for other requirements relating to Host.
8.5. TE 8.5. TE
The TE request-header field indicates what extension transfer-codings The TE request-header field indicates what extension transfer-codings
it is willing to accept in the response and whether or not it is it is willing to accept in the response and whether or not it is
willing to accept trailer fields in a chunked transfer-coding. Its willing to accept trailer fields in a chunked transfer-coding. Its
value may consist of the keyword "trailers" and/or a comma-separated value may consist of the keyword "trailers" and/or a comma-separated
list of extension transfer-coding names with optional accept list of extension transfer-coding names with optional accept
parameters (as described in Section 3.4). parameters (as described in Section 3.4).
skipping to change at page 48, line 22 skipping to change at page 49, line 22
| TE | http | standard | Section 8.5 | | TE | http | standard | Section 8.5 |
| Trailer | http | standard | Section 8.6 | | Trailer | http | standard | Section 8.6 |
| Transfer-Encoding | http | standard | Section 8.7 | | Transfer-Encoding | http | standard | Section 8.7 |
| Upgrade | http | standard | Section 8.8 | | Upgrade | http | standard | Section 8.8 |
| Via | http | standard | Section 8.9 | | Via | http | standard | Section 8.9 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
9.2. URI Scheme Registration
The entry for the "http" URI Scheme in the registry located at
<http://www.iana.org/assignments/uri-schemes.html> should be updated
to point to Section 3.2.2 of this document (see [RFC4395]).
9.3. Internet Media Type Registrations
This document serves as the specification for the Internet media
types "message/http" and "application/http". The following is to be
registered with IANA (see [RFC4288]).
9.3.1. Internet Media Type message/http
The message/http type can be used to enclose a single HTTP request or
response message, provided that it obeys the MIME restrictions for
all "message" types regarding line length and encodings.
Type name: message
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
Interoperability considerations: none
Published specification: This specification (see Section 9.3.1).
Applications that use this media type:
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IESG
9.3.2. Internet Media Type application/http
The application/http type can be used to enclose a pipeline of one or
more HTTP request or response messages (not intermixed).
Type name: application
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
Interoperability considerations: none
Published specification: This specification (see Section 9.3.2).
Applications that use this media type:
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IESG
10. Security Considerations 10. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
10.1. Personal Information 10.1. Personal Information
skipping to change at page 52, line 16 skipping to change at page 55, line 37
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-03 (work in Semantics", draft-ietf-httpbis-p2-semantics-04 (work in
progress), June 2008. progress), August 2008.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-03 and Content Negotiation", draft-ietf-httpbis-p3-payload-04
(work in progress), June 2008. (work in progress), August 2008.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-03 (work Partial Responses", draft-ietf-httpbis-p5-range-04 (work
in progress), June 2008. in progress), August 2008.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-03 (work in progress), draft-ietf-httpbis-p6-cache-04 (work in progress),
June 2008. August 2008.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 53, line 13 skipping to change at page 56, line 36
[RFC822ABNF] [RFC822ABNF]
Crocker, D., "Standard for the format of ARPA Internet Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
12.2. Informative References 12.2. Informative References
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. 1,
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and
C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1,
and PNG", ACM Proceedings of the ACM SIGCOMM '97 and PNG", ACM Proceedings of the ACM SIGCOMM '97
conference on Applications, technologies, architectures, conference on Applications, technologies, architectures,
and protocols for computer communication SIGCOMM '97, and protocols for computer communication SIGCOMM '97,
September 1997, September 1997,
<http://doi.acm.org/10.1145/263105.263157>. <http://doi.acm.org/10.1145/263105.263157>.
[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
Computer Networks and ISDN Systems v. 28, pp. 25-35, Computer Networks and ISDN Systems v. 28, pp. 25-35,
December 1995. December 1995,
<http://portal.acm.org/citation.cfm?id=219094>.
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/HTTPLatency.html>.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Alberti, "The Internet Gopher Protocol Torrey, D., and B. Alberti, "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)", (a distributed document search and retrieval protocol)",
skipping to change at page 54, line 18 skipping to change at page 57, line 40
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
RFC 1900, February 1996. RFC 1900, February 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
and Interpretation of HTTP Version Numbers", RFC 2145, and Interpretation of HTTP Version Numbers", RFC 2145,
May 1997. May 1997.
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, April 1998. (HTCPCP/1.0)", RFC 2324, April 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006. RFC 3977, October 2006.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet [RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985. STD 9, RFC 959, October 1985.
[Spe] Spero, S., "Analysis of HTTP Performance Problems", [Spe] Spero, S., "Analysis of HTTP Performance Problems",
<http://sunsite.unc.edu/mdma-release/http-prob.html>. <http://sunsite.unc.edu/mdma-release/http-prob.html>.
[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
HTTP Performance", ISI Research Report ISI/RR-98-463, HTTP Performance", ISI Research Report ISI/RR-98-463,
Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
(original report dated Aug. 1996) (original report dated Aug. 1996)
[WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T.,
Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface
Protocol Prototype Functional Specification (v1.5)", Protocol Prototype Functional Specification (v1.5)",
Thinking Machines Corporation , April 1990. Thinking Machines Corporation , April 1990.
Appendix A. Internet Media Types Appendix A. Tolerant Applications
In addition to defining HTTP/1.1, this document serves as the
specification for the Internet media type "message/http" and
"application/http". The following is to be registered with IANA
[RFC4288].
A.1. Internet Media Type message/http
The message/http type can be used to enclose a single HTTP request or
response message, provided that it obeys the MIME restrictions for
all "message" types regarding line length and encodings.
Type name: message
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
Interoperability considerations: none
Published specification: This specification (see Appendix A.1).
Applications that use this media type:
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IESG
A.2. Internet Media Type application/http
The application/http type can be used to enclose a pipeline of one or
more HTTP request or response messages (not intermixed).
Type name: application
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
Interoperability considerations: none
Published specification: This specification (see Appendix A.2).
Applications that use this media type:
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IESG
Appendix B. Tolerant Applications
Although this document specifies the requirements for the generation Although this document specifies the requirements for the generation
of HTTP/1.1 messages, not all applications will be correct in their of HTTP/1.1 messages, not all applications will be correct in their
implementation. We therefore recommend that operational applications implementation. We therefore recommend that operational applications
be tolerant of deviations whenever those deviations can be be tolerant of deviations whenever those deviations can be
interpreted unambiguously. interpreted unambiguously.
Clients SHOULD be tolerant in parsing the Status-Line and servers Clients SHOULD be tolerant in parsing the Status-Line and servers
tolerant when parsing the Request-Line. In particular, they SHOULD tolerant when parsing the Request-Line. In particular, they SHOULD
accept any amount of SP or HTAB characters between fields, even accept any amount of SP or HTAB characters between fields, even
skipping to change at page 58, line 28 skipping to change at page 59, line 47
proper value. proper value.
o All expiration-related calculations MUST be done in GMT. The o All expiration-related calculations MUST be done in GMT. The
local time zone MUST NOT influence the calculation or comparison local time zone MUST NOT influence the calculation or comparison
of an age or expiration time. of an age or expiration time.
o If an HTTP header incorrectly carries a date value with a time o If an HTTP header incorrectly carries a date value with a time
zone other than GMT, it MUST be converted into GMT using the most zone other than GMT, it MUST be converted into GMT using the most
conservative possible conversion. conservative possible conversion.
Appendix C. Conversion of Date Formats Appendix B. Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to
simplify the process of date comparison. Proxies and gateways from simplify the process of date comparison. Proxies and gateways from
other protocols SHOULD ensure that any Date header field present in a other protocols SHOULD ensure that any Date header field present in a
message conforms to one of the HTTP/1.1 formats and rewrite the date message conforms to one of the HTTP/1.1 formats and rewrite the date
if necessary. if necessary.
Appendix D. Compatibility with Previous Versions Appendix C. Compatibility with Previous Versions
It is beyond the scope of a protocol specification to mandate It is beyond the scope of a protocol specification to mandate
compliance with previous versions. HTTP/1.1 was deliberately compliance with previous versions. HTTP/1.1 was deliberately
designed, however, to make supporting previous versions easy. It is designed, however, to make supporting previous versions easy. It is
worth noting that, at the time of composing this specification worth noting that, at the time of composing this specification
(1996), we would expect commercial HTTP/1.1 servers to: (1996), we would expect commercial HTTP/1.1 servers to:
o recognize the format of the Request-Line for HTTP/0.9, 1.0, and o recognize the format of the Request-Line for HTTP/0.9, 1.0, and
1.1 requests; 1.1 requests;
skipping to change at page 59, line 21 skipping to change at page 60, line 38
o understand any valid response in the format of HTTP/0.9, 1.0, or o understand any valid response in the format of HTTP/0.9, 1.0, or
1.1. 1.1.
For most implementations of HTTP/1.0, each connection is established For most implementations of HTTP/1.0, each connection is established
by the client prior to the request and closed by the server after by the client prior to the request and closed by the server after
sending the response. Some implementations implement the Keep-Alive sending the response. Some implementations implement the Keep-Alive
version of persistent connections described in Section 19.7.1 of version of persistent connections described in Section 19.7.1 of
[RFC2068]. [RFC2068].
D.1. Changes from HTTP/1.0 C.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
D.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP C.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP
Addresses Addresses
The requirements that clients and servers support the Host request- The requirements that clients and servers support the Host request-
header, report an error if the Host request-header (Section 8.4) is header, report an error if the Host request-header (Section 8.4) is
missing from an HTTP/1.1 request, and accept absolute URIs missing from an HTTP/1.1 request, and accept absolute URIs
(Section 5.1.2) are among the most important changes defined by this (Section 5.1.2) are among the most important changes defined by this
specification. specification.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
skipping to change at page 60, line 14 skipping to change at page 61, line 30
o Both clients and servers MUST support the Host request-header. o Both clients and servers MUST support the Host request-header.
o A client that sends an HTTP/1.1 request MUST send a Host header. o A client that sends an HTTP/1.1 request MUST send a Host header.
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header. request does not include a Host request-header.
o Servers MUST accept absolute URIs. o Servers MUST accept absolute URIs.
D.2. Compatibility with HTTP/1.0 Persistent Connections C.2. Compatibility with HTTP/1.0 Persistent Connections
Some clients and servers might wish to be compatible with some Some clients and servers might wish to be compatible with some
previous implementations of persistent connections in HTTP/1.0 previous implementations of persistent connections in HTTP/1.0
clients and servers. Persistent connections in HTTP/1.0 are clients and servers. Persistent connections in HTTP/1.0 are
explicitly negotiated as they are not the default behavior. HTTP/1.0 explicitly negotiated as they are not the default behavior. HTTP/1.0
experimental implementations of persistent connections are faulty, experimental implementations of persistent connections are faulty,
and the new facilities in HTTP/1.1 are designed to rectify these and the new facilities in HTTP/1.1 are designed to rectify these
problems. The problem was that some existing 1.0 clients may be problems. The problem was that some existing 1.0 clients may be
sending Keep-Alive to a proxy server that doesn't understand sending Keep-Alive to a proxy server that doesn't understand
Connection, which would then erroneously forward it to the next Connection, which would then erroneously forward it to the next
skipping to change at page 60, line 41 skipping to change at page 62, line 8
connections, so that prohibition is clearly unacceptable. Therefore, connections, so that prohibition is clearly unacceptable. Therefore,
we need some other mechanism for indicating a persistent connection we need some other mechanism for indicating a persistent connection
is desired, which is safe to use even when talking to an old proxy is desired, which is safe to use even when talking to an old proxy
that ignores Connection. Persistent connections are the default for that ignores Connection. Persistent connections are the default for
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
declaring non-persistence. See Section 8.1. declaring non-persistence. See Section 8.1.
The original HTTP/1.0 form of persistent connections (the Connection: The original HTTP/1.0 form of persistent connections (the Connection:
Keep-Alive and Keep-Alive header) is documented in [RFC2068]. Keep-Alive and Keep-Alive header) is documented in [RFC2068].
D.3. Changes from RFC 2068 C.3. Changes from RFC 2068
This specification has been carefully audited to correct and This specification has been carefully audited to correct and
disambiguate key word usage; RFC 2068 had many problems in respect to disambiguate key word usage; RFC 2068 had many problems in respect to
the conventions laid out in [RFC2119]. the conventions laid out in [RFC2119].
Transfer-coding and message lengths all interact in ways that Transfer-coding and message lengths all interact in ways that
required fixing exactly when chunked encoding is used (to allow for required fixing exactly when chunked encoding is used (to allow for
transfer encoding that may not be self delimiting); it was important transfer encoding that may not be self delimiting); it was important
to straighten out exactly how message lengths are computed. to straighten out exactly how message lengths are computed.
(Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6])
skipping to change at page 61, line 20 skipping to change at page 62, line 36
interactions with chunked encoding. The solution is that transfer- interactions with chunked encoding. The solution is that transfer-
codings become as full fledged as content-codings. This involves codings become as full fledged as content-codings. This involves
adding an IANA registry for transfer-codings (separate from content adding an IANA registry for transfer-codings (separate from content
codings), a new header field (TE) and enabling trailer headers in the codings), a new header field (TE) and enabling trailer headers in the
future. Transfer encoding is a major performance benefit, so it was future. Transfer encoding is a major performance benefit, so it was
worth fixing [Nie1997]. TE also solves another, obscure, downward worth fixing [Nie1997]. TE also solves another, obscure, downward
interoperability problem that could have occurred due to interactions interoperability problem that could have occurred due to interactions
between authentication trailers, chunked encoding and HTTP/1.0 between authentication trailers, chunked encoding and HTTP/1.0
clients.(Section 3.4, 3.4.1, and 8.5) clients.(Section 3.4, 3.4.1, and 8.5)
D.4. Changes from RFC 2616 C.4. Changes from RFC 2616
The CHAR rule does not allow the NUL character anymore (this affects The CHAR rule does not allow the NUL character anymore (this affects
the comment and quoted-string rules). Furthermore, the quoted-pair the comment and quoted-string rules). Furthermore, the quoted-pair
rule does not allow escaping NUL, CR or LF anymore. (Section 2.2) rule does not allow escaping NUL, CR or LF anymore. (Section 2.2)
Clarify that HTTP-Version is case sensitive. (Section 3.1) Clarify that HTTP-Version is case sensitive. (Section 3.1)
Remove reference to non-existant identity transfer-coding value Remove reference to non-existant identity transfer-coding value
tokens. (Sections 3.4 and 4.4) tokens. (Sections 3.4 and 4.4)
skipping to change at page 61, line 36 skipping to change at page 63, line 4
Clarify that HTTP-Version is case sensitive. (Section 3.1) Clarify that HTTP-Version is case sensitive. (Section 3.1)
Remove reference to non-existant identity transfer-coding value Remove reference to non-existant identity transfer-coding value
tokens. (Sections 3.4 and 4.4) tokens. (Sections 3.4 and 4.4)
Clarification that the chunk length does not include the count of the Clarification that the chunk length does not include the count of the
octets in the chunk header and trailer. (Section 3.4.1) octets in the chunk header and trailer. (Section 3.4.1)
Fix BNF to add query, as the abs_path production in Section 3 of Fix BNF to add query, as the abs_path production in Section 3 of
[RFC2396] doesn't define it. (Section 5.1.2) [RFC2396] doesn't define it. (Section 5.1.2)
Clarify exactly when close connection options must be sent. Clarify exactly when close connection options must be sent.
(Section 8.1) (Section 8.1)
Appendix E. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
E.1. Since RFC2616 D.1. Since RFC2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
E.2. Since draft-ietf-httpbis-p1-messaging-00 D.2. Since draft-ietf-httpbis-p1-messaging-00
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP
Version should be case sensitive" Version should be case sensitive"
(<http://purl.org/NET/http-errata#verscase>) (<http://purl.org/NET/http-errata#verscase>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
characters" (<http://purl.org/NET/http-errata#unsafe-uri>) characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
skipping to change at page 63, line 24 skipping to change at page 64, line 36
up-to-date references" up-to-date references"
Other changes: Other changes:
o Update media type registrations to use RFC4288 template. o Update media type registrations to use RFC4288 template.
o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF
for chunk-data (work in progress on for chunk-data (work in progress on
<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>)
E.3. Since draft-ietf-httpbis-p1-messaging-01 D.3. Since draft-ietf-httpbis-p1-messaging-01
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on
GET (and other) requests" GET (and other) requests"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating
to RFC4288" to RFC4288"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status
skipping to change at page 64, line 22 skipping to change at page 65, line 34
o Move "Product Tokens" section (back) into Part 1, as "token" is o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header. used in the definition of the Upgrade header.
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
"TEXT". "TEXT".
E.4. Since draft-ietf-httpbis-p1-messaging-02 D.4. Since draft-ietf-httpbis-p1-messaging-02
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date
vs. rfc1123-date" vs. rfc1123-date"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in
quoted-pair" quoted-pair"
Ongoing work on IANA Message Header Registration Ongoing work on IANA Message Header Registration
skipping to change at page 64, line 44 skipping to change at page 66, line 8
o Reference RFC 3984, and update header registrations for headers o Reference RFC 3984, and update header registrations for headers
defined in this document. defined in this document.
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive o Replace string literals when the string really is case-sensitive
(HTTP-Version). (HTTP-Version).
D.5. Since draft-ietf-httpbis-p1-messaging-03
Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/28>:
"Connection closing"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
registrations and registry information to IANA Considerations"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new
URL for PAD1995 reference"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
Considerations: update HTTP URI scheme registration"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite
HTTPS URI scheme definition"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-
type headers vs Set-Cookie"
Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive
(HTTP-Date).
o Replace HEX by HEXDIG for future consistence with RFC 5234's core
rules.
Index Index
A A
application/http Media Type 56 application/http Media Type 50
C C
cache 8 cache 8
cacheable 9 cacheable 9
client 7 client 7
connection 6 connection 6
Connection header 39 Connection header 40
content negotiation 7 content negotiation 7
Content-Length header 40 Content-Length header 41
D D
Date header 41 Date header 42
downstream 9 downstream 9
E E
entity 7 entity 7
G G
gateway 8 gateway 8
Grammar Grammar
absoluteURI 18 absoluteURI 18
ALPHA 14 ALPHA 14
asctime-date 20 asctime-date 20
attribute 20 attribute 21
authority 18 authority 18
CHAR 14 CHAR 14
chunk 22 chunk 22
chunk-data 22 chunk-data 22
chunk-ext-name 22 chunk-ext-name 22
chunk-ext-val 22 chunk-ext-val 22
chunk-extension 22 chunk-extension 22
chunk-size 22 chunk-size 22
Chunked-Body 22 Chunked-Body 22
comment 15 comment 15
Connection 39 Connection 40
connection-token 39 connection-token 40
Content-Length 40 Content-Length 41
CR 14 CR 14
CRLF 14 CRLF 14
ctext 15 ctext 15
CTL 14 CTL 14
Date 41 Date 42
date1 20 date1 20
date2 20 date2 20
date3 20 date3 20
DIGIT 14 DIGIT 14
DQUOTE 14 DQUOTE 14
extension-code 32 extension-code 33
extension-method 29 extension-method 29
field-content 25 field-content 25
field-name 25 field-name 25
field-value 25 field-value 25
general-header 28 general-header 29
generic-message 24 generic-message 25
HEX 15 HEXDIG 15
Host 42 Host 43
HTAB 14 HTAB 14
HTTP-date 20 HTTP-date 20
HTTP-message 24 HTTP-message 24
HTTP-Prot-Name 16 HTTP-Prot-Name 16
http-URL 18 http-URL 18
HTTP-Version 16 HTTP-Version 16
last-chunk 22 last-chunk 22
LF 14 LF 14
LWS 14 LWS 14
message-body 25 message-body 26
message-header 25 message-header 25
Method 29 Method 29
month 20 month 20
obsolete-date 20 obsolete-date 20
OCTET 14 OCTET 14
parameter 20 parameter 21
path-absolute 18 path-absolute 18
port 18 port 18
product 23 product 24
product-version 23 product-version 24
protocol-name 46 protocol-name 47
protocol-version 46 protocol-version 47
pseudonym 46 pseudonym 47
qdtext 15 qdtext 15
query 18 query 18
quoted-pair 15 quoted-pair 15
quoted-string 15 quoted-string 15
quoted-text 15 quoted-text 15
Reason-Phrase 32 Reason-Phrase 33
received-by 46 received-by 47
received-protocol 46 received-protocol 47
relativeURI 18 relativeURI 18
Request 28 Request 29
Request-Line 28 Request-Line 29
Request-URI 29 Request-URI 30
Response 31 Response 32
rfc850-date 20 rfc850-date 20
rfc1123-date 20 rfc1123-date 20
separators 15 separators 15
SP 14 SP 14
start-line 24 start-line 25
Status-Code 32 Status-Code 33
Status-Line 31 Status-Line 32
t-codings 43 t-codings 44
tchar 15 tchar 15
TE 43 TE 44
TEXT 14 TEXT 14
time 20 time 20
token 15 token 15
Trailer 44 Trailer 45
trailer-part 22 trailer-part 22
transfer-coding 20 transfer-coding 21
Transfer-Encoding 44 Transfer-Encoding 45
transfer-extension 20 transfer-extension 21
Upgrade 45 Upgrade 46
uri-host 18 uri-host 18
value 20 value 21
Via 46 Via 47
weekday 20 weekday 20
wkday 20 wkday 20
H H
Headers Headers
Connection 39 Connection 40
Content-Length 40 Content-Length 41
Date 41 Date 42
Host 42 Host 43
TE 43 TE 44
Trailer 44 Trailer 45
Transfer-Encoding 44 Transfer-Encoding 45
Upgrade 45 Upgrade 46
Via 46 Via 47
Host header 42 Host header 43
http URI scheme 18
https URI scheme 18
I I
implied *LWS 13 implied *LWS 13
inbound 9 inbound 9
M M
Media Type Media Type
application/http 56 application/http 50
message/http 55 message/http 49
message 6 message 6
message/http Media Type 55 message/http Media Type 49
O O
origin server 8 origin server 8
outbound 9 outbound 9
P P
proxy 8 proxy 8
R R
representation 7 representation 7
request 6 request 6
resource 7 resource 7
response 6 response 6
S S
server 8 server 8
T T
skipping to change at page 68, line 14 skipping to change at page 70, line 10
R R
representation 7 representation 7
request 6 request 6
resource 7 resource 7
response 6 response 6
S S
server 8 server 8
T T
TE header 43 TE header 44
Trailer header 44 Trailer header 45
Transfer-Encoding header 44 Transfer-Encoding header 45
tunnel 8 tunnel 8
U U
Upgrade header 45 Upgrade header 46
upstream 9 upstream 9
URI scheme
http 18
https 18
user agent 7 user agent 7
V V
variant 7 variant 7
Via header 46 Via header 47
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
 End of changes. 83 change blocks. 
300 lines changed or deleted 397 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/