draft-ietf-httpbis-p1-messaging-04.txt   draft-ietf-httpbis-p1-messaging-05.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: March 2, 2009 J. Mogul Expires: May 20, 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
August 29, 2008 November 16, 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-04 draft-ietf-httpbis-p1-messaging-05
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 March 2, 2009. This Internet-Draft will expire on May 20, 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
"http" and "https" Uniform Resource Identifier (URI) schemes, defines "http" and "https" Uniform Resource Identifier (URI) schemes, defines
the generic message syntax and parsing requirements for HTTP message the generic message syntax and parsing requirements for HTTP message
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://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://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.4. The changes in this draft are summarized in Appendix E.6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Notational Conventions and Generic Grammar . . . . . . . . . . 8
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . . . 8
2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 2.3. ABNF Rules defined in other Parts of the Specification . . 10
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
2.3. ABNF Rules defined in other Parts of the Specification . . 16 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 11
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 12
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1. http URI scheme . . . . . . . . . . . . . . . . . . . 13
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 3.2.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 13
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 14
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 19 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 16
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 17
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 21 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 22 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 24 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 20
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 25 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 23
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24
4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 24
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. The Resource Identified by a Request . . . . . . . . . . . 26
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 30 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. The Resource Identified by a Request . . . . . . . . . . . 31 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 27
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 28
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 32 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 28
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 28
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 33 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 30
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 30
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 34 7.2. Message Transmission Requirements . . . . . . . . . . . . 31
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 35 7.2.1. Persistent Connections and Flow Control . . . . . . . 31
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35 7.2.2. Monitoring Connections for Error Status Messages . . . 31
7.2. Message Transmission Requirements . . . . . . . . . . . . 36 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 32
7.2.1. Persistent Connections and Flow Control . . . . . . . 37
7.2.2. Monitoring Connections for Error Status Messages . . . 37
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 . . . . . . . . . . . . . . . . . . . . . . 39 Connection . . . . . . . . . . . . . . . . . . . . . . 34
8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 40 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 34
8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 40 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 41 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 36
8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.3.1. Clockless Origin Server Operation . . . . . . . . . . 43 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 37
8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 45 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 40
8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Message Header Registration . . . . . . . . . . . . . . . 48 9.1. Message Header Registration . . . . . . . . . . . . . . . 43
9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 49 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 44
9.3. Internet Media Type Registrations . . . . . . . . . . . . 49 9.3. Internet Media Type Registrations . . . . . . . . . . . . 44
9.3.1. Internet Media Type message/http . . . . . . . . . . . 49 9.3.1. Internet Media Type message/http . . . . . . . . . . . 44
9.3.2. Internet Media Type application/http . . . . . . . . . 50 9.3.2. Internet Media Type application/http . . . . . . . . . 45
10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 52 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 47
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 52 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 47
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 52 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47
10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 52 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 53 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 48
10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 54 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 49
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. Normative References . . . . . . . . . . . . . . . . . . . 55 12.1. Normative References . . . . . . . . . . . . . . . . . . . 50
12.2. Informative References . . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . . 51
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 59 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 53
Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 59 Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 54
Appendix C. Compatibility with Previous Versions . . . . . . . . 60 Appendix C. Compatibility with Previous Versions . . . . . . . . 54
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 60 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 55
C.1.1. Changes to Simplify Multi-homed Web Servers and C.1.1. Changes to Simplify Multi-homed Web Servers and
Conserve IP Addresses . . . . . . . . . . . . . . . . 60 Conserve IP Addresses . . . . . . . . . . . . . . . . 55
C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 61 C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 56
C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 62 C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 57
C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 62 C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 57
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Terminology . . . . . . . . . . . . . . . . . . . . . 58
publication) . . . . . . . . . . . . . . . . . . . . 63 Appendix E. Change Log (to be removed by RFC Editor before
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 63 publication) . . . . . . . . . . . . . . . . . . . . 61
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 63 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 64 E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 65 E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 66 E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 63
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 64
Intellectual Property and Copyright Statements . . . . . . . . . . 73 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
Intellectual Property and Copyright Statements . . . . . . . . . . 72
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 request/response protocol that uses extensible semantics and MIME-
systems. HTTP has been in use by the World-Wide Web global like message payloads for flexible interaction with network-based
information initiative since 1990. The first version of HTTP, hypermedia information systems. HTTP relies upon the Uniform
commonly referred to as HTTP/0.9, was a simple protocol for raw data Resource Identifier (URI) standard [RFC3986] to indicate resource
transfer across the Internet with only a single method and no targets for interaction and to identify other resources. Messages
metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol
by allowing messages to be in the format of MIME-like messages,
containing metadata about the data transferred and modifiers on the
request/response semantics. However, HTTP/1.0 did not sufficiently
take into consideration the effects of hierarchical proxies, caching,
the need for persistent connections, or name-based virtual hosts. In
addition, the proliferation of incompletely-implemented applications
calling themselves "HTTP/1.0" necessitated a protocol version change
in order for two communicating applications to determine each other's
true capabilities.
This document is Part 1 of the seven-part specification that defines
the protocol referred to as "HTTP/1.1", obsoleting [RFC2616].
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations and adding only
those new features that will either be safely ignored by an HTTP/1.0
recipient or only sent when communicating with a party advertising
compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1
related to overall network operation, message framing, interaction
with transport protocols, and URI schemes.
This document is currently disorganized in order to minimize the
changes between drafts and enable reviewers to see the smaller errata
changes. The next draft will reorganize the sections to better
reflect the content. In particular, the sections will be organized
according to the typical process of deciding when to use HTTP (URI
schemes), overall network operation, connection management, message
framing, and generic message parsing. The current mess reflects how
widely dispersed these topics and associated requirements had become
in [RFC2616].
1.1. Purpose
Practical information systems require more functionality than simple
retrieval, including search, front-end update, and annotation. HTTP
allows an open-ended set of methods and headers that indicate the
purpose of a request [RFC2324]. It builds on the discipline of
reference provided by the Uniform Resource Identifier (URI)
[RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for
indicating the resource to which a method is to be applied. Messages
are passed in a format similar to that used by Internet mail are passed in a format similar to that used by Internet mail
[RFC2822] as defined by the Multipurpose Internet Mail Extensions [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
(MIME) [RFC2045]. [RFC2045] (see Appendix A of [Part3] for the differences between HTTP
and MIME messages).
HTTP is also used as a generic protocol for communication between HTTP is also designed for use as a generic protocol for translating
user agents and proxies/gateways to other Internet systems, including communication to and from other Internet information systems, such as
those supported by the SMTP [RFC2821], NNTP [RFC3977], FTP [RFC959], USENET news services via NNTP [RFC3977], file services via FTP
Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP [RFC959], Gopher [RFC1436], and WAIS [WAIS]. HTTP proxies and
allows basic hypermedia access to resources available from diverse gateways provide access to alternative information services by
applications. translating their diverse protocols into a hypermedia format that can
be viewed and manipulated by clients in the same way as HTTP
services.
1.2. Requirements This document is Part 1 of the seven-part specification of HTTP,
defining the protocol referred to as "HTTP/1.1" and obsoleting
[RFC2616]. Part 1 defines how clients determine when to use HTTP,
the URI schemes specific to HTTP-based resources, overall network
operation with transport protocol connection management, and HTTP
message framing. Our goal is to define all of the mechanisms
necessary for HTTP message handling that are independent of message
semantics, thereby defining the complete set of requirements for an
HTTP message relay or generic message parser.
1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the MUST or
REQUIRED level and all the SHOULD level requirements for its REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant."
1.3. Terminology 1.2. Overall Operation
This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication.
connection
A transport layer virtual circuit established between two programs
for the purpose of communication.
message
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in Section 4 and
transmitted via the connection.
request
An HTTP request message, as defined in Section 5.
response
An HTTP response message, as defined in Section 6.
resource
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
representations (e.g. multiple languages, data formats, size, and
resolutions) or vary in other ways.
entity
The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, as
described in Section 4 of [Part3].
representation
An entity included with a response that is subject to content
negotiation, as described in Section 5 of [Part3]. There may
exist multiple representations associated with a particular
response status.
content negotiation
The mechanism for selecting the appropriate representation when
servicing a request, as described in Section 5 of [Part3]. The
representation of entities in any response can be negotiated
(including error responses).
variant
A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these
representations is termed a `variant'. Use of the term `variant'
does not necessarily imply that the resource is subject to content
negotiation.
client
A program that establishes connections for the purpose of sending
requests.
user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
server
An application program that accepts connections in order to
service requests by sending back responses. Any given program may
be capable of being both a client and a server; our use of these
terms refers only to the role being performed by the program for a
particular connection, rather than to the program's capabilities
in general. Likewise, any server may act as an origin server,
proxy, gateway, or tunnel, switching behavior based on the nature
of each request.
origin server
The server on which a given resource resides or is to be created.
proxy
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy MUST implement
both the client and server requirements of this specification. A
"transparent proxy" is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification. A "non-transparent proxy" is a proxy that
modifies the request or response in order to provide some added
service to the user agent, such as group annotation services,
media type transformation, protocol reduction, or anonymity
filtering. Except where either transparent or non-transparent
behavior is explicitly stated, the HTTP proxy requirements apply
to both types of proxies.
gateway
A server which acts as an intermediary for some other server.
Unlike a proxy, a gateway receives requests as if it were the
origin server for the requested resource; the requesting client
may not be aware that it is communicating with a gateway.
tunnel
An intermediary program which is acting as a blind relay between
two connections. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when
both ends of the relayed connections are closed.
cache
A program's local store of response messages and the subsystem
that controls its message storage, retrieval, and deletion. A
cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a
cache cannot be used by a server that is acting as a tunnel.
cacheable
A response is cacheable if a cache is allowed to store a copy of
the response message for use in answering subsequent requests.
The rules for determining the cacheability of HTTP responses are
defined in Section 1 of [Part6]. Even if a resource is cacheable,
there may be additional constraints on whether a cache can use the
cached copy for a particular request.
upstream/downstream
Upstream and downstream describe the flow of a message: all
messages flow from upstream to downstream.
inbound/outbound
Inbound and outbound refer to the request and response paths for
messages: "inbound" means "traveling toward the origin server",
and "outbound" means "traveling toward the user agent"
1.4. Overall Operation
HTTP is a request/response protocol. A client sends a request to the HTTP is a request/response protocol. A client sends a request to the
server in the form of a request method, URI, and protocol version, server in the form of a request method, URI, and protocol version,
followed by a MIME-like message containing request modifiers, client followed by a MIME-like message containing request modifiers, client
information, and possible body content over a connection with a information, and possible body content over a connection with a
server. The server responds with a status line, including the server. The server responds with a status line, including the
message's protocol version and a success or error code, followed by a message's protocol version and a success or error code, 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].
skipping to change at page 11, line 34 skipping to change at page 8, line 7
response structures onto the transport data units of the protocol in response structures onto the transport data units of the protocol in
question is outside the scope of this specification. question is outside the scope of this specification.
In HTTP/1.0, most implementations used a new connection for each In HTTP/1.0, most implementations used a new connection for each
request/response exchange. In HTTP/1.1, a connection may be used for request/response exchange. In HTTP/1.1, a connection may be used for
one or more request/response exchanges, although connections may be one or more request/response exchanges, although connections may be
closed for a variety of reasons (see Section 7.1). closed for a variety of reasons (see Section 7.1).
2. Notational Conventions and Generic Grammar 2. Notational Conventions and Generic Grammar
2.1. Augmented BNF 2.1. ABNF Extension: #rule
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) similar to that
used by [RFC822ABNF]. Implementors will need to be familiar with the
notation in order to understand this specification. The augmented
BNF includes the following constructs:
name = definition
The name of a rule is simply the name itself (without any
enclosing "<" and ">") and is separated from its definition by the
equal "=" character. White space is only significant in that
indentation of continuation lines is used to indicate a rule
definition that spans more than one line. Certain basic rules are
in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.
Angle brackets are used within definitions whenever their presence
will facilitate discerning the use of rule names.
"literal"
Quotation marks surround literal text. Unless stated otherwise,
the text is case-insensitive.
rule1 | rule2
Elements separated by a bar ("|") are alternatives, e.g., "yes |
no" will accept yes or no.
(rule1 rule2)
Elements enclosed in parentheses are treated as a single element.
Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
foo elem" and "elem bar elem".
*rule
The character "*" preceding an element indicates repetition. The
full form is "<n>*<m>element" indicating at least <n> and at most
<m> occurrences of element. Default values are 0 and infinity so
that "*(element)" allows any number, including zero; "1*element"
requires at least one; and "1*2element" allows one or two.
[rule]
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".
N rule
Specific repetition: "<n>(element)" is equivalent to
"<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
alphabetic characters.
#rule One extension to the ABNF rules of [RFC5234] is used to improve
readability.
A construct "#" is defined, similar to "*", for defining lists of A construct "#" is defined, similar to "*", for defining lists of
elements. The full form is "<n>#<m>element" indicating at least elements. The full form is "<n>#<m>element" indicating at least <n>
<n> and at most <m> elements, each separated by one or more commas and at most <m> elements, each separated by one or more commas (",")
(",") and OPTIONAL linear white space (LWS). This makes the usual and OPTIONAL linear white space (OWS). This makes the usual form of
form of lists very easy; a rule such as lists very easy; a rule such as
( *OWS element *( *OWS "," *OWS element ))
( *LWS element *( *LWS "," *LWS element ))
can be shown as can be shown as
1#element 1#element
Wherever this construct is used, null elements are allowed, but do Wherever this construct is used, null elements are allowed, but do
not contribute to the count of elements present. That is, not contribute to the count of elements present. That is,
"(element), , (element) " is permitted, but counts as only two "(element), , (element) " is permitted, but counts as only two
elements. Therefore, where at least one element is required, at elements. Therefore, where at least one element is required, at
least one non-null element MUST be present. Default values are 0 least one non-null element MUST be present. Default values are 0 and
and infinity so that "#element" allows any number, including zero; infinity so that "#element" allows any number, including zero;
"1#element" requires at least one; and "1#2element" allows one or "1#element" requires at least one; and "1#2element" allows one or
two. two.
; comment [[abnf.list: At a later point of time, we may want to add an appendix
containing the whole ABNF, with the list rules expanded to strict RFC
A semi-colon, set off some distance to the right of rule text, 5234 notation.]]
starts a comment that continues to the end of line. This is a
simple way of including useful notes in parallel with the
specifications.
implied *LWS
The grammar described by this specification is word-based. Except
where noted otherwise, linear white space (LWS) can be included
between any two adjacent words (token or quoted-string), and
between adjacent words and separators, without changing the
interpretation of a field. At least one delimiter (LWS and/or
separators) MUST exist between any two tokens (for the definition
of "token" below), since they would otherwise be interpreted as a
single token.
2.2. Basic Rules 2.2. Basic Rules
The following rules are used throughout this specification to This specification uses the Augmented Backus-Naur Form (ABNF)
describe basic parsing constructs. The US-ASCII coded character set notation of [RFC5234]. The following core rules are included by
is defined by ANSI X3.4-1986 [USASCII]. reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters),
CHAR (any [USASCII] character, excluding NUL), CR (carriage return),
OCTET = %x00-FF CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
; any 8-bit sequence of data quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
CHAR = %x01-7F (line feed), OCTET (any 8-bit sequence of data), SP (space) and WSP
; any US-ASCII character, excluding NUL (white space).
ALPHA = %x41-5A | %x61-7A
; A-Z | a-z
DIGIT = %x30-39
; any US-ASCII digit "0".."9"
CTL = %x00-1F | %x7F
; (octets 0 - 31) and DEL (127)
CR = %x0D
; US-ASCII CR, carriage return (13)
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 A 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 All linear white space (LWS) in header field-values has the same
semantics as SP. A recipient MAY replace any such linear white space
with a single SP before interpreting the field value or forwarding
the message downstream.
HTTP/1.1 header field values can be folded onto multiple lines if the Historically, HTTP/1.1 header field values allow linear white space
continuation line begins with a space or horizontal tab. All linear folding across multiple lines. However, this specification
white space, including folding, has the same semantics as SP. A deprecates its use; senders MUST NOT produce messages that include
recipient MAY replace any linear white space with a single SP before LWS folding (i.e., use the obs-fold rule), except within the message/
interpreting the field value or forwarding the message downstream. http media type (Section 9.3.1). Receivers SHOULD still parse folded
linear white space.
LWS = [CRLF] 1*( SP | HTAB ) This specification uses three rules to denote the use of linear white
space; BWS ("Bad" White Space), OWS (Optional White Space), and RWS
(Required White Space).
"Bad" white space is allowed by the BNF, but senders SHOULD NOT
produce it in messages. Receivers MUST accept it in incoming
messages.
Required white space is used when at least one linear white space
character is required to separate field tokens. In all such cases, a
single SP character SHOULD be used.
OWS = *( [ obs-fold ] WSP )
; "optional" white space
RWS = 1*( [ obs-fold ] WSP )
; "required" white space
BWS = OWS
; "bad" white space
obs-fold = CRLF
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 = %x20-7E | %x80-FF | LWS TEXT = %x20-7E / %x80-FF / OWS
; any OCTET except CTLs, but including LWS ; any OCTET except CTLs, but including OWS
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.
HEXDIG = "A" | "B" | "C" | "D" | "E" | "F"
| "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 = "(" | ")" | "<" | ">" | "@" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
| "," | ";" | ":" | "\" | DQUOTE / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
| "/" | "[" | "]" | "?" | "=" / DIGIT / ALPHA
| "{" | "}" | SP | HTAB
tchar = "!" | "#" | "$" | "%" | "&" | "'" | "*"
| "+" | "-" | "." | "^" | "_" | "`" | "|" | "~"
| DIGIT | ALPHA
; any CHAR except CTLs or separators
token = 1*tchar 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-text = %x01-09 | quoted-text = %x01-09 /
%x0B-0C | %x0B-0C /
%x0E-FF ; Characters excluding NUL, CR and LF %x0E-FF ; Characters excluding NUL, CR and LF
quoted-pair = "\" quoted-text quoted-pair = "\" quoted-text
2.3. ABNF Rules defined in other Parts of the Specification 2.3. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
request-header = <request-header, defined in [Part2], Section 4> request-header = <request-header, defined in [Part2], Section 4>
response-header = <response-header, defined in [Part2], Section 6> response-header = <response-header, defined in [Part2], Section 6>
skipping to change at page 17, line 36 skipping to change at page 12, line 17
since the publication of [RFC2068], caching proxies MUST, gateways since the publication of [RFC2068], caching proxies MUST, gateways
MAY, and tunnels MUST NOT upgrade the request to the highest version MAY, and tunnels MUST NOT upgrade the request to the highest version
they support. The proxy/gateway's response to that request MUST be they support. The proxy/gateway's response to that request MUST be
in the same major version as the request. in the same major version as the request.
Note: Converting between versions of HTTP may involve modification Note: Converting between versions of HTTP may involve modification
of header fields required or forbidden by the versions involved. of header fields required or forbidden by the versions involved.
3.2. Uniform Resource Identifiers 3.2. Uniform Resource Identifiers
URIs have been known by many names: WWW addresses, Universal Document Uniform Resource Identifiers (URIs) [RFC3986] are used in HTTP to
Identifiers, Universal Resource Identifiers [RFC1630], and finally indicate the target of a request and to identify additional resources
the combination of Uniform Resource Locators (URL) [RFC1738] and related to that resource, the request, or the response. Each
Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource protocol element in HTTP that allows a URI reference will indicate in
Identifiers are simply formatted strings which identify--via name, its ABNF whether the element allows only a URI in absolute form, any
location, or any other characteristic--a resource. relative reference, or some limited subset of the URI-reference
grammar. Unless otherwise indicated, relative URI references are to
be parsed relative to the URI corresponding to the request target
(the base URI).
3.2.1. General Syntax This specification adopts the definitions of "URI-reference",
"absolute-URI", "fragment", "port", "host", "path-abempty", "path-
absolute", "query", and "authority" from [RFC3986]:
URIs in HTTP can be represented in absolute form or relative to some absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
known base URI [RFC1808], depending upon the context of their use. authority = <authority, defined in [RFC3986], Section 3.2>
The two forms are differentiated by the fact that absolute URIs fragment = <fragment, defined in [RFC3986], Section 3.5>
always begin with a scheme name followed by a colon. For definitive path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
information on URL syntax and semantics, see "Uniform Resource path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which port = <port, defined in [RFC3986], Section 3.2.3>
replaces [RFC1738] and [RFC1808]). This specification adopts the query = <query, defined in [RFC3986], Section 3.4>
definitions of "URI-reference", "absoluteURI", "fragment", uri-host = <host, defined in [RFC3986], Section 3.2.2>
"relativeURI", "port", "host", "abs_path", "query", and "authority"
from that specification:
absoluteURI = <absoluteURI, defined in [RFC2396], Section 3> relative-part = <relative-part, defined in [RFC3986], Section 4.2>
authority = <authority, defined in [RFC2396], Section 3.2> relativeURI = relative-part [ "?" query ]
fragment = <fragment, defined in [RFC2396], Section 4.1>
path-absolute = <abs_path, defined in [RFC2396], Section 3>
port = <port, defined in [RFC2396], Section 3.2.2>
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. HTTP does not place an a priori limit on the length of a URI.
Servers MUST be able to handle the URI of any resource they serve, 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 and SHOULD be able to handle URIs of unbounded length if they provide
GET-based forms that could generate such URIs. A server SHOULD 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 return 414 (Request-URI Too Long) status if a URI is longer than the
server can handle (see Section 9.4.15 of [Part2]). 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.1. http URI scheme
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 syntax and semantics for
semantics for http URLs. identifiers using the http or https URI schemes.
http-URL = "http:" "//" uri-host [ ":" port ] http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ 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 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]. Note: the "https" scheme is defined in [RFC2818].
3.2.3. URI Comparison 3.2.2. 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], Characters other than those in the "reserved" set (see [RFC3986],
Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" 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
skipping to change at page 20, line 14 skipping to change at page 14, line 40
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 = s-Mon | s-Tue | s-Wed wkday = s-Mon / s-Tue / s-Wed
| s-Thu | s-Fri | s-Sat | s-Sun / s-Thu / s-Fri / s-Sat / s-Sun
weekday = l-Mon | l-Tue | l-Wed weekday = l-Mon / l-Tue / l-Wed
| l-Thu | l-Fri | l-Sat | l-Sun / l-Thu / l-Fri / l-Sat / l-Sun
month = s-Jan | s-Feb | s-Mar | s-Apr month = s-Jan / s-Feb / s-Mar / s-Apr
| s-May | s-Jun | s-Jul | s-Aug / s-May / s-Jun / s-Jul / s-Aug
| s-Sep | s-Oct | s-Nov | s-Dec / s-Sep / s-Oct / s-Nov / s-Dec
GMT = %x47.4D.54 ; "GMT", case-sensitive GMT = %x47.4D.54 ; "GMT", case-sensitive
s-Mon = %x4D.6F.6E ; "Mon", case-sensitive s-Mon = %x4D.6F.6E ; "Mon", case-sensitive
s-Tue = %x54.75.65 ; "Tue", case-sensitive s-Tue = %x54.75.65 ; "Tue", case-sensitive
s-Wed = %x57.65.64 ; "Wed", case-sensitive s-Wed = %x57.65.64 ; "Wed", case-sensitive
s-Thu = %x54.68.75 ; "Thu", case-sensitive s-Thu = %x54.68.75 ; "Thu", case-sensitive
s-Fri = %x46.72.69 ; "Fri", case-sensitive s-Fri = %x46.72.69 ; "Fri", case-sensitive
s-Sat = %x53.61.74 ; "Sat", case-sensitive s-Sat = %x53.61.74 ; "Sat", case-sensitive
s-Sun = %x53.75.6E ; "Sun", case-sensitive s-Sun = %x53.75.6E ; "Sun", case-sensitive
skipping to change at page 21, line 30 skipping to change at page 16, line 13
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
entity-body in order to ensure "safe transport" through the network. entity-body in order to ensure "safe transport" through the network.
This differs from a content coding in that the transfer-coding is a This differs from a content coding in that the transfer-coding is a
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 *( OWS ";" OWS parameter )
Parameters are in the form of attribute/value pairs. Parameters are in the form of attribute/value pairs.
parameter = attribute "=" value parameter = attribute BWS "=" BWS 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 indicates transfer-codings MUST include "chunked", unless the message indicates
it is terminated by closing the connection. When the "chunked" it is terminated by closing the connection. When the "chunked"
transfer-coding is used, it MUST be the last transfer-coding applied transfer-coding is used, it MUST be the last transfer-coding applied
to the message-body. The "chunked" transfer-coding MUST NOT be to the message-body. The "chunked" transfer-coding MUST NOT be
skipping to change at page 22, line 40 skipping to change at page 17, line 21
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-part trailer-part
CRLF CRLF
chunk = chunk-size [ chunk-extension ] CRLF chunk = chunk-size *WSP [ chunk-ext ] CRLF
chunk-data CRLF chunk-data CRLF
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
last-chunk = 1*("0") [ chunk-extension ] CRLF last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext = *( ";" *WSP chunk-ext-name
[ "=" chunk-ext-val ] *WSP )
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
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
skipping to change at page 23, line 38 skipping to change at page 18, line 22
This requirement prevents an interoperability failure when the This requirement prevents an interoperability failure when the
message is being received by an HTTP/1.1 (or later) proxy and message is being received by an HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 recipient. It avoids a situation where forwarded to an HTTP/1.0 recipient. It avoids a situation where
compliance with the protocol would have necessitated a possibly compliance with the protocol would have necessitated a possibly
infinite buffer on the proxy. infinite buffer on the proxy.
A process for decoding the "chunked" transfer-coding can be A process for decoding the "chunked" transfer-coding can be
represented in pseudo-code as: represented in pseudo-code as:
length := 0 length := 0
read chunk-size, chunk-extension (if any) and CRLF read chunk-size, chunk-ext (if any) and CRLF
while (chunk-size > 0) { while (chunk-size > 0) {
read chunk-data and CRLF read chunk-data and CRLF
append chunk-data to entity-body append chunk-data to entity-body
length := length + chunk-size length := length + chunk-size
read chunk-size and CRLF read chunk-size and CRLF
} }
read entity-header read entity-header
while (entity-header not empty) { while (entity-header not empty) {
append entity-header to existing header fields append entity-header to existing header fields
read entity-header read entity-header
skipping to change at page 24, line 4 skipping to change at page 18, line 36
length := length + chunk-size length := length + chunk-size
read chunk-size and CRLF read chunk-size and CRLF
} }
read entity-header read entity-header
while (entity-header not empty) { while (entity-header not empty) {
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-ext extensions they
they do not understand. do not understand.
3.5. Product Tokens 3.5. Product Tokens
Product tokens are used to allow communicating applications to Product tokens are used to allow communicating applications to
identify themselves by software name and version. Most fields using identify themselves by software name and version. Most fields using
product tokens also allow sub-products which form a significant part product tokens also allow sub-products which form a significant part
of the application to be listed, separated by white space. By of the application to be listed, separated by white space. By
convention, the products are listed in order of their significance convention, the products are listed in order of their significance
for identifying the application. for identifying the application.
skipping to change at page 24, line 39 skipping to change at page 19, line 23
versions of the same product SHOULD only differ in the product- versions of the same product SHOULD only differ in the product-
version portion of the product value). 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
message format of [RFC2822] for transferring entities (the payload of message format of [RFC5322] for transferring entities (the payload of
the message). Both types of message consist of a start-line, zero or the message). Both types of message consist of a start-line, zero or
more header fields (also known as "headers"), an empty line (i.e., a more header fields (also known as "headers"), an empty line (i.e., a
line with nothing preceding the CRLF) indicating the end of the line with nothing preceding the CRLF) indicating the end of the
header fields, and possibly a message-body. header fields, and possibly a message-body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body ] [ message-body ]
start-line = Request-Line | Status-Line start-line = Request-Line / Status-Line
In the interest of robustness, servers SHOULD ignore any empty In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, line(s) received where a Request-Line is expected. In other words,
if the server is reading the protocol stream at the beginning of a if the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF. message and receives a CRLF first, it should ignore the CRLF.
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 4.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 [RFC5322].
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 / OWS )
field-content = <field content> field-content = <field content>
; the OCTETs making up the field-value
; and consisting of either *TEXT or combinations [[anchor1: whitespace between field-name and colon is an error and
; of token, separators, and quoted-string MUST NOT be accepted]]
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 26, line 37 skipping to change at page 21, line 21
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>
Transfer-Encoding MUST be used to indicate any transfer-codings Transfer-Encoding MUST be used to indicate any transfer-codings
applied by an application to ensure safe and proper transfer of the applied by an application to ensure safe and proper transfer of the
message. Transfer-Encoding is a property of the message, not of the message. Transfer-Encoding is a property of the message, not of the
entity, and thus MAY be added or removed by any application along the entity, and thus MAY be added or removed by any application along the
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.
skipping to change at page 29, line 6 skipping to change at page 23, line 34
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 16.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 16.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 16.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 4.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 30, line 11 skipping to change at page 24, line 40
identified by the Request-URI. The method is case-sensitive. identified by the Request-URI. The method is case-sensitive.
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 / absolute-URI
| ( path-absolute [ "?" 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
The absoluteURI form is REQUIRED when the request is being made to a The absolute-URI form is REQUIRED when the request is being made to a
proxy. The proxy is requested to forward the request or service it proxy. The proxy is requested to forward the request or service it
from a valid cache, and return the response. Note that the proxy MAY from a valid cache, and return the response. Note that the proxy MAY
forward the request on to another proxy or directly to the server forward the request on to another proxy or directly to the server
specified by the absoluteURI. In order to avoid request loops, a specified by the absolute-URI. In order to avoid request loops, a
proxy MUST be able to recognize all of its server names, including proxy MUST be able to recognize all of its server names, including
any aliases, local variations, and the numeric IP address. An any aliases, local variations, and the numeric IP address. An
example Request-Line would be: example Request-Line would be:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future To allow for transition to absolute-URIs 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 absolute-URI
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, 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
skipping to change at page 31, line 4 skipping to change at page 25, line 33
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 "% HEXDIG Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG
HEXDIG" encoding ([RFC2396], Section 2.4.1), the origin server MUST HEXDIG" encoding ([RFC3986], Section 2.4), the origin server MUST
decode the Request-URI in order to properly interpret the request. decode the Request-URI in order to properly interpret the request.
Servers SHOULD respond to invalid Request-URIs with an appropriate Servers SHOULD respond to invalid Request-URIs with an appropriate
status code. 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
skipping to change at page 31, line 40 skipping to change at page 26, line 22
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 C.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 absolute-URI, 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.
2. If the Request-URI is not an absoluteURI, and the request 2. If the Request-URI is not an absolute-URI, and the request
includes a Host header field, the host is determined by the Host includes a Host header field, the host is determined by the Host
header field value. header field value.
3. If the host as determined by rule 1 or 2 is not a valid host on 3. If the host as determined by rule 1 or 2 is not a valid host on
the server, the response MUST be a 400 (Bad Request) error the server, the response MUST be a 400 (Bad Request) error
message. message.
Recipients of an HTTP/1.0 request that lacks a Host header field MAY Recipients of an HTTP/1.0 request that lacks a Host header field MAY
attempt to use heuristics (e.g., examination of the URI path for attempt to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to determine what something unique to a particular host) in order to determine what
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 4.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.
skipping to change at page 40, line 25 skipping to change at page 35, line 9
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to message framing and transport protocols. fields related to message framing and transport protocols.
For entity-header fields, both sender and recipient refer to either For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the the client or the server, depending on who sends and who receives the
entity. entity.
8.1. Connection 8.1. Connection
The Connection general-header field allows the sender to specify The general-header field "Connection" allows the sender to specify
options that are desired for that particular connection and MUST NOT options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections. be communicated by proxies over further connections.
The Connection header has the following grammar: The Connection header's value has the following grammar:
Connection = "Connection" ":" 1#(connection-token) Connection = "Connection" ":" OWS Connection-v
Connection-v = 1#connection-token
connection-token = token connection-token = token
HTTP/1.1 proxies MUST parse the Connection header field before a HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token in this field, message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the remove any header field(s) from the message with the same name as the
connection-token. Connection options are signaled by the presence of connection-token. Connection options are signaled by the presence of
a connection-token in the Connection header field, not by any a connection-token in the Connection header field, not by any
corresponding additional header field(s), since the additional header corresponding additional header field(s), since the additional header
field may not be sent if there are no parameters associated with that field may not be sent if there are no parameters associated with that
connection option. connection option.
skipping to change at page 41, line 24 skipping to change at page 36, line 9
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 C.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 entity-header field "Content-Length" 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" ":" OWS 1*Content-Length-v
Content-Length-v = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
Applications SHOULD use this field to indicate the transfer-length of Applications SHOULD use this field to indicate the transfer-length of
the message-body, unless this is prohibited by the rules in the message-body, unless this is prohibited by the rules in
Section 4.4. Section 4.4.
Any Content-Length greater than or equal to zero is a valid value. Any Content-Length greater than or equal to zero is a valid value.
skipping to change at page 42, line 7 skipping to change at page 36, line 38
Note that the meaning of this field is significantly different from Note that the meaning of this field is significantly different from
the corresponding definition in MIME, where it is an optional field the corresponding definition in MIME, where it is an optional field
used within the "message/external-body" content-type. In HTTP, it used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined prior SHOULD be sent whenever the message's length can be determined prior
to being transferred, unless this is prohibited by the rules in to being transferred, unless this is prohibited by the rules in
Section 4.4. Section 4.4.
8.3. Date 8.3. Date
The Date general-header field represents the date and time at which The general-header field "Date" represents the date and time at which
the message was originated, having the same semantics as orig-date in the message was originated, having the same semantics as orig-date in
Section 3.6.1 of [RFC2822]. The field value is an HTTP-date, as Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as
described in Section 3.3.1; it MUST be sent in rfc1123-date format. described in Section 3.3.1; it MUST be sent in rfc1123-date format.
Date = "Date" ":" HTTP-date Date = "Date" ":" OWS Date-v
Date-v = HTTP-date
An example is An example is
Date: Tue, 15 Nov 1994 08:12:31 GMT Date: Tue, 15 Nov 1994 08:12:31 GMT
Origin servers MUST include a Date header field in all responses, Origin servers MUST include a Date header field in all responses,
except in these cases: except in these cases:
1. If the response status code is 100 (Continue) or 101 (Switching 1. If the response status code is 100 (Continue) or 101 (Switching
Protocols), the response MAY include a Date header field, at the Protocols), the response MAY include a Date header field, at the
skipping to change at page 43, line 21 skipping to change at page 38, line 7
An origin server without a clock MUST NOT assign Expires or Last- An origin server without a clock MUST NOT assign Expires or Last-
Modified values to a response, unless these values were associated Modified values to a response, unless these values were associated
with the resource by a system or user with a reliable clock. It MAY with the resource by a system or user with a reliable clock. It MAY
assign an Expires value that is known, at or before server assign an Expires value that is known, at or before server
configuration time, to be in the past (this allows "pre-expiration" configuration time, to be in the past (this allows "pre-expiration"
of responses without storing separate Expires values for each of responses without storing separate Expires values for each
resource). resource).
8.4. Host 8.4. Host
The Host request-header field specifies the Internet host and port The request-header field "Host" 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.1). 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" ":" uri-host [ ":" port ] ; Section 3.2.2 Host = "Host" ":" OWS Host-v
Host-v = uri-host [ ":" port ] ; Section 3.2.1
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 44, line 7 skipping to change at page 38, line 41
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 C.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 request-header field "TE" indicates what extension transfer-
it is willing to accept in the response and whether or not it is codings it is willing to accept in the response and whether or not it
willing to accept trailer fields in a chunked transfer-coding. Its is willing to accept trailer fields in a chunked transfer-coding.
value may consist of the keyword "trailers" and/or a comma-separated Its value may consist of the keyword "trailers" and/or a comma-
list of extension transfer-coding names with optional accept separated list of extension transfer-coding names with optional
parameters (as described in Section 3.4). accept parameters (as described in Section 3.4).
TE = "TE" ":" #( t-codings ) TE = "TE" ":" OWS TE-v
t-codings = "trailers" | ( transfer-extension [ accept-params ] ) TE-v = #t-codings
t-codings = "trailers" / ( transfer-extension [ accept-params ] )
The presence of the keyword "trailers" indicates that the client is The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer-coding, as willing to accept trailer fields in a chunked transfer-coding, as
defined in Section 3.4.1. This keyword is reserved for use with defined in Section 3.4.1. This keyword is reserved for use with
transfer-coding values even though it does not itself represent a transfer-coding values even though it does not itself represent a
transfer-coding. transfer-coding.
Examples of its use are: Examples of its use are:
TE: deflate TE: deflate
skipping to change at page 45, line 14 skipping to change at page 39, line 50
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.
8.6. Trailer 8.6. Trailer
The Trailer general field value indicates that the given set of The general field "Trailer" indicates that the given set of header
header fields is present in the trailer of a message encoded with fields is present in the trailer of a message encoded with chunked
chunked transfer-coding. transfer-coding.
Trailer = "Trailer" ":" 1#field-name Trailer = "Trailer" ":" OWS Trailer-v
Trailer-v = 1#field-name
An HTTP/1.1 message SHOULD include a Trailer header field in a An HTTP/1.1 message SHOULD include a Trailer header field in a
message using chunked transfer-coding with a non-empty trailer. message using chunked transfer-coding with a non-empty trailer.
Doing so allows the recipient to know which header fields to expect Doing so allows the recipient to know which header fields to expect
in the trailer. in the trailer.
If no Trailer header field is present, the trailer SHOULD NOT include If no Trailer header field is present, the trailer SHOULD NOT include
any header fields. See Section 3.4.1 for restrictions on the use of any header fields. See Section 3.4.1 for restrictions on the use of
trailer fields in a "chunked" transfer-coding. trailer fields in a "chunked" transfer-coding.
skipping to change at page 45, line 40 skipping to change at page 40, line 29
include the following header fields: include the following header fields:
o Transfer-Encoding o Transfer-Encoding
o Content-Length o Content-Length
o Trailer o Trailer
8.7. Transfer-Encoding 8.7. Transfer-Encoding
The Transfer-Encoding general-header field indicates what (if any) The general-header "Transfer-Encoding" field indicates what (if any)
type of transformation has been applied to the message body in order type of transformation has been applied to the message body in order
to safely transfer it between the sender and the recipient. This to safely transfer it between the sender and the recipient. This
differs from the content-coding in that the transfer-coding is a differs from the content-coding in that the transfer-coding is a
property of the message, not of the entity. property of the message, not of the entity.
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding Transfer-Encoding = "Transfer-Encoding" ":" OWS
Transfer-Encoding-v
Transfer-Encoding-v = 1#transfer-coding
Transfer-codings are defined in Section 3.4. An example is: Transfer-codings are defined in Section 3.4. An example is:
Transfer-Encoding: chunked Transfer-Encoding: chunked
If multiple encodings have been applied to an entity, the transfer- If multiple encodings have been applied to an entity, the transfer-
codings MUST be listed in the order in which they were applied. codings MUST be listed in the order in which they were applied.
Additional information about the encoding parameters MAY be provided Additional information about the encoding parameters MAY be provided
by other entity-header fields not defined by this specification. by other entity-header fields not defined by this specification.
Many older HTTP/1.0 applications do not understand the Transfer- Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header. Encoding header.
8.8. Upgrade 8.8. Upgrade
skipping to change at page 46, line 14 skipping to change at page 41, line 7
If multiple encodings have been applied to an entity, the transfer- If multiple encodings have been applied to an entity, the transfer-
codings MUST be listed in the order in which they were applied. codings MUST be listed in the order in which they were applied.
Additional information about the encoding parameters MAY be provided Additional information about the encoding parameters MAY be provided
by other entity-header fields not defined by this specification. by other entity-header fields not defined by this specification.
Many older HTTP/1.0 applications do not understand the Transfer- Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header. Encoding header.
8.8. Upgrade 8.8. Upgrade
The Upgrade general-header allows the client to specify what The general-header "Upgrade" allows the client to specify what
additional communication protocols it supports and would like to use additional communication protocols it supports and would like to use
if the server finds it appropriate to switch protocols. The server if the server finds it appropriate to switch protocols. The server
MUST use the Upgrade header field within a 101 (Switching Protocols) MUST use the Upgrade header field within a 101 (Switching Protocols)
response to indicate which protocol(s) are being switched. response to indicate which protocol(s) are being switched.
Upgrade = "Upgrade" ":" 1#product Upgrade = "Upgrade" ":" OWS Upgrade-v
Upgrade-v = 1#product
For example, For example,
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol. for transition from HTTP/1.1 to some other, incompatible protocol.
It does so by allowing the client to advertise its desire to use It does so by allowing the client to advertise its desire to use
another protocol, such as a later version of HTTP with a higher major another protocol, such as a later version of HTTP with a higher major
version number, even though the current request has been made using version number, even though the current request has been made using
skipping to change at page 47, line 18 skipping to change at page 42, line 10
This specification only defines the protocol name "HTTP" for use by This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 3.1 and future updates to this version rules of Section 3.1 and future updates to this
specification. Any token can be used as a protocol name; however, it specification. Any token can be used as a protocol name; however, it
will only be useful if both the client and server associate the name will only be useful if both the client and server associate the name
with the same protocol. with the same protocol.
8.9. Via 8.9. Via
The Via general-header field MUST be used by gateways and proxies to The general-header field "Via" MUST be used by gateways and proxies
indicate the intermediate protocols and recipients between the user to indicate the intermediate protocols and recipients between the
agent and the server on requests, and between the origin server and user agent and the server on requests, and between the origin server
the client on responses. It is analogous to the "Received" field and the client on responses. It is analogous to the "Received" field
defined in Section 3.6.7 of [RFC2822] and is intended to be used for defined in Section 3.6.7 of [RFC5322] and is intended to be used for
tracking message forwards, avoiding request loops, and identifying tracking message forwards, avoiding request loops, and identifying
the protocol capabilities of all senders along the request/response the protocol capabilities of all senders along the request/response
chain. chain.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) Via = "Via" ":" OWS Via-v
Via-v = 1#( received-protocol RWS received-by
[ RWS 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 = ( uri-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 49, line 26 skipping to change at page 44, line 26
| 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 9.2. URI Scheme Registration
The entry for the "http" URI Scheme in the registry located at The entry for the "http" URI Scheme in the registry located at
<http://www.iana.org/assignments/uri-schemes.html> should be updated <http://www.iana.org/assignments/uri-schemes.html> should be updated
to point to Section 3.2.2 of this document (see [RFC4395]). to point to Section 3.2.1 of this document (see [RFC4395]).
9.3. Internet Media Type Registrations 9.3. Internet Media Type Registrations
This document serves as the specification for the Internet media This document serves as the specification for the Internet media
types "message/http" and "application/http". The following is to be types "message/http" and "application/http". The following is to be
registered with IANA (see [RFC4288]). registered with IANA (see [RFC4288]).
9.3.1. Internet Media Type message/http 9.3.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
skipping to change at page 54, line 21 skipping to change at page 49, line 21
protect against a broad range of security and privacy attacks. Such protect against a broad range of security and privacy attacks. Such
cryptography is beyond the scope of the HTTP/1.1 specification. cryptography is beyond the scope of the HTTP/1.1 specification.
10.6. Denial of Service Attacks on Proxies 10.6. Denial of Service Attacks on Proxies
They exist. They are hard to defend against. Research continues. They exist. They are hard to defend against. Research continues.
Beware. Beware.
11. Acknowledgments 11. Acknowledgments
This specification makes heavy use of the augmented BNF and generic
constructs defined by David H. Crocker for [RFC822ABNF]. Similarly,
it reuses many of the definitions provided by Nathaniel Borenstein
and Ned Freed for MIME [RFC2045]. We hope that their inclusion in
this specification will help reduce past confusion over the
relationship between HTTP and Internet mail message formats.
HTTP has evolved considerably over the years. It has benefited from HTTP has evolved considerably over the years. It has benefited from
a large and active developer community--the many people who have a large and active developer community--the many people who have
participated on the www-talk mailing list--and it is that community participated on the www-talk mailing list--and it is that community
which has been most responsible for the success of HTTP and of the which has been most responsible for the success of HTTP and of the
World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel
W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
recognition for their efforts in defining early aspects of the recognition for their efforts in defining early aspects of the
protocol. protocol.
skipping to change at page 55, line 24 skipping to change at page 50, line 17
Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
help. And thanks go particularly to Jeff Mogul and Scott Lawrence help. And thanks go particularly to Jeff Mogul and Scott Lawrence
for performing the "MUST/MAY/SHOULD" audit. for performing the "MUST/MAY/SHOULD" audit.
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
Frystyk implemented RFC 2068 early, and we wish to thank them for the Frystyk implemented RFC 2068 early, and we wish to thank them for the
discovery of many of the problems that this document attempts to discovery of many of the problems that this document attempts to
rectify. rectify.
This specification makes heavy use of the augmented BNF and generic
constructs defined by David H. Crocker for [RFC5234]. Similarly, it
reuses many of the definitions provided by Nathaniel Borenstein and
Ned Freed for MIME [RFC2045]. We hope that their inclusion in this
specification will help reduce past confusion over the relationship
between HTTP and Internet mail message formats.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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-04 (work in Semantics", draft-ietf-httpbis-p2-semantics-05 (work in
progress), August 2008. progress), November 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-04 and Content Negotiation", draft-ietf-httpbis-p3-payload-05
(work in progress), August 2008. (work in progress), November 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-04 (work Partial Responses", draft-ietf-httpbis-p5-range-05 (work
in progress), August 2008. in progress), November 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-04 (work in progress), draft-ietf-httpbis-p6-cache-05 (work in progress),
August 2008. November 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 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifier (URI): Generic Syntax", RFC 3986,
August 1998. STD 66, January 2005.
[RFC822ABNF] [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Crocker, D., "Standard for the format of ARPA Internet Specifications: ABNF", STD 68, RFC 5234, January 2008.
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 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. 1, Politics", ACM Transactions on Internet Technology Vol. 1,
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
skipping to change at page 57, line 16 skipping to change at page 52, line 14
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)",
RFC 1436, March 1993. RFC 1436, March 1993.
[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses
of Objects on the Network as used in the World-Wide Web",
RFC 1630, June 1994.
[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1808] Fielding, R., "Relative Uniform Resource Locators",
RFC 1808, June 1995.
[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 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997. 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
(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. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. 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 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006. RFC 4395, February 2006.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008.
[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 60, line 9 skipping to change at page 54, line 35
Appendix B. 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 C. Compatibility with Previous Versions Appendix C. Compatibility with Previous Versions
HTTP has been in use by the World-Wide Web global information
initiative since 1990. The first version of HTTP, later referred to
as HTTP/0.9, was a simple protocol for hypertext data transfer across
the Internet with only a single method and no metadata. HTTP/1.0, as
defined by [RFC1945], added a range of request methods and MIME-like
messaging that could include metadata about the data transferred and
modifiers on the request/response semantics. However, HTTP/1.0 did
not sufficiently take into consideration the effects of hierarchical
proxies, caching, the need for persistent connections, or name-based
virtual hosts. The proliferation of incompletely-implemented
applications calling themselves "HTTP/1.0" further necessitated a
protocol version change in order for two communicating applications
to determine each other's true capabilities.
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations, adding only those
new features that will either be safely ignored by an HTTP/1.0
recipient or only sent when communicating with a party advertising
compliance with HTTP/1.1.
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;
o understand any valid request in the format of HTTP/0.9, 1.0, or o understand any valid request in the format of HTTP/0.9, 1.0, or
skipping to change at page 62, line 38 skipping to change at page 57, line 38
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)
C.4. Changes from RFC 2616 C.4. Changes from RFC 2616
The CHAR rule does not allow the NUL character anymore (this affects Rules about implicit linear white space between certain grammar
the comment and quoted-string rules). Furthermore, the quoted-pair productions have been removed; now it's only allowed when
rule does not allow escaping NUL, CR or LF anymore. (Section 2.2) specifically pointed out in the ABNF. The CHAR rule does not allow
the NUL character anymore (this affects the comment and quoted-string
rules). Furthermore, the quoted-pair 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)
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)
Update use of abs_path production from RFC1808 to the path-absolute +
query components of RFC3986. (Section 5.1.2)
Fix BNF to add query, as the abs_path production in Section 3 of
[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 D. Change Log (to be removed by RFC Editor before publication) Appendix D. Terminology
D.1. Since RFC2616 This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication.
connection
A transport layer virtual circuit established between two programs
for the purpose of communication.
message
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in Section 4 and
transmitted via the connection.
request
An HTTP request message, as defined in Section 5.
response
An HTTP response message, as defined in Section 6.
resource
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
representations (e.g. multiple languages, data formats, size, and
resolutions) or vary in other ways.
entity
The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, as
described in Section 4 of [Part3].
representation
An entity included with a response that is subject to content
negotiation, as described in Section 5 of [Part3]. There may
exist multiple representations associated with a particular
response status.
content negotiation
The mechanism for selecting the appropriate representation when
servicing a request, as described in Section 5 of [Part3]. The
representation of entities in any response can be negotiated
(including error responses).
variant
A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these
representations is termed a `variant'. Use of the term `variant'
does not necessarily imply that the resource is subject to content
negotiation.
client
A program that establishes connections for the purpose of sending
requests.
user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
server
An application program that accepts connections in order to
service requests by sending back responses. Any given program may
be capable of being both a client and a server; our use of these
terms refers only to the role being performed by the program for a
particular connection, rather than to the program's capabilities
in general. Likewise, any server may act as an origin server,
proxy, gateway, or tunnel, switching behavior based on the nature
of each request.
origin server
The server on which a given resource resides or is to be created.
proxy
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy MUST implement
both the client and server requirements of this specification. A
"transparent proxy" is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification. A "non-transparent proxy" is a proxy that
modifies the request or response in order to provide some added
service to the user agent, such as group annotation services,
media type transformation, protocol reduction, or anonymity
filtering. Except where either transparent or non-transparent
behavior is explicitly stated, the HTTP proxy requirements apply
to both types of proxies.
gateway
A server which acts as an intermediary for some other server.
Unlike a proxy, a gateway receives requests as if it were the
origin server for the requested resource; the requesting client
may not be aware that it is communicating with a gateway.
tunnel
An intermediary program which is acting as a blind relay between
two connections. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when
both ends of the relayed connections are closed.
cache
A program's local store of response messages and the subsystem
that controls its message storage, retrieval, and deletion. A
cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a
cache cannot be used by a server that is acting as a tunnel.
cacheable
A response is cacheable if a cache is allowed to store a copy of
the response message for use in answering subsequent requests.
The rules for determining the cacheability of HTTP responses are
defined in Section 1 of [Part6]. Even if a resource is cacheable,
there may be additional constraints on whether a cache can use the
cached copy for a particular request.
upstream/downstream
Upstream and downstream describe the flow of a message: all
messages flow from upstream to downstream.
inbound/outbound
Inbound and outbound refer to the request and response paths for
messages: "inbound" means "traveling toward the origin server",
and "outbound" means "traveling toward the user agent"
Appendix E. Change Log (to be removed by RFC Editor before publication)
E.1. Since RFC2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
D.2. Since draft-ietf-httpbis-p1-messaging-00 E.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://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
Version should be case sensitive" 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://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>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size o <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
Definition" (<http://purl.org/NET/http-errata#chunk-size>) Definition" (<http://purl.org/NET/http-errata#chunk-size>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message o <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length"
Length" (<http://purl.org/NET/http-errata#msg-len-chars>) (<http://purl.org/NET/http-errata#msg-len-chars>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
Registrations" (<http://purl.org/NET/http-errata#media-reg>) Registrations" (<http://purl.org/NET/http-errata#media-reg>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI o <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes
includes query" (<http://purl.org/NET/http-errata#uriquery>) query" (<http://purl.org/NET/http-errata#uriquery>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close o <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on
on 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>) 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
'identity' token references" 'identity' token references"
(<http://purl.org/NET/http-errata#identity>) (<http://purl.org/NET/http-errata#identity>)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query
BNF"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import o <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF"
query BNF"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
BNF" Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
and Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
Compliance" Compliance"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977 o <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
reference" reference"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
references" references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/47>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency
"inconsistency in date format explanation" in date format explanation"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
reference typo" typo"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
"Informative references" references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
"ISO-8859-1 Reference" Reference"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
up-to-date references" 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://tools.ietf.org/wg/httpbis/trac/ticket/36>)
D.3. Since draft-ietf-httpbis-p1-messaging-01 E.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://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
GET (and other) requests" (and other) requests"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
RFC4288"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
to RFC4288" and Reason Phrase"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
Code and Reason Phrase" used"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path
not used"
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Get rid of duplicate BNF rule names ("host" -> "uri-host", o Get rid of duplicate BNF rule names ("host" -> "uri-host",
"trailer" -> "trailer-part"). "trailer" -> "trailer-part").
o Avoid underscore character in rule names ("http_URL" -> "http- o Avoid underscore character in rule names ("http_URL" -> "http-
URL", "abs_path" -> "path-absolute"). URL", "abs_path" -> "path-absolute").
o Add rules for terms imported from URI spec ("absoluteURI", o Add rules for terms imported from URI spec ("absoluteURI",
"authority", "path-absolute", "port", "query", "relativeURI", "authority", "path-absolute", "port", "query", "relativeURI",
"host) -- these will have to be updated when switching over to "host) -- these will have to be updated when switching over to
skipping to change at page 65, line 34 skipping to change at page 63, line 43
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".
D.4. Since draft-ietf-httpbis-p1-messaging-02 E.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://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
vs. rfc1123-date" rfc1123-date"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in
quoted-pair"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
pair"
Ongoing work on IANA Message Header Registration Ongoing work on IANA Message Header Registration
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
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://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 E.5. Since draft-ietf-httpbis-p1-messaging-03
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/28>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
"Connection closing" closing"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
registrations and registry information to IANA Considerations" registrations and registry information to IANA Considerations"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
URL for PAD1995 reference" for PAD1995 reference"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
Considerations: update HTTP URI scheme registration" Considerations: update HTTP URI scheme registration"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
HTTPS URI scheme definition" URI scheme definition"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/129>: "List- o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type
type headers vs Set-Cookie" headers vs Set-Cookie"
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://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-Date). (HTTP-Date).
o Replace HEX by HEXDIG for future consistence with RFC 5234's core o Replace HEX by HEXDIG for future consistence with RFC 5234's core
rules. rules.
E.6. Since draft-ietf-httpbis-p1-messaging-04
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date
reference for URIs"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
updated by RFC 5322"
Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Use "/" instead of "|" for alternatives.
o Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
o Only reference RFC 5234's core rules.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header
value format definitions.
Index Index
A A
application/http Media Type 50 application/http Media Type 45
C C
cache 8 cache 60
cacheable 9 cacheable 60
client 7 client 59
connection 6 connection 58
Connection header 40 Connection header 35
content negotiation 7 content negotiation 59
Content-Length header 41 Content-Length header 36
D D
Date header 42 Date header 36
downstream 9 downstream 61
E E
entity 7 entity 58
G G
gateway 8 gateway 60
Grammar Grammar
absoluteURI 18 absolute-URI 12
ALPHA 14 asctime-date 14
asctime-date 20 attribute 16
attribute 21 authority 12
authority 18 BWS 9
CHAR 14 chunk 17
chunk 22 chunk-data 17
chunk-data 22 chunk-ext 17
chunk-ext-name 22 chunk-ext-name 17
chunk-ext-val 22 chunk-ext-val 17
chunk-extension 22 chunk-size 17
chunk-size 22 Chunked-Body 17
Chunked-Body 22 comment 10
comment 15 Connection 35
Connection 40 connection-token 35
connection-token 40 Connection-v 35
Content-Length 41 Content-Length 36
CR 14 Content-Length-v 36
CRLF 14 ctext 10
ctext 15 Date 36
CTL 14 Date-v 36
Date 42 date1 14
date1 20 date2 14
date2 20 date3 14
date3 20 extension-code 27
DIGIT 14 extension-method 24
DQUOTE 14 field-content 20
extension-code 33 field-name 20
extension-method 29 field-value 20
field-content 25 general-header 23
field-name 25 generic-message 19
field-value 25 Host 38
general-header 29 Host-v 38
generic-message 25 HTTP-date 14
HEXDIG 15 HTTP-message 19
Host 43 HTTP-Prot-Name 11
HTAB 14 http-URI 13
HTTP-date 20 HTTP-Version 11
HTTP-message 24 last-chunk 17
HTTP-Prot-Name 16 message-body 21
http-URL 18 message-header 20
HTTP-Version 16 Method 24
last-chunk 22 month 14
LF 14 obsolete-date 14
LWS 14 OWS 9
message-body 26 parameter 16
message-header 25 path-absolute 12
Method 29 port 12
month 20 product 18
obsolete-date 20 product-version 18
OCTET 14 protocol-name 42
parameter 21 protocol-version 42
path-absolute 18 pseudonym 42
port 18 qdtext 10
product 24 query 12
product-version 24 quoted-pair 10
protocol-name 47 quoted-string 10
protocol-version 47 quoted-text 10
pseudonym 47 Reason-Phrase 27
qdtext 15 received-by 42
query 18 received-protocol 42
quoted-pair 15 relative-part 12
quoted-string 15 relativeURI 12
quoted-text 15 Request 24
Reason-Phrase 33 Request-Line 24
received-by 47 Request-URI 24
received-protocol 47 Response 26
relativeURI 18 rfc850-date 14
Request 29 rfc1123-date 14
Request-Line 29 RWS 9
Request-URI 30 start-line 19
Response 32 Status-Code 27
rfc850-date 20 Status-Line 27
rfc1123-date 20 t-codings 38
separators 15 tchar 10
SP 14 TE 38
start-line 25 TE-v 38
Status-Code 33 TEXT 9
Status-Line 32 time 14
t-codings 44 token 10
tchar 15 Trailer 40
TE 44 trailer-part 17
TEXT 14 Trailer-v 40
time 20 transfer-coding 16
token 15 Transfer-Encoding 40
Trailer 45 Transfer-Encoding-v 40
trailer-part 22 transfer-extension 16
transfer-coding 21 Upgrade 41
Transfer-Encoding 45 Upgrade-v 41
transfer-extension 21 uri-host 12
Upgrade 46 URI-reference 12
uri-host 18 value 16
value 21 Via 42
Via 47 Via-v 42
weekday 20 weekday 14
wkday 20 wkday 14
H H
Headers Headers
Connection 40 Connection 35
Content-Length 41 Content-Length 36
Date 42 Date 36
Host 43 Host 38
TE 44 TE 38
Trailer 45 Trailer 39
Transfer-Encoding 45 Transfer-Encoding 40
Upgrade 46 Upgrade 41
Via 47 Via 42
Host header 43 Host header 38
http URI scheme 18 http URI scheme 13
https URI scheme 18 https URI scheme 13
I I
implied *LWS 13 inbound 61
inbound 9
M M
Media Type Media Type
application/http 50 application/http 45
message/http 49 message/http 44
message 6 message 58
message/http Media Type 49 message/http Media Type 44
O O
origin server 8 origin server 59
outbound 9 outbound 61
P P
proxy 8 proxy 59
R R
representation 7 representation 58
request 6 request 58
resource 7 resource 58
response 6 response 58
S S
server 8 server 59
T T
TE header 44 TE header 38
Trailer header 45 Trailer header 39
Transfer-Encoding header 45 Transfer-Encoding header 40
tunnel 8 tunnel 60
U U
Upgrade header 46 Upgrade header 41
upstream 9 upstream 61
URI scheme URI scheme
http 18 http 13
https 18 https 13
user agent 7 user agent 59
V V
variant 7 variant 59
Via header 47 Via header 42
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. 172 change blocks. 
805 lines changed or deleted 743 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/