draft-ietf-httpbis-p1-messaging-01.txt   draft-ietf-httpbis-p1-messaging-02.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: July 15, 2008 J. Mogul Expires: August 27, 2008 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
January 12, 2008 February 24, 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-01 draft-ietf-httpbis-p1-messaging-02
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 July 15, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 15 2.3. ABNF Rules defined in other Parts of the Specification . . 16
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 18 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 18 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 19 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 20
3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 20 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 21
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 24
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25
4.5. General Header Fields . . . . . . . . . . . . . . . . . . 26 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 26
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 27 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. The Resource Identified by a Request . . . . . . . . . . . 29 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 29
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. The Resource Identified by a Request . . . . . . . . . . . 30
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 31 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 31 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 31 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 33 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 33
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 33 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34
7.2. Message Transmission Requirements . . . . . . . . . . . . 34 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35
7.2.1. Persistent Connections and Flow Control . . . . . . . 34 7.2. Message Transmission Requirements . . . . . . . . . . . . 36
7.2.2. Monitoring Connections for Error Status Messages . . . 34 7.2.1. Persistent Connections and Flow Control . . . . . . . 36
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 35 7.2.2. Monitoring Connections for Error Status Messages . . . 36
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 37 Connection . . . . . . . . . . . . . . . . . . . . . . 38
8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 37 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 39
8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 39 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40
8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.3.1. Clockless Origin Server Operation . . . . . . . . . . 40 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42
8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 43 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44
8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 10. Security Considerations . . . . . . . . . . . . . . . . . . . 47
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 46 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 46 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 48
10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 48 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 49
10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 48 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . . 50 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
12.2. Informative References . . . . . . . . . . . . . . . . . . 51 12.2. Informative References . . . . . . . . . . . . . . . . . . 52
Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 53 Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 54
A.1. Internet Media Type message/http . . . . . . . . . . . . . 53 A.1. Internet Media Type message/http . . . . . . . . . . . . . 54
A.2. Internet Media Type application/http . . . . . . . . . . . 54 A.2. Internet Media Type application/http . . . . . . . . . . . 56
Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 55 Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57
Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 56 Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58
Appendix D. Compatibility with Previous Versions . . . . . . . . 56 Appendix D. Compatibility with Previous Versions . . . . . . . . 58
D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 57 D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 58
D.1.1. Changes to Simplify Multi-homed Web Servers and D.1.1. Changes to Simplify Multi-homed Web Servers and
Conserve IP Addresses . . . . . . . . . . . . . . . . 57 Conserve IP Addresses . . . . . . . . . . . . . . . . 59
D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 58 D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59
D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 58 D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60
D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 59 D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 60
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 59 publication) . . . . . . . . . . . . . . . . . . . . 61
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 59 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61
E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 59 E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67
Intellectual Property and Copyright Statements . . . . . . . . . . 70
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 7, line 18 skipping to change at page 7, line 18
A network data object or service that can be identified by a URI, A network data object or service that can be identified by a URI,
as defined in Section 3.2. Resources may be available in multiple as defined in Section 3.2. Resources may be available in multiple
representations (e.g. multiple languages, data formats, size, and representations (e.g. multiple languages, data formats, size, and
resolutions) or vary in other ways. resolutions) or vary in other ways.
entity entity
The information transferred as the payload of a request or The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of response. An entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, as entity-header fields and content in the form of an entity-body, as
described in Section 3 of [Part3]. described in Section 4 of [Part3].
representation representation
An entity included with a response that is subject to content An entity included with a response that is subject to content
negotiation, as described in Section 4 of [Part3]. There may negotiation, as described in Section 5 of [Part3]. There may
exist multiple representations associated with a particular exist multiple representations associated with a particular
response status. response status.
content negotiation content negotiation
The mechanism for selecting the appropriate representation when The mechanism for selecting the appropriate representation when
servicing a request, as described in Section 4 of [Part3]. The servicing a request, as described in Section 5 of [Part3]. The
representation of entities in any response can be negotiated representation of entities in any response can be negotiated
(including error responses). (including error responses).
variant variant
A resource may have one, or more than one, representation(s) A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these associated with it at any given instant. Each of these
representations is termed a `variant'. Use of the term `variant' representations is termed a `variant'. Use of the term `variant'
does not necessarily imply that the resource is subject to content does not necessarily imply that the resource is subject to content
negotiation. negotiation.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
messages flow from upstream to downstream. messages flow from upstream to downstream.
inbound/outbound inbound/outbound
Inbound and outbound refer to the request and response paths for Inbound and outbound refer to the request and response paths for
messages: "inbound" means "traveling toward the origin server", messages: "inbound" means "traveling toward the origin server",
and "outbound" means "traveling toward the user agent" and "outbound" means "traveling toward the user agent"
1.4. Overall Operation 1.4. Overall Operation
The HTTP protocol is a request/response protocol. A client sends a HTTP is a request/response protocol. A client sends a request to the
request to the server in the form of a request method, URI, and server in the form of a request method, URI, and protocol version,
protocol version, followed by a MIME-like message containing request followed by a MIME-like message containing request modifiers, client
modifiers, client information, and possible body content over a information, and possible body content over a connection with a
connection with a server. The server responds with a status line, server. The server responds with a status line, including the
including the message's protocol version and a success or error code, message's protocol version and a success or error code, followed by a
followed by a MIME-like message containing server information, entity MIME-like message containing server information, entity
metainformation, and possible entity-body content. The relationship metainformation, and possible entity-body content. The relationship
between HTTP and MIME is described in Appendix A of [Part3]. between HTTP and MIME is described in Appendix A of [Part3].
Most HTTP communication is initiated by a user agent and consists of Most HTTP communication is initiated by a user agent and consists of
a request to be applied to a resource on some origin server. In the a request to be applied to a resource on some origin server. In the
simplest case, this may be accomplished via a single connection (v) simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O). between the user agent (UA) and the origin server (O).
request chain ------------------------> request chain ------------------------>
UA -------------------v------------------- O UA -------------------v------------------- O
skipping to change at page 14, line 5 skipping to change at page 14, line 5
separators) MUST exist between any two tokens (for the definition separators) MUST exist between any two tokens (for the definition
of "token" below), since they would otherwise be interpreted as a of "token" below), since they would otherwise be interpreted as a
single token. single token.
2.2. Basic Rules 2.2. Basic Rules
The following rules are used throughout this specification to The following rules are used throughout this specification to
describe basic parsing constructs. The US-ASCII coded character set describe basic parsing constructs. The US-ASCII coded character set
is defined by ANSI X3.4-1986 [USASCII]. is defined by ANSI X3.4-1986 [USASCII].
OCTET = <any 8-bit sequence of data> OCTET = %x00-FF
CHAR = <any US-ASCII character (octets 0 - 127)> ; any 8-bit sequence of data
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> CHAR = %x01-7F
LOALPHA = <any US-ASCII lowercase letter "a".."z"> ; any US-ASCII character, excluding NUL
ALPHA = UPALPHA | LOALPHA ALPHA = %x41-5A | %x61-7A
DIGIT = <any US-ASCII digit "0".."9"> ; A-Z | a-z
CTL = <any US-ASCII control character DIGIT = %x30-39
(octets 0 - 31) and DEL (127)> ; any US-ASCII digit "0".."9"
CR = <US-ASCII CR, carriage return (13)> CTL = %x00-1F | %x7F
LF = <US-ASCII LF, linefeed (10)> ; (octets 0 - 31) and DEL (127)
SP = <US-ASCII SP, space (32)> CR = %x0D
HTAB = <US-ASCII HT, horizontal-tab (9)> ; US-ASCII CR, carriage return (13)
DQUOTE = <US-ASCII double-quote mark (34)> LF = %x0A
; US-ASCII LF, linefeed (10)
SP = %x20
; US-ASCII SP, space (32)
HTAB = %x09
; US-ASCII HT, horizontal-tab (9)
DQUOTE = %x22
; 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 B 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 2.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
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
LWS = [CRLF] 1*( SP | HTAB ) LWS = [CRLF] 1*( SP | HTAB )
The TEXT rule is only used for descriptive field contents and values The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO- of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [ISO-8859-1] only when encoded according to the rules of 8859-1 [ISO-8859-1] only when encoded according to the rules of
[RFC2047]. [RFC2047].
TEXT = <any OCTET except CTLs, TEXT = %x20-7E | %x80-FF | LWS
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" HEX = "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).
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@" separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | DQUOTE | "," | ";" | ":" | "\" | DQUOTE
| "/" | "[" | "]" | "?" | "=" | "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HTAB | "{" | "}" | SP | HTAB
tchar = "!" | "#" | "$" | "%" | "&" | "'" | "*"
| "+" | "-" | "." | "^" | "_" | "`" | "|" | "~"
| DIGIT | ALPHA
; any CHAR except CTLs or separators
token = 1*tchar
Comments can be included in some HTTP header fields by surrounding Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition. fields containing "comment" as part of their field value definition.
In all other fields, parentheses are considered part of the field In all other fields, parentheses are considered part of the field
value. value.
comment = "(" *( ctext | quoted-pair | comment ) ")" comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")"> ctext = <any TEXT excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using A string of text is parsed as a single word if it is quoted using
double-quote marks. double-quote marks.
quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE ) quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE )
qdtext = <any TEXT excluding DQUOTE and "\"> qdtext = <any TEXT excluding DQUOTE and "\">
The backslash character ("\") MAY be used as a single-character The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs. quoting mechanism only within quoted-string and comment constructs.
quoted-pair = "\" CHAR quoted-pair = "\" CHAR
2.3. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts:
request-header = <request-header, defined in [Part2], Section 4>
response-header = <response-header, defined in [Part2], Section 6>
accept-params = <accept-params, defined in [Part3], Section 6.1>
entity-body = <entity-body, defined in [Part3], Section 4.2>
entity-header = <entity-header, defined in [Part3], Section 4.1>
Cache-Control = <Cache-Control, defined in [Part6], Section 16.4>
Pragma = <Pragma, defined in [Part6], Section 16.4>
Warning = <Warning, defined in [Part6], Section 16.6>
3. Protocol Parameters 3. Protocol Parameters
3.1. HTTP Version 3.1. HTTP Version
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow of the protocol. The protocol versioning policy is intended to allow
the sender to indicate the format of a message and its capacity for the sender to indicate the format of a message and its capacity for
understanding further HTTP communication, rather than the features understanding further HTTP communication, rather than the features
obtained via that communication. No change is made to the version obtained via that communication. No change is made to the version
number for the addition of message components which do not affect number for the addition of message components which do not affect
skipping to change at page 17, line 16 skipping to change at page 17, line 50
3.2.1. General Syntax 3.2.1. General Syntax
URIs in HTTP can be represented in absolute form or relative to some URIs in HTTP can be represented in absolute form or relative to some
known base URI [RFC1808], depending upon the context of their use. known base URI [RFC1808], depending upon the context of their use.
The two forms are differentiated by the fact that absolute URIs The two forms are differentiated by the fact that absolute URIs
always begin with a scheme name followed by a colon. For definitive always begin with a scheme name followed by a colon. For definitive
information on URL syntax and semantics, see "Uniform Resource information on URL syntax and semantics, see "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which
replaces [RFC1738] and [RFC1808]). This specification adopts the replaces [RFC1738] and [RFC1808]). This specification adopts the
definitions of "URI-reference", "absoluteURI", "relativeURI", "port", definitions of "URI-reference", "absoluteURI", "fragment",
"host", "abs_path", "rel_path", "query", and "authority" from that "relativeURI", "port", "host", "abs_path", "query", and "authority"
specification. from that specification:
The HTTP protocol does not place any a priori limit on the length of absoluteURI = <absoluteURI, defined in [RFC2396], Section 3>
a URI. Servers MUST be able to handle the URI of any resource they authority = <authority, defined in [RFC2396], Section 3.2>
serve, and SHOULD be able to handle URIs of unbounded length if they fragment = <fragment, defined in [RFC2396], Section 4.1>
provide GET-based forms that could generate such URIs. A server path-absolute = <abs_path, defined in [RFC2396], Section 3>
SHOULD return 414 (Request-URI Too Long) status if a URI is longer port = <port, defined in [RFC2396], Section 3.2.2>
than the server can handle (see Section 9.4.15 of [Part2]). query = <query, defined in [RFC2396], Section 3.4>
relativeURI = <relativeURI, defined in [RFC2396], Section 5>
uri-host = <host, defined in [RFC2396], Section 3.2.2>
HTTP does not place any a priori limit on the length of a URI.
Servers MUST be able to handle the URI of any resource they serve,
and SHOULD be able to handle URIs of unbounded length if they provide
GET-based forms that could generate such URIs. A server SHOULD
return 414 (Request-URI Too Long) status if a URI is longer than the
server can handle (see Section 9.4.15 of [Part2]).
Note: Servers ought to be cautious about depending on URI lengths Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy above 255 bytes, because some older client or proxy
implementations might not properly support these lengths. implementations might not properly support these lengths.
3.2.2. http URL 3.2.2. http URL
The "http" scheme is used to locate network resources via the HTTP The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and protocol. This section defines the scheme-specific syntax and
semantics for http URLs. semantics for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] http-URL = "http:" "//" uri-host [ ":" port ]
[ path-absolute [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The semantics If the port is empty or not given, port 80 is assumed. The semantics
are that the identified resource is located at the server listening are that the identified resource is located at the server listening
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 abs_path (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 abs_path is not present in the URL, it MUST be [RFC1900]). If the path-absolute is not present in the URL, it MUST
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.
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 abs_path is equivalent to an abs_path 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]) are
equivalent to their ""%" HEX HEX" encoding. equivalent to their ""%" HEX HEX" 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
skipping to change at page 20, line 32 skipping to change at page 21, line 25
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
transfer-coding value tokens. Initially, the registry contains the transfer-coding value tokens. Initially, the registry contains the
following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and
"deflate" (Section 2.2 of [Part3]). "deflate" (Section 3.2 of [Part3]).
New transfer-coding value tokens SHOULD be registered in the same way New transfer-coding value tokens SHOULD be registered in the same way
as new content-coding value tokens (Section 2.2 of [Part3]). as new content-coding value tokens (Section 3.2 of [Part3]).
A server which receives an entity-body with a transfer-coding it does A server which receives an entity-body with a transfer-coding it does
not understand SHOULD return 501 (Not Implemented), and close the not understand SHOULD return 501 (Not Implemented), and close the
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 connection. A server MUST NOT send transfer-codings to an HTTP/1.0
client. client.
3.4.1. Chunked Transfer Coding 3.4.1. Chunked Transfer Coding
The chunked encoding modifies the body of a message in order to The chunked encoding modifies the body of a message in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing entity-header fields. followed by an OPTIONAL trailer containing entity-header fields.
This allows dynamically produced content to be transferred along with This allows dynamically produced content to be transferred along with
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 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*HEX
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 = *(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
whose size is zero, followed by the trailer, which is terminated by whose size is zero, followed by the trailer, which is terminated by
an empty line. an empty line.
The trailer allows the sender to include additional HTTP header The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be fields at the end of the message. The Trailer header field can be
used to indicate which header fields are included in a trailer (see used to indicate which header fields are included in a trailer (see
Section 8.6). Section 8.6).
skipping to change at page 22, line 28 skipping to change at page 23, line 28
append entity-header to existing header fields append entity-header to existing header fields
read entity-header read entity-header
} }
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
All HTTP/1.1 applications MUST be able to receive and decode the All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding, and MUST ignore chunk-extension extensions "chunked" transfer-coding, and MUST ignore chunk-extension extensions
they do not understand. they do not understand.
3.5. Product Tokens
Product tokens are used to allow communicating applications to
identify themselves by software name and version. Most fields using
product tokens also allow sub-products which form a significant part
of the application to be listed, separated by white space. By
convention, the products are listed in order of their significance
for identifying the application.
product = token ["/" product-version]
product-version = token
Examples:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Product tokens SHOULD be short and to the point. They MUST NOT be
used for advertising or other non-essential information. Although
any token character MAY appear in a product-version, this token
SHOULD only be used for a version identifier (i.e., successive
versions of the same product SHOULD only differ in the product-
version portion of the product value).
4. HTTP Message 4. HTTP Message
4.1. Message Types 4.1. Message Types
HTTP messages consist of requests from client to server and responses HTTP messages consist of requests from client to server and responses
from server to client. from server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages HTTP-message = Request | Response ; HTTP/1.1 messages
Request (Section 5) and Response (Section 6) messages use the generic Request (Section 5) and Response (Section 6) messages use the generic
skipping to change at page 23, line 16 skipping to change at page 24, line 41
Certain buggy HTTP/1.0 client implementations generate extra CRLF's Certain buggy HTTP/1.0 client implementations generate extra CRLF's
after a POST request. To restate what is explicitly forbidden by the after a POST request. To restate what is explicitly forbidden by the
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
extra CRLF. extra CRLF.
4.2. Message Headers 4.2. Message Headers
HTTP header fields, which include general-header (Section 4.5), HTTP header fields, which include general-header (Section 4.5),
request-header (Section 4 of [Part2]), response-header (Section 6 of request-header (Section 4 of [Part2]), response-header (Section 6 of
[Part2]), and entity-header (Section 3.1 of [Part3]) fields, follow [Part2]), and entity-header (Section 4.1 of [Part3]) fields, follow
the same generic format as that given in Section 2.1 of [RFC2822]. the same generic format as that given in Section 2.1 of [RFC2822].
Each header field consists of a name followed by a colon (":") and Each header field consists of a name followed by a colon (":") and
the field value. Field names are case-insensitive. The field value the field value. Field names are case-insensitive. The field value
MAY be preceded by any amount of LWS, though a single SP is MAY be preceded by any amount of LWS, though a single SP is
preferred. Header fields can be extended over multiple lines by preferred. Header fields can be extended over multiple lines by
preceding each extra line with at least one SP or HTAB. Applications preceding each extra line with at least one SP or HTAB. Applications
ought to follow "common form", where one is known or indicated, when ought to follow "common form", where one is known or indicated, when
generating HTTP constructs, since there might exist some generating HTTP constructs, since there might exist some
implementations that fail to accept anything beyond the common forms. implementations that fail to accept anything beyond the common forms.
message-header = field-name ":" [ field-value ] message-header = field-name ":" [ field-value ]
field-name = token field-name = token
field-value = *( field-content | LWS ) field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value field-content = <field content>
and consisting of either *TEXT or combinations ; the OCTETs making up the field-value
of token, separators, and quoted-string> ; and consisting of either *TEXT or combinations
; of token, separators, and quoted-string
The field-content does not include any leading or trailing LWS: The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message before interpreting the field value or forwarding the message
downstream. downstream.
skipping to change at page 24, line 36 skipping to change at page 26, line 14
request/response chain. (However, Section 3.4 places restrictions on request/response chain. (However, Section 3.4 places restrictions on
when certain transfer-codings may be used.) when certain transfer-codings may be used.)
The rules for when a message-body is allowed in a message differ for The rules for when a message-body is allowed in a message differ for
requests and responses. requests and responses.
The presence of a message-body in a request is signaled by the The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included the request's message-headers. A message-body MUST NOT be included
in a request if the specification of the request method (Section 3 of in a request if the specification of the request method (Section 3 of
[Part2]) does not allow sending an entity-body in requests. A server [Part2]) explicitly disallows an entity-body in requests. When a
SHOULD read and forward a message-body on any request; if the request request message contains both a message-body of non-zero length and a
method does not include defined semantics for an entity-body, then method that does not define any semantics for that request message-
the message-body SHOULD be ignored when handling the request. body, then an origin server SHOULD either ignore the message-body or
respond with an appropriate error message (e.g., 413). A proxy or
gateway, when presented the same request, SHOULD either forward the
request inbound with the message-body or ignore the message-body when
determining a response.
For response messages, whether or not a message-body is included with For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response a message is dependent on both the request method and the response
status code (Section 6.1.1). All responses to the HEAD request status code (Section 6.1.1). All responses to the HEAD request
method MUST NOT include a message-body, even though the presence of method MUST NOT include a message-body, even though the presence of
entity-header fields might lead one to believe they do. All 1xx entity-header fields might lead one to believe they do. All 1xx
(informational), 204 (No Content), and 304 (Not Modified) responses (informational), 204 (No Content), and 304 (Not Modified) responses
MUST NOT include a message-body. All other responses do include a MUST NOT include a message-body. All other responses do include a
message-body, although it MAY be of zero length. message-body, although it MAY be of zero length.
skipping to change at page 26, line 30 skipping to change at page 28, line 12
the message-body. HTTP/1.1 user agents MUST notify the user when an the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected. invalid length is received and detected.
4.5. General Header Fields 4.5. General Header Fields
There are a few header fields which have general applicability for There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the both request and response messages, but which do not apply to the
entity being transferred. These header fields apply only to the entity being transferred. These header fields apply only to the
message being transmitted. message being transmitted.
general-header = Cache-Control ; [Part6], Section 15.2 general-header = Cache-Control ; [Part6], Section 16.2
| Connection ; Section 8.1 | Connection ; Section 8.1
| Date ; Section 8.3 | Date ; Section 8.3
| Pragma ; [Part6], Section 15.4 | Pragma ; [Part6], Section 16.4
| Trailer ; Section 8.6 | Trailer ; Section 8.6
| Transfer-Encoding ; Section 8.7 | Transfer-Encoding ; Section 8.7
| Upgrade ; Section 8.8 | Upgrade ; Section 8.8
| Via ; Section 8.9 | Via ; Section 8.9
| Warning ; [Part6], Section 15.6 | Warning ; [Part6], Section 16.6
General-header field names can be extended reliably only in General-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of general experimental header fields may be given the semantics of general
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as be general-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
5. Request 5. Request
A request message from a client to a server includes, within the A request message from a client to a server includes, within the
first line of that message, the method to be applied to the resource, first line of that message, the method to be applied to the resource,
the identifier of the resource, and the protocol version in use. the identifier of the resource, and the protocol version in use.
Request = Request-Line ; Section 5.1 Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5 *(( general-header ; Section 4.5
| request-header ; [Part2], Section 4 | request-header ; [Part2], Section 4
| entity-header ) CRLF) ; [Part3], Section 3.1 | entity-header ) CRLF) ; [Part3], Section 4.1
CRLF CRLF
[ message-body ] ; Section 4.3 [ message-body ] ; Section 4.3
5.1. Request-Line 5.1. Request-Line
The Request-Line begins with a method token, followed by the Request- The Request-Line begins with a method token, followed by the Request-
URI and the protocol version, and ending with CRLF. The elements are URI and the protocol version, and ending with CRLF. The elements are
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
skipping to change at page 27, line 36 skipping to change at page 29, line 19
Method = token Method = token
5.1.2. Request-URI 5.1.2. Request-URI
The Request-URI is a Uniform Resource Identifier (Section 3.2) and The Request-URI is a Uniform Resource Identifier (Section 3.2) and
identifies the resource upon which to apply the request. identifies the resource upon which to apply the request.
Request-URI = "*" Request-URI = "*"
| absoluteURI | absoluteURI
| ( abs_path [ "?" query ] ) | ( path-absolute [ "?" query ] )
| authority | authority
The four options for Request-URI are dependent on the nature of the The four options for Request-URI are dependent on the nature of the
request. The asterisk "*" means that the request does not apply to a request. The asterisk "*" means that the request does not apply to a
particular resource, but to the server itself, and is only allowed particular resource, but to the server itself, and is only allowed
when the method used does not necessarily apply to a resource. One when the method used does not necessarily apply to a resource. One
example would be example would be
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
skipping to change at page 28, line 20 skipping to change at page 29, line 51
To allow for transition to absoluteURIs in all requests in future To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies. them in requests to proxies.
The authority form is only used by the CONNECT method (Section 8.9 of The authority form is only used by the CONNECT method (Section 8.9 of
[Part2]). [Part2]).
The most common form of Request-URI is that used to identify a The most common form of Request-URI is that used to identify a
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, abs_path) as path of the URI MUST be transmitted (see Section 3.2.1, path-
the Request-URI, and the network location of the URI (authority) MUST absolute) as the Request-URI, and the network location of the URI
be transmitted in a Host header field. For example, a client wishing (authority) MUST be transmitted in a Host header field. For example,
to retrieve the resource above directly from the origin server would a client wishing to retrieve the resource above directly from the
create a TCP connection to port 80 of the host "www.example.org" and origin server would create a TCP connection to port 80 of the host
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 "% HEX HEX"
encoding [RFC2396], the origin server MUST decode the Request-URI in encoding [RFC2396], the origin server MUST decode the Request-URI in
order to properly interpret the request. Servers SHOULD respond to order to properly interpret the request. Servers SHOULD respond to
invalid Request-URIs with an appropriate status code. invalid Request-URIs with an appropriate status code.
A transparent proxy MUST NOT rewrite the "abs_path" 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 abs_path 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
skipping to change at page 29, line 45 skipping to change at page 31, line 26
exact resource is being requested. exact resource is being requested.
6. Response 6. Response
After receiving and interpreting a request message, a server responds After receiving and interpreting a request message, a server responds
with an HTTP response message. with an HTTP response message.
Response = Status-Line ; Section 6.1 Response = Status-Line ; Section 6.1
*(( general-header ; Section 4.5 *(( general-header ; Section 4.5
| response-header ; [Part2], Section 6 | response-header ; [Part2], Section 6
| entity-header ) CRLF) ; [Part3], Section 3.1 | entity-header ) CRLF) ; [Part3], Section 4.1
CRLF CRLF
[ message-body ] ; Section 4.3 [ message-body ] ; Section 4.3
6.1. Status-Line 6.1. Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its of the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP associated textual phrase, with each element separated by SP
characters. No CR or LF is allowed except in the final CRLF characters. No CR or LF is allowed except in the final CRLF
sequence. sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1. Status Code and Reason Phrase 6.1.1. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully attempt to understand and satisfy the request. These codes are fully
defined in Section 9 of [Part2]. The Reason-Phrase is intended to defined in Section 9 of [Part2]. The Reason Phrase exists for the
give a short textual description of the Status-Code. The Status-Code sole purpose of providing a textual description associated with the
is intended for use by automata and the Reason-Phrase is intended for numeric status code, out of deference to earlier Internet application
the human user. The client is not required to examine or display the protocols that were more frequently used with interactive text
Reason-Phrase. clients. A client SHOULD ignore the content of the Reason Phrase.
The first digit of the Status-Code defines the class of response. The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. There are 5 The last two digits do not have any categorization role. There are 5
values for the first digit: values for the first digit:
o 1xx: Informational - Request received, continuing process o 1xx: Informational - Request received, continuing process
o 2xx: Success - The action was successfully received, understood, o 2xx: Success - The action was successfully received, understood,
and accepted and accepted
skipping to change at page 41, line 11 skipping to change at page 42, line 33
The Host request-header field specifies the Internet host and port The Host request-header field specifies the Internet host and port
number of the resource being requested, as obtained from the original number of the resource being requested, as obtained from the original
URI given by the user or referring resource (generally an HTTP URL, URI given by the user or referring resource (generally an HTTP URL,
as described in Section 3.2.2). The Host field value MUST represent as described in Section 3.2.2). The Host field value MUST represent
the naming authority of the origin server or gateway given by the the naming authority of the origin server or gateway given by the
original URL. This allows the origin server or gateway to original URL. This allows the origin server or gateway to
differentiate between internally-ambiguous URLs, such as the root "/" differentiate between internally-ambiguous URLs, such as the root "/"
URL of a server for multiple host names on a single IP address. URL of a server for multiple host names on a single IP address.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 Host = "Host" ":" uri-host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information implies the default A "host" without any trailing port information implies the default
port for the service requested (e.g., "80" for an HTTP URL). For port for the service requested (e.g., "80" for an HTTP URL). For
example, a request on the origin server for example, a request on the origin server for
<http://www.example.org/pub/WWW/> would properly include: <http://www.example.org/pub/WWW/> would properly include:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.example.org Host: www.example.org
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
skipping to change at page 42, line 31 skipping to change at page 44, line 4
clients are willing to accept trailer fields in the forwarded clients are willing to accept trailer fields in the forwarded
response, or that it will attempt to buffer the response on response, or that it will attempt to buffer the response on
behalf of downstream recipients. behalf of downstream recipients.
Note: HTTP/1.1 does not define any means to limit the size of a Note: HTTP/1.1 does not define any means to limit the size of a
chunked response such that a client can be assured of buffering chunked response such that a client can be assured of buffering
the entire response. the entire response.
2. If the transfer-coding being tested is one of the transfer- 2. If the transfer-coding being tested is one of the transfer-
codings listed in the TE field, then it is acceptable unless it codings listed in the TE field, then it is acceptable unless it
is accompanied by a qvalue of 0. (As defined in Section 2.4 of is accompanied by a qvalue of 0. (As defined in Section 3.4 of
[Part3], a qvalue of 0 means "not acceptable.") [Part3], a qvalue of 0 means "not acceptable.")
3. If multiple transfer-codings are acceptable, then the acceptable 3. If multiple transfer-codings are acceptable, then the acceptable
transfer-coding with the highest non-zero qvalue is preferred. transfer-coding with the highest non-zero qvalue is preferred.
The "chunked" transfer-coding always has a qvalue of 1. The "chunked" transfer-coding always has a qvalue of 1.
If the TE field-value is empty or if no TE field is present, the only If the TE field-value is empty or if no TE field is present, the only
transfer-coding is "chunked". A message with no transfer-coding is transfer-coding is "chunked". A message with no transfer-coding is
always acceptable. always acceptable.
skipping to change at page 45, line 9 skipping to change at page 46, line 31
agent and the server on requests, and between the origin server and agent and the server on requests, and between the origin server and
the client on responses. It is analogous to the "Received" field of the client on responses. It is analogous to the "Received" field of
[RFC2822] and is intended to be used for tracking message forwards, [RFC2822] and is intended to be used for tracking message forwards,
avoiding request loops, and identifying the protocol capabilities of avoiding request loops, and identifying the protocol capabilities of
all senders along the request/response chain. all senders along the request/response chain.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym received-by = ( uri-host [ ":" port ] ) | pseudonym
pseudonym = token pseudonym = token
The received-protocol indicates the protocol version of the message The received-protocol indicates the protocol version of the message
received by the server or client along each segment of the request/ received by the server or client along each segment of the request/
response chain. The received-protocol version is appended to the Via response chain. The received-protocol version is appended to the Via
field value when the message is forwarded so that information about field value when the message is forwarded so that information about
the protocol capabilities of upstream applications remains visible to the protocol capabilities of upstream applications remains visible to
all recipients. all recipients.
The protocol-name is optional if and only if it would be "HTTP". The The protocol-name is optional if and only if it would be "HTTP". The
skipping to change at page 46, line 23 skipping to change at page 47, line 45
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Applications SHOULD NOT combine multiple entries unless they are all Applications SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been under the same organizational control and the hosts have already been
replaced by pseudonyms. Applications MUST NOT combine entries which replaced by pseudonyms. Applications MUST NOT combine entries which
have different received-protocol values. have different received-protocol values.
9. IANA Considerations 9. IANA Considerations
TBD. [[anchor1: TBD.]]
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
HTTP clients are often privy to large amounts of personal information HTTP clients are often privy to large amounts of personal information
(e.g. the user's name, location, mail address, passwords, encryption (e.g. the user's name, location, mail address, passwords, encryption
keys, etc.), and SHOULD be very careful to prevent unintentional keys, etc.), and SHOULD be very careful to prevent unintentional
leakage of this information via the HTTP protocol to other sources. leakage of this information. We very strongly recommend that a
We very strongly recommend that a convenient interface be provided convenient interface be provided for the user to control
for the user to control dissemination of such information, and that dissemination of such information, and that designers and
designers and implementors be particularly careful in this area. implementors be particularly careful in this area. History shows
History shows that errors in this area often create serious security that errors in this area often create serious security and/or privacy
and/or privacy problems and generate highly adverse publicity for the problems and generate highly adverse publicity for the implementor's
implementor's company. company.
10.2. Abuse of Server Log Information 10.2. Abuse of Server Log Information
A server is in the position to save personal data about a user's A server is in the position to save personal data about a user's
requests which might identify their reading patterns or subjects of requests which might identify their reading patterns or subjects of
interest. This information is clearly confidential in nature and its interest. This information is clearly confidential in nature and its
handling can be constrained by law in certain countries. People handling can be constrained by law in certain countries. People
using the HTTP protocol to provide data are responsible for ensuring using HTTP to provide data are responsible for ensuring that such
that such material is not distributed without the permission of any material is not distributed without the permission of any individuals
individuals that are identifiable by the published results. that are identifiable by the published results.
10.3. Attacks Based On File and Path Names 10.3. Attacks Based On File and Path Names
Implementations of HTTP origin servers SHOULD be careful to restrict Implementations of HTTP origin servers SHOULD be careful to restrict
the documents returned by HTTP requests to be only those that were the documents returned by HTTP requests to be only those that were
intended by the server administrators. If an HTTP server translates intended by the server administrators. If an HTTP server translates
HTTP URIs directly into file system calls, the server MUST take HTTP URIs directly into file system calls, the server MUST take
special care not to serve files that were not intended to be special care not to serve files that were not intended to be
delivered to HTTP clients. For example, UNIX, Microsoft Windows, and delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
other operating systems use ".." as a path component to indicate a other operating systems use ".." as a path component to indicate a
skipping to change at page 49, line 14 skipping to change at page 50, line 34
11. Acknowledgments 11. Acknowledgments
This specification makes heavy use of the augmented BNF and generic This specification makes heavy use of the augmented BNF and generic
constructs defined by David H. Crocker for [RFC822ABNF]. Similarly, constructs defined by David H. Crocker for [RFC822ABNF]. Similarly,
it reuses many of the definitions provided by Nathaniel Borenstein it reuses many of the definitions provided by Nathaniel Borenstein
and Ned Freed for MIME [RFC2045]. We hope that their inclusion in and Ned Freed for MIME [RFC2045]. We hope that their inclusion in
this specification will help reduce past confusion over the this specification will help reduce past confusion over the
relationship between HTTP and Internet mail message formats. relationship between HTTP and Internet mail message formats.
The HTTP protocol has evolved considerably over the years. It has HTTP has evolved considerably over the years. It has benefited from
benefited from a large and active developer community--the many a large and active developer community--the many people who have
people who have participated on the www-talk mailing list--and it is participated on the www-talk mailing list--and it is that community
that community which has been most responsible for the success of which has been most responsible for the success of HTTP and of the
HTTP and of the World-Wide Web in general. Marc Andreessen, Robert World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel
Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
VanHeyningen deserve special recognition for their efforts in recognition for their efforts in defining early aspects of the
defining early aspects of the protocol. protocol.
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the HTTP-WG. In addition to those already participating in the HTTP-WG. In addition to those already
mentioned, the following individuals have contributed to this mentioned, the following individuals have contributed to this
specification: specification:
Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra,
Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc
Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel
skipping to change at page 50, line 21 skipping to change at page 51, line 43
[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-01 (work in Semantics", draft-ietf-httpbis-p2-semantics-02 (work in
progress), January 2008. progress), February 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-01 and Content Negotiation", draft-ietf-httpbis-p3-payload-02
(work in progress), January 2008. (work in progress), February 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-01 (work Partial Responses", draft-ietf-httpbis-p5-range-02 (work
in progress), January 2008. in progress), February 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-01 (work in progress), draft-ietf-httpbis-p6-cache-02 (work in progress),
January 2008. February 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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[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
skipping to change at page 52, line 47 skipping to change at page 54, line 16
[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.
[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
Registration Procedures", BCP 13, RFC 4288, December 2005.
[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
skipping to change at page 53, line 21 skipping to change at page 54, line 41
(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. Internet Media Types
In addition to defining the HTTP/1.1 protocol, this document serves In addition to defining HTTP/1.1, this document serves as the
as the specification for the Internet media type "message/http" and specification for the Internet media type "message/http" and
"application/http". The following is to be registered with IANA "application/http". The following is to be registered with IANA
[RFC4288]. [RFC4288].
A.1. Internet Media Type message/http A.1. Internet Media Type message/http
The message/http type can be used to enclose a single HTTP request or The message/http type can be used to enclose a single HTTP request or
response message, provided that it obeys the MIME restrictions for response message, provided that it obeys the MIME restrictions for
all "message" types regarding line length and encodings. all "message" types regarding line length and encodings.
Type name: message Type name: message
skipping to change at page 59, line 25 skipping to change at page 60, line 47
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 D.4. Changes from RFC 2616
Clarify that HTTP-Version is case sensitive. (Section 3.1) The CHAR rule does not allow the NUL character anymore (this affects
the comment and quoted-string rules). (Section 2.2)
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.
skipping to change at page 61, line 18 skipping to change at page 62, line 45
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
Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on
GET (and other) requests"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating
to RFC4288"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status
Code and Reason Phrase"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path
not used"
Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Get rid of duplicate BNF rule names ("host" -> "uri-host",
"trailer" -> "trailer-part").
o Avoid underscore character in rule names ("http_URL" -> "http-
URL", "abs_path" -> "path-absolute").
o Add rules for terms imported from URI spec ("absoluteURI",
"authority", "path-absolute", "port", "query", "relativeURI",
"host) -- these will have to be updated when switching over to
RFC3986.
o Synchronize core rules with RFC5234 (this includes a change to
CHAR which now excludes NUL).
o Get rid of prose rules that span multiple lines.
o Get rid of unused rules LOALPHA and UPALPHA.
o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header.
o Add explicit references to BNF syntax and rules imported from
other parts of the specification.
o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
"TEXT".
Index Index
A A
application/http Media Type 54 application/http Media Type 56
C C
cache 8 cache 8
cacheable 9 cacheable 9
client 7 client 7
connection 6 connection 6
Connection header 38 Connection header 39
content negotiation 7 content negotiation 7
Content-Length header 39 Content-Length header 40
D D
Date header 39 Date header 41
downstream 9 downstream 9
E E
entity 7 entity 7
G G
gateway 8 gateway 8
Grammar Grammar
absoluteURI 18
ALPHA 14 ALPHA 14
asctime-date 19 asctime-date 20
attribute 20 attribute 20
authority 18
CHAR 14 CHAR 14
chunk 21 chunk 22
chunk-data 21 chunk-data 22
chunk-ext-name 21 chunk-ext-name 22
chunk-ext-val 21 chunk-ext-val 22
chunk-extension 21 chunk-extension 22
chunk-size 21 chunk-size 22
Chunked-Body 21 Chunked-Body 22
comment 15 comment 15
Connection 38 Connection 39
connection-token 38 connection-token 39
Content-Length 39 Content-Length 40
CR 14 CR 14
CRLF 14 CRLF 14
ctext 15 ctext 15
CTL 14 CTL 14
Date 39 Date 41
date1 19 date1 20
date2 19 date2 20
date3 19 date3 20
DIGIT 14 DIGIT 14
DQUOTE 14 DQUOTE 14
extension-code 30 extension-code 32
extension-method 27 extension-method 29
field-content 23 field-content 25
field-name 23 field-name 25
field-value 23 field-value 25
general-header 26 general-header 28
generic-message 22 generic-message 24
HEX 14 HEX 15
Host 41 Host 42
HTAB 14 HTAB 14
HTTP-date 19 HTTP-date 20
HTTP-message 22 HTTP-message 24
http-URL 18
HTTP-Version 16 HTTP-Version 16
http_URL 17 last-chunk 22
last-chunk 21
LF 14 LF 14
LOALPHA 14
LWS 14 LWS 14
message-body 24 message-body 25
message-header 23 message-header 25
Method 27 Method 29
month 19 month 20
OCTET 14 OCTET 14
parameter 20 parameter 20
protocol-name 45 path-absolute 18
protocol-version 45 port 18
pseudonym 45 product 23
product-version 23
protocol-name 46
protocol-version 46
pseudonym 46
qdtext 15 qdtext 15
query 18
quoted-pair 15 quoted-pair 15
quoted-string 15 quoted-string 15
Reason-Phrase 30 Reason-Phrase 32
received-by 45 received-by 46
received-protocol 45 received-protocol 46
Request 27 relativeURI 18
Request-Line 27 Request 28
Request-URI 27 Request-Line 28
Response 29 Request-URI 29
rfc850-date 19 Response 31
rfc1123-date 19 rfc850-date 20
rfc1123-date 20
separators 15 separators 15
SP 14 SP 14
start-line 22 start-line 24
Status-Code 30 Status-Code 32
Status-Line 30 Status-Line 31
t-codings 41 t-codings 43
TE 41 tchar 15
TE 43
TEXT 14 TEXT 14
time 19 time 20
token 15 token 15
Trailer 42 Trailer 44
trailer 21 trailer-part 22
transfer-coding 19 transfer-coding 20
Transfer-Encoding 43 Transfer-Encoding 44
transfer-extension 19 transfer-extension 20
UPALPHA 14 Upgrade 45
Upgrade 43 uri-host 18
value 20 value 20
Via 45 Via 46
weekday 19 weekday 20
wkday 19 wkday 20
H H
Headers Headers
Connection 38 Connection 39
Content-Length 39 Content-Length 40
Date 39 Date 41
Host 40 Host 42
TE 41 TE 43
Trailer 42 Trailer 44
Transfer-Encoding 43 Transfer-Encoding 44
Upgrade 43 Upgrade 45
Via 44 Via 46
Host header 40 Host header 42
I I
inbound 9 inbound 9
M M
Media Type Media Type
application/http 54 application/http 56
message/http 53 message/http 54
message 6 message 6
message/http Media Type 53 message/http Media Type 54
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
TE header 41 TE header 43
Trailer header 42 Trailer header 44
Transfer-Encoding header 43 Transfer-Encoding header 44
tunnel 8 tunnel 8
U U
Upgrade header 43 Upgrade header 45
upstream 9 upstream 9
user agent 7 user agent 7
V V
variant 7 variant 7
Via header 44 Via header 46
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. 90 change blocks. 
270 lines changed or deleted 396 lines changed or added

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