mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-08-19 03:50:53 +00:00
5152 lines
194 KiB
Text
5152 lines
194 KiB
Text
|
||
|
||
|
||
HTTPbis Working Group R. Fielding, Ed.
|
||
Internet-Draft Day Software
|
||
Obsoletes: 2616 (if approved) J. Gettys
|
||
Updates: 2817 (if approved) Alcatel-Lucent
|
||
Intended status: Standards Track J. Mogul
|
||
Expires: February 5, 2011 HP
|
||
H. Frystyk
|
||
Microsoft
|
||
L. Masinter
|
||
Adobe Systems
|
||
P. Leach
|
||
Microsoft
|
||
T. Berners-Lee
|
||
W3C/MIT
|
||
Y. Lafon, Ed.
|
||
W3C
|
||
J. Reschke, Ed.
|
||
greenbytes
|
||
August 4, 2010
|
||
|
||
|
||
HTTP/1.1, part 1: URIs, Connections, and Message Parsing
|
||
draft-ietf-httpbis-p1-messaging-11
|
||
|
||
Abstract
|
||
|
||
The Hypertext Transfer Protocol (HTTP) is an application-level
|
||
protocol for distributed, collaborative, hypertext information
|
||
systems. HTTP has been in use by the World Wide Web global
|
||
information initiative since 1990. This document is Part 1 of the
|
||
seven-part specification that defines the protocol referred to as
|
||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
|
||
an overview of HTTP and its associated terminology, defines the
|
||
"http" and "https" Uniform Resource Identifier (URI) schemes, defines
|
||
the generic message syntax and parsing requirements for HTTP message
|
||
frames, and describes general security concerns for implementations.
|
||
|
||
Editorial Note (To be removed by RFC Editor)
|
||
|
||
Discussion of this draft should take place on the HTTPBIS working
|
||
group mailing list (ietf-http-wg@w3.org). The current issues list is
|
||
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
|
||
documents (including fancy diffs) can be found at
|
||
<http://tools.ietf.org/wg/httpbis/>.
|
||
|
||
The changes in this draft are summarized in Appendix D.12.
|
||
|
||
Status of This Memo
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 1]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
This Internet-Draft is submitted in full conformance with the
|
||
provisions of BCP 78 and BCP 79.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF). Note that other groups may also distribute
|
||
working documents as Internet-Drafts. The list of current Internet-
|
||
Drafts is at http://datatracker.ietf.org/drafts/current/.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
This Internet-Draft will expire on February 5, 2011.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2010 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(http://trustee.ietf.org/license-info) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with respect
|
||
to this document. Code Components extracted from this document must
|
||
include Simplified BSD License text as described in Section 4.e of
|
||
the Trust Legal Provisions and are provided without warranty as
|
||
described in the Simplified BSD License.
|
||
|
||
This document may contain material from IETF Documents or IETF
|
||
Contributions published or made publicly available before November
|
||
10, 2008. The person(s) controlling the copyright in some of this
|
||
material may not have granted the IETF Trust the right to allow
|
||
modifications of such material outside the IETF Standards Process.
|
||
Without obtaining an adequate license from the person(s) controlling
|
||
the copyright in such materials, this document may not be modified
|
||
outside the IETF Standards Process, and derivative works of it may
|
||
not be created outside the IETF Standards Process, except to format
|
||
it for publication as an RFC or to translate it into languages other
|
||
than English.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
|
||
1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 2]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8
|
||
1.2.3. ABNF Rules defined in other Parts of the
|
||
Specification . . . . . . . . . . . . . . . . . . . . 10
|
||
2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10
|
||
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
|
||
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
|
||
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||
2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14
|
||
2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
|
||
2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
|
||
2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
|
||
2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18
|
||
2.6.3. http and https URI Normalization and Comparison . . . 18
|
||
3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
|
||
3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20
|
||
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20
|
||
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22
|
||
3.4. General Header Fields . . . . . . . . . . . . . . . . . . 25
|
||
4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
|
||
4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26
|
||
4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26
|
||
4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27
|
||
4.2. The Resource Identified by a Request . . . . . . . . . . . 29
|
||
4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 29
|
||
5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
|
||
5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31
|
||
5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31
|
||
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32
|
||
6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32
|
||
6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34
|
||
6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35
|
||
6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37
|
||
6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38
|
||
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
|
||
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39
|
||
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39
|
||
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 39
|
||
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40
|
||
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40
|
||
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42
|
||
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44
|
||
7.2. Message Transmission Requirements . . . . . . . . . . . . 45
|
||
7.2.1. Persistent Connections and Flow Control . . . . . . . 45
|
||
7.2.2. Monitoring Connections for Error Status Messages . . . 45
|
||
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46
|
||
7.2.4. Client Behavior if Server Prematurely Closes
|
||
Connection . . . . . . . . . . . . . . . . . . . . . . 48
|
||
8. Miscellaneous notes that might disappear . . . . . . . . . . . 49
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 3]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
8.1. Scheme aliases considered harmful . . . . . . . . . . . . 49
|
||
8.2. Use of HTTP for proxy communication . . . . . . . . . . . 49
|
||
8.3. Interception of HTTP for access control . . . . . . . . . 49
|
||
8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49
|
||
8.5. Use of HTTP by media type specification . . . . . . . . . 49
|
||
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49
|
||
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49
|
||
9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 50
|
||
9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
|
||
9.3.1. Clockless Origin Server Operation . . . . . . . . . . 52
|
||
9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
|
||
9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
|
||
9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54
|
||
9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 55
|
||
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55
|
||
9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56
|
||
9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
|
||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
|
||
10.1. Header Field Registration . . . . . . . . . . . . . . . . 59
|
||
10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59
|
||
10.3. Internet Media Type Registrations . . . . . . . . . . . . 59
|
||
10.3.1. Internet Media Type message/http . . . . . . . . . . . 59
|
||
10.3.2. Internet Media Type application/http . . . . . . . . . 61
|
||
10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62
|
||
10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62
|
||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 62
|
||
11.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
|
||
11.2. Abuse of Server Log Information . . . . . . . . . . . . . 63
|
||
11.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
|
||
11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 63
|
||
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64
|
||
11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
|
||
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
|
||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
|
||
13.1. Normative References . . . . . . . . . . . . . . . . . . . 66
|
||
13.2. Informative References . . . . . . . . . . . . . . . . . . 68
|
||
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70
|
||
Appendix B. Compatibility with Previous Versions . . . . . . . . 71
|
||
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71
|
||
B.1.1. Changes to Simplify Multi-homed Web Servers and
|
||
Conserve IP Addresses . . . . . . . . . . . . . . . . 72
|
||
B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72
|
||
B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73
|
||
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74
|
||
Appendix D. Change Log (to be removed by RFC Editor before
|
||
publication) . . . . . . . . . . . . . . . . . . . . 78
|
||
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78
|
||
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 4]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80
|
||
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81
|
||
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81
|
||
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82
|
||
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82
|
||
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83
|
||
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84
|
||
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84
|
||
D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85
|
||
D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85
|
||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 5]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
1. Introduction
|
||
|
||
The Hypertext Transfer Protocol (HTTP) is an application-level
|
||
request/response protocol that uses extensible semantics and MIME-
|
||
like message payloads for flexible interaction with network-based
|
||
hypertext information systems. HTTP relies upon the Uniform Resource
|
||
Identifier (URI) standard [RFC3986] to indicate request targets and
|
||
relationships between resources. Messages are passed in a format
|
||
similar to that used by Internet mail [RFC5322] and the Multipurpose
|
||
Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3]
|
||
for the differences between HTTP and MIME messages).
|
||
|
||
HTTP is a generic interface protocol for information systems. It is
|
||
designed to hide the details of how a service is implemented by
|
||
presenting a uniform interface to clients that is independent of the
|
||
types of resources provided. Likewise, servers do not need to be
|
||
aware of each client's purpose: an HTTP request can be considered in
|
||
isolation rather than being associated with a specific type of client
|
||
or a predetermined sequence of application steps. The result is a
|
||
protocol that can be used effectively in many different contexts and
|
||
for which implementations can evolve independently over time.
|
||
|
||
HTTP is also designed for use as an intermediation protocol for
|
||
translating communication to and from non-HTTP information systems.
|
||
HTTP proxies and gateways can provide access to alternative
|
||
information services by translating their diverse protocols into a
|
||
hypertext format that can be viewed and manipulated by clients in the
|
||
same way as HTTP services.
|
||
|
||
One consequence of HTTP flexibility is that the protocol cannot be
|
||
defined in terms of what occurs behind the interface. Instead, we
|
||
are limited to defining the syntax of communication, the intent of
|
||
received communication, and the expected behavior of recipients. If
|
||
the communication is considered in isolation, then successful actions
|
||
ought to be reflected in corresponding changes to the observable
|
||
interface provided by servers. However, since multiple clients might
|
||
act in parallel and perhaps at cross-purposes, we cannot require that
|
||
such changes be observable beyond the scope of a single response.
|
||
|
||
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 describes the architectural elements that are used
|
||
or referred to in HTTP, defines the "http" and "https" URI schemes,
|
||
describes overall network operation and connection management, and
|
||
defines HTTP message framing and forwarding requirements. 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 message parsers and message-
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 6]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
forwarding intermediaries.
|
||
|
||
1.1. Requirements
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC2119].
|
||
|
||
An implementation is not compliant if it fails to satisfy one or more
|
||
of the "MUST" or "REQUIRED" level requirements for the protocols it
|
||
implements. An implementation that satisfies all the "MUST" or
|
||
"REQUIRED" level and all the "SHOULD" level requirements for its
|
||
protocols is said to be "unconditionally compliant"; one that
|
||
satisfies all the "MUST" level requirements but not all the "SHOULD"
|
||
level requirements for its protocols is said to be "conditionally
|
||
compliant".
|
||
|
||
1.2. Syntax Notation
|
||
|
||
This specification uses the Augmented Backus-Naur Form (ABNF)
|
||
notation of [RFC5234].
|
||
|
||
The following core rules are included by reference, as defined in
|
||
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
|
||
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
|
||
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
|
||
sequence of data), SP (space), VCHAR (any visible [USASCII]
|
||
character), and WSP (whitespace).
|
||
|
||
As a syntactic convention, ABNF rule names prefixed with "obs-"
|
||
denote "obsolete" grammar rules that appear for historical reasons.
|
||
|
||
1.2.1. ABNF Extension: #rule
|
||
|
||
The #rule extension to the ABNF rules of [RFC5234] is used to improve
|
||
readability.
|
||
|
||
A construct "#" is defined, similar to "*", for defining comma-
|
||
delimited lists of elements. The full form is "<n>#<m>element"
|
||
indicating at least <n> and at most <m> elements, each separated by a
|
||
single comma (",") and optional whitespace (OWS, Section 1.2.2).
|
||
|
||
Thus,
|
||
|
||
1#element => element *( OWS "," OWS element )
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 7]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
and:
|
||
|
||
#element => [ 1#element ]
|
||
|
||
and for n >= 1 and m > 1:
|
||
|
||
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
|
||
|
||
For compatibility with legacy list rules, recipients SHOULD accept
|
||
empty list elements. In other words, consumers would follow the list
|
||
productions:
|
||
|
||
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
|
||
|
||
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
|
||
|
||
Note that empty elements do not contribute to the count of elements
|
||
present, though.
|
||
|
||
For example, given these ABNF productions:
|
||
|
||
example-list = 1#example-list-elmt
|
||
example-list-elmt = token ; see Section 1.2.2
|
||
|
||
Then these are valid values for example-list (not including the
|
||
double quotes, which are present for delimitation only):
|
||
|
||
"foo,bar"
|
||
" foo ,bar,"
|
||
" foo , ,bar,charlie "
|
||
"foo ,bar, charlie "
|
||
|
||
But these values would be invalid, as at least one non-empty element
|
||
is required:
|
||
|
||
""
|
||
","
|
||
", ,"
|
||
|
||
Appendix C shows the collected ABNF, with the list rules expanded as
|
||
explained above.
|
||
|
||
1.2.2. Basic Rules
|
||
|
||
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
|
||
protocol elements other than the message-body (see Appendix A for
|
||
tolerant applications).
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 8]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
This specification uses three rules to denote the use of linear
|
||
whitespace: OWS (optional whitespace), RWS (required whitespace), and
|
||
BWS ("bad" whitespace).
|
||
|
||
The OWS rule is used where zero or more linear whitespace characters
|
||
might appear. OWS SHOULD either not be produced or be produced as a
|
||
single SP character. Multiple OWS characters that occur within
|
||
field-content SHOULD be replaced with a single SP before interpreting
|
||
the field value or forwarding the message downstream.
|
||
|
||
RWS is used when at least one linear whitespace character is required
|
||
to separate field tokens. RWS SHOULD be produced as a single SP
|
||
character. Multiple RWS characters that occur within field-content
|
||
SHOULD be replaced with a single SP before interpreting the field
|
||
value or forwarding the message downstream.
|
||
|
||
BWS is used where the grammar allows optional whitespace for
|
||
historical reasons but senders SHOULD NOT produce it in messages.
|
||
HTTP/1.1 recipients MUST accept such bad optional whitespace and
|
||
remove it before interpreting the field value or forwarding the
|
||
message downstream.
|
||
|
||
|
||
OWS = *( [ obs-fold ] WSP )
|
||
; "optional" whitespace
|
||
RWS = 1*( [ obs-fold ] WSP )
|
||
; "required" whitespace
|
||
BWS = OWS
|
||
; "bad" whitespace
|
||
obs-fold = CRLF
|
||
; see Section 3.2
|
||
|
||
Many HTTP/1.1 header field values consist of words (token or quoted-
|
||
string) separated by whitespace or special characters. These special
|
||
characters MUST be in a quoted string to be used within a parameter
|
||
value (as defined in Section 6.2).
|
||
|
||
word = token / quoted-string
|
||
|
||
token = 1*tchar
|
||
|
||
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
|
||
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
|
||
/ DIGIT / ALPHA
|
||
; any VCHAR, except special
|
||
|
||
special = "(" / ")" / "<" / ">" / "@" / ","
|
||
/ ";" / ":" / "\" / DQUOTE / "/" / "["
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 9]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
/ "]" / "?" / "=" / "{" / "}"
|
||
|
||
A string of text is parsed as a single word if it is quoted using
|
||
double-quote marks.
|
||
|
||
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
|
||
qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
|
||
; OWS / <VCHAR except DQUOTE and "\"> / obs-text
|
||
obs-text = %x80-FF
|
||
|
||
The backslash character ("\") can be used as a single-character
|
||
quoting mechanism within quoted-string constructs:
|
||
|
||
quoted-pair = "\" ( WSP / VCHAR / obs-text )
|
||
|
||
Producers SHOULD NOT escape characters that do not require escaping
|
||
(i.e., other than DQUOTE and the backslash character).
|
||
|
||
1.2.3. ABNF Rules defined in other Parts of the Specification
|
||
|
||
The ABNF rules below are defined in other parts:
|
||
|
||
request-header = <request-header, defined in [Part2], Section 3>
|
||
response-header = <response-header, defined in [Part2], Section 5>
|
||
|
||
|
||
MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1>
|
||
|
||
|
||
Cache-Control = <Cache-Control, defined in [Part6], Section 3.4>
|
||
Pragma = <Pragma, defined in [Part6], Section 3.4>
|
||
Warning = <Warning, defined in [Part6], Section 3.6>
|
||
|
||
2. HTTP-related architecture
|
||
|
||
HTTP was created for the World Wide Web architecture and has evolved
|
||
over time to support the scalability needs of a worldwide hypertext
|
||
system. Much of that architecture is reflected in the terminology
|
||
and syntax productions used to define HTTP.
|
||
|
||
2.1. Client/Server Messaging
|
||
|
||
HTTP is a stateless request/response protocol that operates by
|
||
exchanging messages across a reliable transport or session-layer
|
||
connection. An HTTP "client" is a program that establishes a
|
||
connection to a server for the purpose of sending one or more HTTP
|
||
requests. An HTTP "server" is a program that accepts connections in
|
||
order to service HTTP requests by sending HTTP responses.
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 10]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Note that the terms client and server refer only to the roles that
|
||
these programs perform for a particular connection. The same program
|
||
might act as a client on some connections and a server on others. We
|
||
use the term "user agent" to refer to the program that initiates a
|
||
request, such as a WWW browser, editor, or spider (web-traversing
|
||
robot), and the term "origin server" to refer to the program that can
|
||
originate authoritative responses to a request. For general
|
||
requirements, we use the term "sender" to refer to whichever
|
||
component sent a given message and the term "recipient" to refer to
|
||
any component that receives the message.
|
||
|
||
Most HTTP communication consists of a retrieval request (GET) for a
|
||
representation of some resource identified by a URI. In the simplest
|
||
case, this might be accomplished via a single bidirectional
|
||
connection (===) between the user agent (UA) and the origin server
|
||
(O).
|
||
|
||
request >
|
||
UA ======================================= O
|
||
< response
|
||
|
||
A client sends an HTTP request to the server in the form of a request
|
||
message (Section 4), beginning with a method, URI, and protocol
|
||
version, followed by MIME-like header fields containing request
|
||
modifiers, client information, and payload metadata, an empty line to
|
||
indicate the end of the header section, and finally the payload body
|
||
(if any).
|
||
|
||
A server responds to the client's request by sending an HTTP response
|
||
message (Section 5), beginning with a status line that includes the
|
||
protocol version, a success or error code, and textual reason phrase,
|
||
followed by MIME-like header fields containing server information,
|
||
resource metadata, and payload metadata, an empty line to indicate
|
||
the end of the header section, and finally the payload body (if any).
|
||
|
||
The following example illustrates a typical message exchange for a
|
||
GET request on the URI "http://www.example.com/hello.txt":
|
||
|
||
client request:
|
||
|
||
GET /hello.txt HTTP/1.1
|
||
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
|
||
Host: www.example.com
|
||
Accept: */*
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 11]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
server response:
|
||
|
||
HTTP/1.1 200 OK
|
||
Date: Mon, 27 Jul 2009 12:28:53 GMT
|
||
Server: Apache
|
||
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
|
||
ETag: "34aa387-d-1568eb00"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 14
|
||
Vary: Accept-Encoding
|
||
Content-Type: text/plain
|
||
|
||
Hello World!
|
||
|
||
2.2. Intermediaries
|
||
|
||
A more complicated situation occurs when one or more intermediaries
|
||
are present in the request/response chain. There are three common
|
||
forms of intermediary: proxy, gateway, and tunnel. In some cases, a
|
||
single intermediary might act as an origin server, proxy, gateway, or
|
||
tunnel, switching behavior based on the nature of each request.
|
||
|
||
> > > >
|
||
UA =========== A =========== B =========== C =========== O
|
||
< < < <
|
||
|
||
The figure above shows three intermediaries (A, B, and C) between the
|
||
user agent and origin server. A request or response message that
|
||
travels the whole chain will pass through four separate connections.
|
||
Some HTTP communication options might apply only to the connection
|
||
with the nearest, non-tunnel neighbor, only to the end-points of the
|
||
chain, or to all connections along the chain. Although the diagram
|
||
is linear, each participant might be engaged in multiple,
|
||
simultaneous communications. For example, B might be receiving
|
||
requests from many clients other than A, and/or forwarding requests
|
||
to servers other than C, at the same time that it is handling A's
|
||
request.
|
||
|
||
We use the terms "upstream" and "downstream" to describe various
|
||
requirements in relation to the directional flow of a message: all
|
||
messages flow from upstream to downstream. Likewise, we use the
|
||
terms "inbound" and "outbound" to refer to directions in relation to
|
||
the request path: "inbound" means toward the origin server and
|
||
"outbound" means toward the user agent.
|
||
|
||
A "proxy" is a message forwarding agent that is selected by the
|
||
client, usually via local configuration rules, to receive requests
|
||
for some type(s) of absolute URI and attempt to satisfy those
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 12]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
requests via translation through the HTTP interface. Some
|
||
translations are minimal, such as for proxy requests for "http" URIs,
|
||
whereas other requests might require translation to and from entirely
|
||
different application-layer protocols. Proxies are often used to
|
||
group an organization's HTTP requests through a common intermediary
|
||
for the sake of security, annotation services, or shared caching.
|
||
|
||
A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
|
||
as a layer above some other server(s) and translates the received
|
||
requests to the underlying server's protocol. Gateways are often
|
||
used for load balancing or partitioning HTTP services across multiple
|
||
machines. Unlike a proxy, a gateway receives requests as if it were
|
||
the origin server for the target resource; the requesting client will
|
||
not be aware that it is communicating with a gateway. A gateway
|
||
communicates with the client as if the gateway is the origin server
|
||
and thus is subject to all of the requirements on origin servers for
|
||
that connection. A gateway communicates with inbound servers using
|
||
any protocol it desires, including private extensions to HTTP that
|
||
are outside the scope of this specification.
|
||
|
||
A "tunnel" acts as a blind relay between two connections without
|
||
changing the messages. Once active, a tunnel is not considered a
|
||
party to the HTTP communication, though the tunnel might have been
|
||
initiated by an HTTP request. A tunnel ceases to exist when both
|
||
ends of the relayed connection are closed. Tunnels are used to
|
||
extend a virtual connection through an intermediary, such as when
|
||
transport-layer security is used to establish private communication
|
||
through a shared firewall proxy.
|
||
|
||
2.3. Caches
|
||
|
||
A "cache" is a local store of previous 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 employ a cache, though a cache
|
||
cannot be used by a server while it is acting as a tunnel.
|
||
|
||
The effect of a cache is that the request/response chain is shortened
|
||
if one of the participants along the chain has a cached response
|
||
applicable to that request. The following illustrates the resulting
|
||
chain if B has a cached copy of an earlier response from O (via C)
|
||
for a request which has not been cached by UA or A.
|
||
|
||
> >
|
||
UA =========== A =========== B - - - - - - C - - - - - - O
|
||
< <
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 13]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
A response is "cacheable" if a cache is allowed to store a copy of
|
||
the response message for use in answering subsequent requests. Even
|
||
when a response is cacheable, there might be additional constraints
|
||
placed by the client or by the origin server on when that cached
|
||
response can be used for a particular request. HTTP requirements for
|
||
cache behavior and cacheable responses are defined in Section 2 of
|
||
[Part6].
|
||
|
||
There are a wide variety of architectures and configurations of
|
||
caches and proxies deployed across the World Wide Web and inside
|
||
large organizations. These systems include national hierarchies of
|
||
proxy caches to save transoceanic bandwidth, systems that broadcast
|
||
or multicast cache entries, organizations that distribute subsets of
|
||
cached data via optical media, and so on.
|
||
|
||
2.4. Transport Independence
|
||
|
||
HTTP systems are used in a wide variety of environments, from
|
||
corporate intranets with high-bandwidth links to long-distance
|
||
communication over low-power radio links and intermittent
|
||
connectivity.
|
||
|
||
HTTP communication usually takes place over TCP/IP connections. The
|
||
default port is TCP 80
|
||
(<http://www.iana.org/assignments/port-numbers>), but other ports can
|
||
be used. This does not preclude HTTP from being implemented on top
|
||
of any other protocol on the Internet, or on other networks. HTTP
|
||
only presumes a reliable transport; any protocol that provides such
|
||
guarantees can be used; the mapping of the HTTP/1.1 request and
|
||
response structures onto the transport data units of the protocol in
|
||
question is outside the scope of this specification.
|
||
|
||
In HTTP/1.0, most implementations used a new connection for each
|
||
request/response exchange. In HTTP/1.1, a connection might be used
|
||
for one or more request/response exchanges, although connections
|
||
might be closed for a variety of reasons (see Section 7.1).
|
||
|
||
2.5. HTTP Version
|
||
|
||
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
|
||
of the protocol. The protocol versioning policy is intended to allow
|
||
the sender to indicate the format of a message and its capacity for
|
||
understanding further HTTP communication, rather than the features
|
||
obtained via that communication. No change is made to the version
|
||
number for the addition of message components which do not affect
|
||
communication behavior or which only add to extensible field values.
|
||
The <minor> number is incremented when the changes made to the
|
||
protocol add features which do not change the general message parsing
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 14]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
algorithm, but which might add to the message semantics and imply
|
||
additional capabilities of the sender. The <major> number is
|
||
incremented when the format of a message within the protocol is
|
||
changed. See [RFC2145] for a fuller explanation.
|
||
|
||
The version of an HTTP message is indicated by an HTTP-Version field
|
||
in the first line of the message. HTTP-Version is case-sensitive.
|
||
|
||
HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
|
||
HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
|
||
|
||
Note that the major and minor numbers MUST be treated as separate
|
||
integers and that each MAY be incremented higher than a single digit.
|
||
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
|
||
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
|
||
and MUST NOT be sent.
|
||
|
||
An application that sends a request or response message that includes
|
||
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
|
||
with this specification. Applications that are at least
|
||
conditionally compliant with this specification SHOULD use an HTTP-
|
||
Version of "HTTP/1.1" in their messages, and MUST do so for any
|
||
message that is not compatible with HTTP/1.0. For more details on
|
||
when to send specific HTTP-Version values, see [RFC2145].
|
||
|
||
The HTTP version of an application is the highest HTTP version for
|
||
which the application is at least conditionally compliant.
|
||
|
||
Proxy and gateway applications need to be careful when forwarding
|
||
messages in protocol versions different from that of the application.
|
||
Since the protocol version indicates the protocol capability of the
|
||
sender, a proxy/gateway MUST NOT send a message with a version
|
||
indicator which is greater than its actual version. If a higher
|
||
version request is received, the proxy/gateway MUST either downgrade
|
||
the request version, or respond with an error, or switch to tunnel
|
||
behavior.
|
||
|
||
Due to interoperability problems with HTTP/1.0 proxies discovered
|
||
since the publication of [RFC2068], caching proxies MUST, gateways
|
||
MAY, and tunnels MUST NOT upgrade the request to the highest version
|
||
they support. The proxy/gateway's response to that request MUST be
|
||
in the same major version as the request.
|
||
|
||
Note: Converting between versions of HTTP might involve
|
||
modification of header fields required or forbidden by the
|
||
versions involved.
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 15]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
2.6. Uniform Resource Identifiers
|
||
|
||
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
|
||
HTTP as the means for identifying resources. URI references are used
|
||
to target requests, indicate redirects, and define relationships.
|
||
HTTP does not limit what a resource might be; it merely defines an
|
||
interface that can be used to interact with a resource via HTTP.
|
||
More information on the scope of URIs and resources can be found in
|
||
[RFC3986].
|
||
|
||
This specification adopts the definitions of "URI-reference",
|
||
"absolute-URI", "relative-part", "port", "host", "path-abempty",
|
||
"path-absolute", "query", and "authority" from [RFC3986]. In
|
||
addition, we define a partial-URI rule for protocol elements that
|
||
allow a relative URI without a fragment.
|
||
|
||
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
|
||
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
|
||
relative-part = <relative-part, defined in [RFC3986], Section 4.2>
|
||
authority = <authority, defined in [RFC3986], Section 3.2>
|
||
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
|
||
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
|
||
port = <port, defined in [RFC3986], Section 3.2.3>
|
||
query = <query, defined in [RFC3986], Section 3.4>
|
||
uri-host = <host, defined in [RFC3986], Section 3.2.2>
|
||
|
||
partial-URI = relative-part [ "?" query ]
|
||
|
||
Each protocol element in HTTP that allows a URI reference will
|
||
indicate in its ABNF production whether the element allows only a URI
|
||
in absolute form (absolute-URI), any relative reference (relative-
|
||
ref), or some other subset of the URI-reference grammar. Unless
|
||
otherwise indicated, URI references are parsed relative to the
|
||
request target (the default base URI for both the request and its
|
||
corresponding response).
|
||
|
||
2.6.1. http URI scheme
|
||
|
||
The "http" URI scheme is hereby defined for the purpose of minting
|
||
identifiers according to their association with the hierarchical
|
||
namespace governed by a potential HTTP origin server listening for
|
||
TCP connections on a given port. The HTTP server is identified via
|
||
the generic syntax's authority component, which includes a host
|
||
identifier and optional TCP port, and the remainder of the URI is
|
||
considered to be identifying data corresponding to a resource for
|
||
which that server might provide an HTTP interface.
|
||
|
||
http-URI = "http:" "//" authority path-abempty [ "?" query ]
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 16]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
The host identifier within an authority component is defined in
|
||
[RFC3986], Section 3.2.2. If host is provided as an IP literal or
|
||
IPv4 address, then the HTTP server is any listener on the indicated
|
||
TCP port at that IP address. If host is a registered name, then that
|
||
name is considered an indirect identifier and the recipient might use
|
||
a name resolution service, such as DNS, to find the address of a
|
||
listener for that host. The host MUST NOT be empty; if an "http" URI
|
||
is received with an empty host, then it MUST be rejected as invalid.
|
||
If the port subcomponent is empty or not given, then TCP port 80 is
|
||
assumed (the default reserved port for WWW services).
|
||
|
||
Regardless of the form of host identifier, access to that host is not
|
||
implied by the mere presence of its name or address. The host might
|
||
or might not exist and, even when it does exist, might or might not
|
||
be running an HTTP server or listening to the indicated port. The
|
||
"http" URI scheme makes use of the delegated nature of Internet names
|
||
and addresses to establish a naming authority (whatever entity has
|
||
the ability to place an HTTP server at that Internet name or address)
|
||
and allows that authority to determine which names are valid and how
|
||
they might be used.
|
||
|
||
When an "http" URI is used within a context that calls for access to
|
||
the indicated resource, a client MAY attempt access by resolving the
|
||
host to an IP address, establishing a TCP connection to that address
|
||
on the indicated port, and sending an HTTP request message to the
|
||
server containing the URI's identifying data as described in
|
||
Section 4. If the server responds to that request with a non-interim
|
||
HTTP response message, as described in Section 5, then that response
|
||
is considered an authoritative answer to the client's request.
|
||
|
||
Although HTTP is independent of the transport protocol, the "http"
|
||
scheme is specific to TCP-based services because the name delegation
|
||
process depends on TCP for establishing authority. An HTTP service
|
||
based on some other underlying connection protocol would presumably
|
||
be identified using a different URI scheme, just as the "https"
|
||
scheme (below) is used for servers that require an SSL/TLS transport
|
||
layer on a connection. Other protocols might also be used to provide
|
||
access to "http" identified resources --- it is only the
|
||
authoritative interface used for mapping the namespace that is
|
||
specific to TCP.
|
||
|
||
The URI generic syntax for authority also includes a deprecated
|
||
userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
|
||
authentication information in the URI. The userinfo subcomponent
|
||
(and its "@" delimiter) MUST NOT be used in an "http" URI. URI
|
||
reference recipients SHOULD parse for the existence of userinfo and
|
||
treat its presence as an error, likely indicating that the deprecated
|
||
subcomponent is being used to obscure the authority for the sake of
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 17]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
phishing attacks.
|
||
|
||
2.6.2. https URI scheme
|
||
|
||
The "https" URI scheme is hereby defined for the purpose of minting
|
||
identifiers according to their association with the hierarchical
|
||
namespace governed by a potential HTTP origin server listening for
|
||
SSL/TLS-secured connections on a given TCP port.
|
||
|
||
All of the requirements listed above for the "http" scheme are also
|
||
requirements for the "https" scheme, except that a default TCP port
|
||
of 443 is assumed if the port subcomponent is empty or not given, and
|
||
the TCP connection MUST be secured for privacy through the use of
|
||
strong encryption prior to sending the first HTTP request.
|
||
|
||
https-URI = "https:" "//" authority path-abempty [ "?" query ]
|
||
|
||
Unlike the "http" scheme, responses to "https" identified requests
|
||
are never "public" and thus are ineligible for shared caching. Their
|
||
default is "private" and might be further constrained via use of the
|
||
Cache-Control header field.
|
||
|
||
Resources made available via the "https" scheme have no shared
|
||
identity with the "http" scheme even if their resource identifiers
|
||
only differ by the single "s" in the scheme name. They are different
|
||
services governed by different authorities. However, some extensions
|
||
to HTTP that apply to entire host domains, such as the Cookie
|
||
protocol, do allow one service to effect communication with the other
|
||
services based on host domain matching.
|
||
|
||
The process for authoritative access to an "https" identified
|
||
resource is defined in [RFC2818].
|
||
|
||
2.6.3. http and https URI Normalization and Comparison
|
||
|
||
Since the "http" and "https" schemes conform to the URI generic
|
||
syntax, such URIs are normalized and compared according to the
|
||
algorithm defined in [RFC3986], Section 6, using the defaults
|
||
described above for each scheme.
|
||
|
||
If the port is equal to the default port for a scheme, the normal
|
||
form is to elide the port subcomponent. Likewise, an empty path
|
||
component is equivalent to an absolute path of "/", so the normal
|
||
form is to provide a path of "/" instead. The scheme and host are
|
||
case-insensitive and normally provided in lowercase; all other
|
||
components are compared in a case-sensitive manner. Characters other
|
||
than those in the "reserved" set are equivalent to their percent-
|
||
encoded octets (see [RFC3986], Section 2.1): the normal form is to
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 18]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
not encode them.
|
||
|
||
For example, the following three URIs are equivalent:
|
||
|
||
http://example.com:80/~smith/home.html
|
||
http://EXAMPLE.com/%7Esmith/home.html
|
||
http://EXAMPLE.com:/%7esmith/home.html
|
||
|
||
[[TODO-not-here: This paragraph does not belong here. --roy]] If
|
||
path-abempty is the empty string (i.e., there is no slash "/" path
|
||
separator following the authority), then the "http" URI MUST be given
|
||
as "/" when used as a request-target (Section 4.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 it received. If a proxy receives
|
||
a fully qualified domain name, the proxy MUST NOT change the host
|
||
name.
|
||
|
||
3. HTTP Message
|
||
|
||
All HTTP/1.1 messages consist of a start-line followed by a sequence
|
||
of characters in a format similar to the Internet Message Format
|
||
[RFC5322]: zero or more header fields (collectively referred to as
|
||
the "headers" or the "header section"), an empty line indicating the
|
||
end of the header section, and an optional message-body.
|
||
|
||
An HTTP message can either be a request from client to server or a
|
||
response from server to client. Syntactically, the two types of
|
||
message differ only in the start-line, which is either a Request-Line
|
||
(for requests) or a Status-Line (for responses), and in the algorithm
|
||
for determining the length of the message-body (Section 3.3). In
|
||
theory, a client could receive requests and a server could receive
|
||
responses, distinguishing them by their different start-line formats,
|
||
but in practice servers are implemented to only expect a request (a
|
||
response is interpreted as an unknown or invalid request method) and
|
||
clients are implemented to only expect a response.
|
||
|
||
HTTP-message = start-line
|
||
*( header-field CRLF )
|
||
CRLF
|
||
[ message-body ]
|
||
start-line = Request-Line / Status-Line
|
||
|
||
Whitespace (WSP) MUST NOT be sent between the start-line and the
|
||
first header field. The presence of whitespace might be an attempt
|
||
to trick a noncompliant implementation of HTTP into ignoring that
|
||
field or processing the next line as a new request, either of which
|
||
might result in security issues when implementations within the
|
||
request chain interpret the same message differently. HTTP/1.1
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 19]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
servers MUST reject such a message with a 400 (Bad Request) response.
|
||
|
||
3.1. Message Parsing Robustness
|
||
|
||
In the interest of robustness, servers SHOULD ignore at least one
|
||
empty line received where a Request-Line is expected. In other
|
||
words, if the server is reading the protocol stream at the beginning
|
||
of a message and receives a CRLF first, it SHOULD ignore the CRLF.
|
||
|
||
Some old HTTP/1.0 client implementations generate an extra CRLF after
|
||
a POST request as a lame workaround for some early server
|
||
applications that failed to read message-body content that was not
|
||
terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or
|
||
follow a request with an extra CRLF. If terminating the request
|
||
message-body with a line-ending is desired, then the client MUST
|
||
include the terminating CRLF octets as part of the message-body
|
||
length.
|
||
|
||
The normal procedure for parsing an HTTP message is to read the
|
||
start-line into a structure, read each header field into a hash table
|
||
by field name until the empty line, and then use the parsed data to
|
||
determine if a message-body is expected. If a message-body has been
|
||
indicated, then it is read as a stream until an amount of octets
|
||
equal to the message-body length is read or the connection is closed.
|
||
Care must be taken to parse an HTTP message as a sequence of octets
|
||
in an encoding that is a superset of US-ASCII. Attempting to parse
|
||
HTTP as a stream of Unicode characters in a character encoding like
|
||
UTF-16 might introduce security flaws due to the differing ways that
|
||
such parsers interpret invalid characters.
|
||
|
||
HTTP allows the set of defined header fields to be extended without
|
||
changing the protocol version (see Section 10.1). However, such
|
||
fields might not be recognized by a downstream recipient and might be
|
||
stripped by non-transparent intermediaries. Unrecognized header
|
||
fields MUST be forwarded by transparent proxies and SHOULD be ignored
|
||
by a recipient.
|
||
|
||
3.2. Header Fields
|
||
|
||
Each HTTP header field consists of a case-insensitive field name
|
||
followed by a colon (":"), optional whitespace, and the field value.
|
||
|
||
header-field = field-name ":" OWS [ field-value ] OWS
|
||
field-name = token
|
||
field-value = *( field-content / OWS )
|
||
field-content = *( WSP / VCHAR / obs-text )
|
||
|
||
No whitespace is allowed between the header field name and colon.
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 20]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
For security reasons, any request message received containing such
|
||
whitespace MUST be rejected with a response code of 400 (Bad
|
||
Request). A proxy MUST remove any such whitespace from a response
|
||
message before forwarding the message downstream.
|
||
|
||
A field value MAY be preceded by optional whitespace (OWS); a single
|
||
SP is preferred. The field value does not include any leading or
|
||
trailing white space: OWS occurring before the first non-whitespace
|
||
character of the field value or after the last non-whitespace
|
||
character of the field value is ignored and SHOULD be removed before
|
||
further processing (as this does not change the meaning of the header
|
||
field).
|
||
|
||
The order in which header fields with differing field names are
|
||
received is not significant. However, it is "good practice" to send
|
||
header fields that contain control data first, such as Host on
|
||
requests and Date on responses, so that implementations can decide
|
||
when not to handle a message as early as possible. A server MUST
|
||
wait until the entire header section is received before interpreting
|
||
a request message, since later header fields might include
|
||
conditionals, authentication credentials, or deliberately misleading
|
||
duplicate header fields that would impact request processing.
|
||
|
||
Multiple header fields with the same field name MUST NOT be sent in a
|
||
message unless the entire field value for that header field is
|
||
defined as a comma-separated list [i.e., #(values)]. Multiple header
|
||
fields with the same field name can be combined into one "field-name:
|
||
field-value" pair, without changing the semantics of the message, by
|
||
appending each subsequent field value to the combined field value in
|
||
order, separated by a comma. The order in which header fields with
|
||
the same field name are received is therefore significant to the
|
||
interpretation of the combined field value; a proxy MUST NOT change
|
||
the order of these field values when forwarding a message.
|
||
|
||
Note: The "Set-Cookie" header as implemented in practice (as
|
||
opposed to how it is specified in [RFC2109]) can occur multiple
|
||
times, but does not use the list syntax, and thus cannot be
|
||
combined into a single line. (See Appendix A.2.3 of [Kri2001] for
|
||
details.) Also note that the Set-Cookie2 header specified in
|
||
[RFC2965] does not share this problem.
|
||
|
||
Historically, HTTP header field values could be extended over
|
||
multiple lines by preceding each extra line with at least one space
|
||
or horizontal tab character (line folding). This specification
|
||
deprecates such line folding except within the message/http media
|
||
type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages
|
||
that include line folding (i.e., that contain any field-content that
|
||
matches the obs-fold rule) unless the message is intended for
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 21]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
packaging within the message/http media type. HTTP/1.1 recipients
|
||
SHOULD accept line folding and replace any embedded obs-fold
|
||
whitespace with a single SP prior to interpreting the field value or
|
||
forwarding the message downstream.
|
||
|
||
Historically, HTTP has allowed field content with text in the ISO-
|
||
8859-1 [ISO-8859-1] character encoding and supported other character
|
||
sets only through use of [RFC2047] encoding. In practice, most HTTP
|
||
header field values use only a subset of the US-ASCII character
|
||
encoding [USASCII]. Newly defined header fields SHOULD limit their
|
||
field values to US-ASCII characters. Recipients SHOULD treat other
|
||
(obs-text) octets in field content as opaque data.
|
||
|
||
Comments can be included in some HTTP header fields by surrounding
|
||
the comment text with parentheses. Comments are only allowed in
|
||
fields containing "comment" as part of their field value definition.
|
||
|
||
comment = "(" *( ctext / quoted-cpair / comment ) ")"
|
||
ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
|
||
; OWS / <VCHAR except "(", ")", and "\"> / obs-text
|
||
|
||
The backslash character ("\") can be used as a single-character
|
||
quoting mechanism within comment constructs:
|
||
|
||
quoted-cpair = "\" ( WSP / VCHAR / obs-text )
|
||
|
||
Producers SHOULD NOT escape characters that do not require escaping
|
||
(i.e., other than the backslash character "\" and the parentheses "("
|
||
and ")").
|
||
|
||
3.3. Message Body
|
||
|
||
The message-body (if any) of an HTTP message is used to carry the
|
||
payload body associated with the request or response.
|
||
|
||
message-body = *OCTET
|
||
|
||
The message-body differs from the payload body only when a transfer-
|
||
coding has been applied, as indicated by the Transfer-Encoding header
|
||
field (Section 9.7). When one or more transfer-codings are applied
|
||
to a payload in order to form the message-body, the Transfer-Encoding
|
||
header field MUST contain the list of transfer-codings applied.
|
||
Transfer-Encoding is a property of the message, not of the payload,
|
||
and thus MAY be added or removed by any implementation along the
|
||
request/response chain under the constraints found in Section 6.2.
|
||
|
||
The rules for when a message-body is allowed in a message differ for
|
||
requests and responses.
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 22]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
The presence of a message-body in a request is signaled by the
|
||
inclusion of a Content-Length or Transfer-Encoding header field in
|
||
the request's header fields, even if the request method does not
|
||
define any use for a message-body. This allows the request message
|
||
framing algorithm to be independent of method semantics.
|
||
|
||
For response messages, whether or not a message-body is included with
|
||
a message is dependent on both the request method and the response
|
||
status code (Section 5.1.1). Responses to the HEAD request method
|
||
never include a message-body because the associated response header
|
||
fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate
|
||
what their values would have been if the method had been GET. All
|
||
1xx (Informational), 204 (No Content), and 304 (Not Modified)
|
||
responses MUST NOT include a message-body. All other responses do
|
||
include a message-body, although the body MAY be of zero length.
|
||
|
||
The length of the message-body is determined by one of the following
|
||
(in order of precedence):
|
||
|
||
1. Any response to a HEAD request and any response with a status
|
||
code of 100-199, 204, or 304 is always terminated by the first
|
||
empty line after the header fields, regardless of the header
|
||
fields present in the message, and thus cannot contain a message-
|
||
body.
|
||
|
||
2. If a Transfer-Encoding header field (Section 9.7) is present and
|
||
the "chunked" transfer-coding (Section 6.2) is the final
|
||
encoding, the message-body length is determined by reading and
|
||
decoding the chunked data until the transfer-coding indicates the
|
||
data is complete.
|
||
|
||
If a Transfer-Encoding header field is present in a response and
|
||
the "chunked" transfer-coding is not the final encoding, the
|
||
message-body length is determined by reading the connection until
|
||
it is closed by the server. If a Transfer-Encoding header field
|
||
is present in a request and the "chunked" transfer-coding is not
|
||
the final encoding, the message-body length cannot be determined
|
||
reliably; the server MUST respond with the 400 (Bad Request)
|
||
status code and then close the connection.
|
||
|
||
If a message is received with both a Transfer-Encoding header
|
||
field and a Content-Length header field, the Transfer-Encoding
|
||
overrides the Content-Length. Such a message might indicate an
|
||
attempt to perform request or response smuggling (bypass of
|
||
security-related checks on message routing or content) and thus
|
||
ought to be handled as an error. The provided Content-Length
|
||
MUST be removed, prior to forwarding the message downstream, or
|
||
replaced with the real message-body length after the transfer-
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 23]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
coding is decoded.
|
||
|
||
3. If a message is received without Transfer-Encoding and with
|
||
either multiple Content-Length header fields or a single Content-
|
||
Length header field with an invalid value, then the message
|
||
framing is invalid and MUST be treated as an error to prevent
|
||
request or response smuggling. If this is a request message, the
|
||
server MUST respond with a 400 (Bad Request) status code and then
|
||
close the connection. If this is a response message received by
|
||
a proxy or gateway, the proxy or gateway MUST discard the
|
||
received response, send a 502 (Bad Gateway) status code as its
|
||
downstream response, and then close the connection. If this is a
|
||
response message received by a user-agent, the message-body
|
||
length is determined by reading the connection until it is
|
||
closed; an error SHOULD be indicated to the user.
|
||
|
||
4. If a valid Content-Length header field (Section 9.2) is present
|
||
without Transfer-Encoding, its decimal value defines the message-
|
||
body length in octets. If the actual number of octets sent in
|
||
the message is less than the indicated Content-Length, the
|
||
recipient MUST consider the message to be incomplete and treat
|
||
the connection as no longer usable. If the actual number of
|
||
octets sent in the message is more than the indicated Content-
|
||
Length, the recipient MUST only process the message-body up to
|
||
the field value's number of octets; the remainder of the message
|
||
MUST either be discarded or treated as the next message in a
|
||
pipeline. For the sake of robustness, a user-agent MAY attempt
|
||
to detect and correct such an error in message framing if it is
|
||
parsing the response to the last request on on a connection and
|
||
the connection has been closed by the server.
|
||
|
||
5. If this is a request message and none of the above are true, then
|
||
the message-body length is zero (no message-body is present).
|
||
|
||
6. Otherwise, this is a response message without a declared message-
|
||
body length, so the message-body length is determined by the
|
||
number of octets received prior to the server closing the
|
||
connection.
|
||
|
||
Since there is no way to distinguish a successfully completed, close-
|
||
delimited message from a partially-received message interrupted by
|
||
network failure, implementations SHOULD use encoding or length-
|
||
delimited messages whenever possible. The close-delimiting feature
|
||
exists primarily for backwards compatibility with HTTP/1.0.
|
||
|
||
A server MAY reject a request that contains a message-body but not a
|
||
Content-Length by responding with 411 (Length Required).
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 24]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Unless a transfer-coding other than "chunked" has been applied, a
|
||
client that sends a request containing a message-body SHOULD use a
|
||
valid Content-Length header field if the message-body length is known
|
||
in advance, rather than the "chunked" encoding, since some existing
|
||
services respond to "chunked" with a 411 (Length Required) status
|
||
code even though they understand the chunked encoding. This is
|
||
typically because such services are implemented via a gateway that
|
||
requires a content-length in advance of being called and the server
|
||
is unable or unwilling to buffer the entire request before
|
||
processing.
|
||
|
||
A client that sends a request containing a message-body MUST include
|
||
a valid Content-Length header field if it does not know the server
|
||
will handle HTTP/1.1 (or later) requests; such knowledge can be in
|
||
the form of specific user configuration or by remembering the version
|
||
of a prior received response.
|
||
|
||
Request messages that are prematurely terminated, possibly due to a
|
||
cancelled connection or a server-imposed time-out exception, MUST
|
||
result in closure of the connection; sending an HTTP/1.1 error
|
||
response prior to closing the connection is OPTIONAL. Response
|
||
messages that are prematurely terminated, usually by closure of the
|
||
connection prior to receiving the expected number of octets or by
|
||
failure to decode a transfer-encoded message-body, MUST be recorded
|
||
as incomplete. A user agent MUST NOT render an incomplete response
|
||
message-body as if it were complete (i.e., some indication must be
|
||
given to the user that an error occurred). Cache requirements for
|
||
incomplete responses are defined in Section 2.1.1 of [Part6].
|
||
|
||
A server MUST read the entire request message-body or close the
|
||
connection after sending its response, since otherwise the remaining
|
||
data on a persistent connection would be misinterpreted as the next
|
||
request. Likewise, a client MUST read the entire response message-
|
||
body if it intends to reuse the same connection for a subsequent
|
||
request. Pipelining multiple requests on a connection is described
|
||
in Section 7.1.2.2.
|
||
|
||
3.4. General Header Fields
|
||
|
||
There are a few header fields which have general applicability for
|
||
both request and response messages, but which do not apply to the
|
||
payload being transferred. These header fields apply only to the
|
||
message being transmitted.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 25]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
general-header = Cache-Control ; [Part6], Section 3.2
|
||
/ Connection ; Section 9.1
|
||
/ Date ; Section 9.3
|
||
/ Pragma ; [Part6], Section 3.4
|
||
/ Trailer ; Section 9.6
|
||
/ Transfer-Encoding ; Section 9.7
|
||
/ Upgrade ; Section 9.8
|
||
/ Via ; Section 9.9
|
||
/ Warning ; [Part6], Section 3.6
|
||
/ MIME-Version ; [Part3], Appendix A.1
|
||
|
||
General-header field names can be extended reliably only in
|
||
combination with a change in the protocol version. However, new or
|
||
experimental header fields might be given the semantics of general
|
||
header fields if all parties in the communication recognize them to
|
||
be general-header fields.
|
||
|
||
4. Request
|
||
|
||
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,
|
||
the identifier of the resource, and the protocol version in use.
|
||
|
||
Request = Request-Line ; Section 4.1
|
||
*( header-field CRLF ) ; Section 3.2
|
||
CRLF
|
||
[ message-body ] ; Section 3.3
|
||
|
||
4.1. Request-Line
|
||
|
||
The Request-Line begins with a method token, followed by the request-
|
||
target and the protocol version, and ending with CRLF. The elements
|
||
are separated by SP characters. No CR or LF is allowed except in the
|
||
final CRLF sequence.
|
||
|
||
Request-Line = Method SP request-target SP HTTP-Version CRLF
|
||
|
||
4.1.1. Method
|
||
|
||
The Method token indicates the method to be performed on the resource
|
||
identified by the request-target. The method is case-sensitive.
|
||
|
||
Method = token
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 26]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
4.1.2. request-target
|
||
|
||
The request-target identifies the resource upon which to apply the
|
||
request.
|
||
|
||
request-target = "*"
|
||
/ absolute-URI
|
||
/ ( path-absolute [ "?" query ] )
|
||
/ authority
|
||
|
||
The four options for request-target are dependent on the nature of
|
||
the request.
|
||
|
||
The asterisk "*" means that the request does not apply to a
|
||
particular resource, but to the server itself, and is only allowed
|
||
when the method used does not necessarily apply to a resource. One
|
||
example would be
|
||
|
||
OPTIONS * HTTP/1.1
|
||
|
||
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
|
||
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
|
||
specified by the absolute-URI. In order to avoid request loops, a
|
||
proxy MUST be able to recognize all of its server names, including
|
||
any aliases, local variations, and the numeric IP address. An
|
||
example Request-Line would be:
|
||
|
||
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
|
||
|
||
To allow for transition to absolute-URIs in all requests in future
|
||
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
|
||
them in requests to proxies.
|
||
|
||
The authority form is only used by the CONNECT method (Section 7.9 of
|
||
[Part2]).
|
||
|
||
The most common form of request-target is that used to identify a
|
||
resource on an origin server or gateway. In this case the absolute
|
||
path of the URI MUST be transmitted (see Section 2.6.1, path-
|
||
absolute) as the request-target, and the network location of the URI
|
||
(authority) MUST be transmitted in a Host header field. For example,
|
||
a client wishing to retrieve the resource above directly from the
|
||
origin server would create a TCP connection to port 80 of the host
|
||
"www.example.org" and send the lines:
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 27]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
GET /pub/WWW/TheProject.html HTTP/1.1
|
||
Host: www.example.org
|
||
|
||
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
|
||
be given as "/" (the server root).
|
||
|
||
If a proxy receives a request without any path in the request-target
|
||
and the method specified is capable of supporting the asterisk form
|
||
of request-target, then the last proxy on the request chain MUST
|
||
forward the request with "*" as the final request-target.
|
||
|
||
For example, the request
|
||
|
||
OPTIONS http://www.example.org:8001 HTTP/1.1
|
||
|
||
would be forwarded by the proxy as
|
||
|
||
OPTIONS * HTTP/1.1
|
||
Host: www.example.org:8001
|
||
|
||
after connecting to port 8001 of host "www.example.org".
|
||
|
||
The request-target is transmitted in the format specified in
|
||
Section 2.6.1. If the request-target is percent-encoded ([RFC3986],
|
||
Section 2.1), the origin server MUST decode the request-target in
|
||
order to properly interpret the request. Servers SHOULD respond to
|
||
invalid request-targets with an appropriate status code.
|
||
|
||
A transparent proxy MUST NOT rewrite the "path-absolute" part of the
|
||
received request-target when forwarding it to the next inbound
|
||
server, except as noted above to replace a null path-absolute with
|
||
"/" or "*".
|
||
|
||
Note: The "no rewrite" rule prevents the proxy from changing the
|
||
meaning of the request when the origin server is improperly using
|
||
a non-reserved URI character for a reserved purpose. Implementors
|
||
need to be aware that some pre-HTTP/1.1 proxies have been known to
|
||
rewrite the request-target.
|
||
|
||
HTTP does not place a pre-defined limit on the length of a request-
|
||
target. A server MUST be prepared to receive URIs of unbounded
|
||
length and respond with the 414 (URI Too Long) status code if the
|
||
received request-target would be longer than the server wishes to
|
||
handle (see Section 8.4.15 of [Part2]).
|
||
|
||
Various ad-hoc limitations on request-target length are found in
|
||
practice. It is RECOMMENDED that all HTTP senders and recipients
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 28]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
support request-target lengths of 8000 or more octets.
|
||
|
||
Note: Fragments ([RFC3986], Section 3.5) are not part of the
|
||
request-target and thus will not be transmitted in an HTTP
|
||
request.
|
||
|
||
4.2. The Resource Identified by a Request
|
||
|
||
The exact resource identified by an Internet request is determined by
|
||
examining both the request-target and the Host header field.
|
||
|
||
An origin server that does not allow resources to differ by the
|
||
requested host MAY ignore the Host header field value when
|
||
determining the resource identified by an HTTP/1.1 request. (But see
|
||
Appendix B.1.1 for other requirements on Host support in HTTP/1.1.)
|
||
|
||
An origin server that does differentiate resources based on the host
|
||
requested (sometimes referred to as virtual hosts or vanity host
|
||
names) MUST use the following rules for determining the requested
|
||
resource on an HTTP/1.1 request:
|
||
|
||
1. If request-target is an absolute-URI, the host is part of the
|
||
request-target. Any Host header field value in the request MUST
|
||
be ignored.
|
||
|
||
2. If the request-target is not an absolute-URI, and the request
|
||
includes a Host header field, the host is determined by the Host
|
||
header field value.
|
||
|
||
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
|
||
message.
|
||
|
||
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
|
||
something unique to a particular host) in order to determine what
|
||
exact resource is being requested.
|
||
|
||
4.3. Effective Request URI
|
||
|
||
HTTP requests often do not carry the absolute URI ([RFC3986], Section
|
||
4.3) for the target resource; instead, the URI needs to be inferred
|
||
from the request-target, Host header field, and connection context.
|
||
The result of this process is called the "effective request URI".
|
||
The "target resource" is the resource identified by the effective
|
||
request URI.
|
||
|
||
If the request-target is an absolute-URI, then the effective request
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 29]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
URI is the request-target.
|
||
|
||
If the request-target uses the path-absolute (plus optional query)
|
||
syntax or if it is just the asterisk "*", then the effective request
|
||
URI is constructed by concatenating
|
||
|
||
o the scheme name: "http" if the request was received over an
|
||
insecure TCP connection, or "https" when received over a SSL/
|
||
TLS-secured TCP connection,
|
||
|
||
o the character sequence "://",
|
||
|
||
o the authority component, as specified in the Host header
|
||
(Section 9.4) and determined by the rules in Section 4.2,
|
||
[[effrequri-nohost: Do we need to include the handling of missing
|
||
hosts in HTTP/1.0 messages, as described in Section 4.2? -- See
|
||
<http://tools.ietf.org/wg/httpbis/trac/ticket/221> --jre]] and
|
||
|
||
o the request-target obtained from the Request-Line, unless the
|
||
request-target is just the asterisk "*".
|
||
|
||
Otherwise, when request-target uses the authority form, the effective
|
||
Request URI is undefined.
|
||
|
||
Example 1: the effective request URI for the message
|
||
|
||
GET /pub/WWW/TheProject.html HTTP/1.1
|
||
Host: www.example.org:8080
|
||
|
||
(received over an insecure TCP connection) is "http", plus "://",
|
||
plus the authority component "www.example.org:8080", plus the
|
||
request-target "/pub/WWW/TheProject.html", thus
|
||
"http://www.example.org:8080/pub/WWW/TheProject.html".
|
||
|
||
Example 2: the effective request URI for the message
|
||
|
||
GET * HTTP/1.1
|
||
Host: www.example.org
|
||
|
||
(received over an SSL/TLS secured TCP connection) is "https", plus
|
||
"://", plus the authority component "www.example.org", thus
|
||
"https://www.example.org".
|
||
|
||
Effective request URIs are compared using the rules described in
|
||
Section 2.6.3, except that empty path components MUST NOT be treated
|
||
as equivalent to an absolute path of "/".
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 30]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
5. Response
|
||
|
||
After receiving and interpreting a request message, a server responds
|
||
with an HTTP response message.
|
||
|
||
Response = Status-Line ; Section 5.1
|
||
*( header-field CRLF ) ; Section 3.2
|
||
CRLF
|
||
[ message-body ] ; Section 3.3
|
||
|
||
5.1. Status-Line
|
||
|
||
The first line of a Response message is the Status-Line, consisting
|
||
of the protocol version followed by a numeric status code and its
|
||
associated textual phrase, with each element separated by SP
|
||
characters. No CR or LF is allowed except in the final CRLF
|
||
sequence.
|
||
|
||
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
|
||
|
||
5.1.1. Status Code and Reason Phrase
|
||
|
||
The Status-Code element is a 3-digit integer result code of the
|
||
attempt to understand and satisfy the request. These codes are fully
|
||
defined in Section 8 of [Part2]. The Reason Phrase exists for the
|
||
sole purpose of providing a textual description associated with the
|
||
numeric status code, out of deference to earlier Internet application
|
||
protocols that were more frequently used with interactive text
|
||
clients. A client SHOULD ignore the content of the Reason Phrase.
|
||
|
||
The first digit of the Status-Code defines the class of response.
|
||
The last two digits do not have any categorization role. There are 5
|
||
values for the first digit:
|
||
|
||
o 1xx: Informational - Request received, continuing process
|
||
|
||
o 2xx: Success - The action was successfully received, understood,
|
||
and accepted
|
||
|
||
o 3xx: Redirection - Further action must be taken in order to
|
||
complete the request
|
||
|
||
o 4xx: Client Error - The request contains bad syntax or cannot be
|
||
fulfilled
|
||
|
||
o 5xx: Server Error - The server failed to fulfill an apparently
|
||
valid request
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 31]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Status-Code = 3DIGIT
|
||
Reason-Phrase = *( WSP / VCHAR / obs-text )
|
||
|
||
6. Protocol Parameters
|
||
|
||
6.1. Date/Time Formats: Full Date
|
||
|
||
HTTP applications have historically allowed three different formats
|
||
for date/time stamps. However, the preferred format is a fixed-
|
||
length subset of that defined by [RFC1123]:
|
||
|
||
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
|
||
|
||
The other formats are described here only for compatibility with
|
||
obsolete implementations.
|
||
|
||
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
|
||
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
|
||
|
||
HTTP/1.1 clients and servers that parse a date value MUST accept all
|
||
three formats (for compatibility with HTTP/1.0), though they MUST
|
||
only generate the RFC 1123 format for representing HTTP-date values
|
||
in header fields. See Appendix A for further information.
|
||
|
||
All HTTP date/time stamps MUST be represented in Greenwich Mean Time
|
||
(GMT), without exception. For the purposes of HTTP, GMT is exactly
|
||
equal to UTC (Coordinated Universal Time). This is indicated in the
|
||
first two formats by the inclusion of "GMT" as the three-letter
|
||
abbreviation for time zone, and MUST be assumed when reading the
|
||
asctime format. HTTP-date is case sensitive and MUST NOT include
|
||
additional whitespace beyond that specifically included as SP in the
|
||
grammar.
|
||
|
||
HTTP-date = rfc1123-date / obs-date
|
||
|
||
Preferred format:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 32]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
|
||
|
||
day-name = %x4D.6F.6E ; "Mon", case-sensitive
|
||
/ %x54.75.65 ; "Tue", case-sensitive
|
||
/ %x57.65.64 ; "Wed", case-sensitive
|
||
/ %x54.68.75 ; "Thu", case-sensitive
|
||
/ %x46.72.69 ; "Fri", case-sensitive
|
||
/ %x53.61.74 ; "Sat", case-sensitive
|
||
/ %x53.75.6E ; "Sun", case-sensitive
|
||
|
||
date1 = day SP month SP year
|
||
; e.g., 02 Jun 1982
|
||
|
||
day = 2DIGIT
|
||
month = %x4A.61.6E ; "Jan", case-sensitive
|
||
/ %x46.65.62 ; "Feb", case-sensitive
|
||
/ %x4D.61.72 ; "Mar", case-sensitive
|
||
/ %x41.70.72 ; "Apr", case-sensitive
|
||
/ %x4D.61.79 ; "May", case-sensitive
|
||
/ %x4A.75.6E ; "Jun", case-sensitive
|
||
/ %x4A.75.6C ; "Jul", case-sensitive
|
||
/ %x41.75.67 ; "Aug", case-sensitive
|
||
/ %x53.65.70 ; "Sep", case-sensitive
|
||
/ %x4F.63.74 ; "Oct", case-sensitive
|
||
/ %x4E.6F.76 ; "Nov", case-sensitive
|
||
/ %x44.65.63 ; "Dec", case-sensitive
|
||
year = 4DIGIT
|
||
|
||
GMT = %x47.4D.54 ; "GMT", case-sensitive
|
||
|
||
time-of-day = hour ":" minute ":" second
|
||
; 00:00:00 - 23:59:59
|
||
|
||
hour = 2DIGIT
|
||
minute = 2DIGIT
|
||
second = 2DIGIT
|
||
|
||
The semantics of day-name, day, month, year, and time-of-day are the
|
||
same as those defined for the RFC 5322 constructs with the
|
||
corresponding name ([RFC5322], Section 3.3).
|
||
|
||
Obsolete formats:
|
||
|
||
obs-date = rfc850-date / asctime-date
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 33]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
|
||
date2 = day "-" month "-" 2DIGIT
|
||
; day-month-year (e.g., 02-Jun-82)
|
||
|
||
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
|
||
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
|
||
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
|
||
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
|
||
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
|
||
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
|
||
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
|
||
|
||
|
||
asctime-date = day-name SP date3 SP time-of-day SP year
|
||
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
|
||
; month day (e.g., Jun 2)
|
||
|
||
Note: Recipients of date values are encouraged to be robust in
|
||
accepting date values that might have been sent by non-HTTP
|
||
applications, as is sometimes the case when retrieving or posting
|
||
messages via proxies/gateways to SMTP or NNTP.
|
||
|
||
Note: HTTP requirements for the date/time stamp format apply only
|
||
to their usage within the protocol stream. Clients and servers
|
||
are not required to use these formats for user presentation,
|
||
request logging, etc.
|
||
|
||
6.2. Transfer Codings
|
||
|
||
Transfer-coding values are used to indicate an encoding
|
||
transformation that has been, can be, or might need to be applied to
|
||
a payload body in order to ensure "safe transport" through the
|
||
network. This differs from a content coding in that the transfer-
|
||
coding is a property of the message rather than a property of the
|
||
representation that is being transferred.
|
||
|
||
transfer-coding = "chunked" ; Section 6.2.1
|
||
/ "compress" ; Section 6.2.2.1
|
||
/ "deflate" ; Section 6.2.2.2
|
||
/ "gzip" ; Section 6.2.2.3
|
||
/ transfer-extension
|
||
transfer-extension = token *( OWS ";" OWS transfer-parameter )
|
||
|
||
Parameters are in the form of attribute/value pairs.
|
||
|
||
transfer-parameter = attribute BWS "=" BWS value
|
||
attribute = token
|
||
value = word
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 34]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
All transfer-coding values are case-insensitive. HTTP/1.1 uses
|
||
transfer-coding values in the TE header field (Section 9.5) and in
|
||
the Transfer-Encoding header field (Section 9.7).
|
||
|
||
Transfer-codings are analogous to the Content-Transfer-Encoding
|
||
values of MIME, which were designed to enable safe transport of
|
||
binary data over a 7-bit transport service ([RFC2045], Section 6).
|
||
However, safe transport has a different focus for an 8bit-clean
|
||
transfer protocol. In HTTP, the only unsafe characteristic of
|
||
message-bodies is the difficulty in determining the exact message
|
||
body length (Section 3.3), or the desire to encrypt data over a
|
||
shared transport.
|
||
|
||
A server that receives a request message with a transfer-coding it
|
||
does not understand SHOULD respond with 501 (Not Implemented) and
|
||
then close the connection. A server MUST NOT send transfer-codings
|
||
to an HTTP/1.0 client.
|
||
|
||
6.2.1. Chunked Transfer Coding
|
||
|
||
The chunked encoding modifies the body of a message in order to
|
||
transfer it as a series of chunks, each with its own size indicator,
|
||
followed by an OPTIONAL trailer containing header fields. This
|
||
allows dynamically produced content to be transferred along with the
|
||
information necessary for the recipient to verify that it has
|
||
received the full message.
|
||
|
||
Chunked-Body = *chunk
|
||
last-chunk
|
||
trailer-part
|
||
CRLF
|
||
|
||
chunk = chunk-size *WSP [ chunk-ext ] CRLF
|
||
chunk-data CRLF
|
||
chunk-size = 1*HEXDIG
|
||
last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF
|
||
|
||
chunk-ext = *( ";" *WSP chunk-ext-name
|
||
[ "=" chunk-ext-val ] *WSP )
|
||
chunk-ext-name = token
|
||
chunk-ext-val = token / quoted-str-nf
|
||
chunk-data = 1*OCTET ; a sequence of chunk-size octets
|
||
trailer-part = *( header-field CRLF )
|
||
|
||
quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
|
||
; like quoted-string, but disallowing line folding
|
||
qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text
|
||
; WSP / <VCHAR except DQUOTE and "\"> / obs-text
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 35]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
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
|
||
whose size is zero, followed by the trailer, which is terminated by
|
||
an empty line.
|
||
|
||
The trailer allows the sender to include additional HTTP header
|
||
fields at the end of the message. The Trailer header field can be
|
||
used to indicate which header fields are included in a trailer (see
|
||
Section 9.6).
|
||
|
||
A server using chunked transfer-coding in a response MUST NOT use the
|
||
trailer for any header fields unless at least one of the following is
|
||
true:
|
||
|
||
1. the request included a TE header field that indicates "trailers"
|
||
is acceptable in the transfer-coding of the response, as
|
||
described in Section 9.5; or,
|
||
|
||
2. the server is the origin server for the response, the trailer
|
||
fields consist entirely of optional metadata, and the recipient
|
||
could use the message (in a manner acceptable to the origin
|
||
server) without receiving this metadata. In other words, the
|
||
origin server is willing to accept the possibility that the
|
||
trailer fields might be silently discarded along the path to the
|
||
client.
|
||
|
||
This requirement prevents an interoperability failure when the
|
||
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
|
||
compliance with the protocol would have necessitated a possibly
|
||
infinite buffer on the proxy.
|
||
|
||
A process for decoding the "chunked" transfer-coding can be
|
||
represented in pseudo-code as:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 36]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
length := 0
|
||
read chunk-size, chunk-ext (if any) and CRLF
|
||
while (chunk-size > 0) {
|
||
read chunk-data and CRLF
|
||
append chunk-data to decoded-body
|
||
length := length + chunk-size
|
||
read chunk-size and CRLF
|
||
}
|
||
read header-field
|
||
while (header-field not empty) {
|
||
append header-field to existing header fields
|
||
read header-field
|
||
}
|
||
Content-Length := length
|
||
Remove "chunked" from Transfer-Encoding
|
||
|
||
All HTTP/1.1 applications MUST be able to receive and decode the
|
||
"chunked" transfer-coding and MUST ignore chunk-ext extensions they
|
||
do not understand.
|
||
|
||
Since "chunked" is the only transfer-coding required to be understood
|
||
by HTTP/1.1 recipients, it plays a crucial role in delimiting
|
||
messages on a persistent connection. Whenever a transfer-coding is
|
||
applied to a payload body in a request, the final transfer-coding
|
||
applied MUST be "chunked". If a transfer-coding is applied to a
|
||
response payload body, then either the final transfer-coding applied
|
||
MUST be "chunked" or the message MUST be terminated by closing the
|
||
connection. When the "chunked" transfer-coding is used, it MUST be
|
||
the last transfer-coding applied to form the message-body. The
|
||
"chunked" transfer-coding MUST NOT be applied more than once in a
|
||
message-body.
|
||
|
||
6.2.2. Compression Codings
|
||
|
||
The codings defined below can be used to compress the payload of a
|
||
message.
|
||
|
||
Note: Use of program names for the identification of encoding
|
||
formats is not desirable and is discouraged for future encodings.
|
||
Their use here is representative of historical practice, not good
|
||
design.
|
||
|
||
Note: For compatibility with previous implementations of HTTP,
|
||
applications SHOULD consider "x-gzip" and "x-compress" to be
|
||
equivalent to "gzip" and "compress" respectively.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 37]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
6.2.2.1. Compress Coding
|
||
|
||
The "compress" format is produced by the common UNIX file compression
|
||
program "compress". This format is an adaptive Lempel-Ziv-Welch
|
||
coding (LZW).
|
||
|
||
6.2.2.2. Deflate Coding
|
||
|
||
The "deflate" format is defined as the "deflate" compression
|
||
mechanism (described in [RFC1951]) used inside the "zlib" data format
|
||
([RFC1950]).
|
||
|
||
Note: Some incorrect implementations send the "deflate" compressed
|
||
data without the zlib wrapper.
|
||
|
||
6.2.2.3. Gzip Coding
|
||
|
||
The "gzip" format is produced by the file compression program "gzip"
|
||
(GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv
|
||
coding (LZ77) with a 32 bit CRC.
|
||
|
||
6.2.3. Transfer Coding Registry
|
||
|
||
The HTTP Transfer Coding Registry defines the name space for the
|
||
transfer coding names.
|
||
|
||
Registrations MUST include the following fields:
|
||
|
||
o Name
|
||
|
||
o Description
|
||
|
||
o Pointer to specification text
|
||
|
||
Names of transfer codings MUST NOT overlap with names of content
|
||
codings (Section 2.2 of [Part3]), unless the encoding transformation
|
||
is identical (as it is the case for the compression codings defined
|
||
in Section 6.2.2).
|
||
|
||
Values to be added to this name space require a specification (see
|
||
"Specification Required" in Section 4.1 of [RFC5226]), and MUST
|
||
conform to the purpose of transfer coding defined in this section.
|
||
|
||
The registry itself is maintained at
|
||
<http://www.iana.org/assignments/http-parameters>.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 38]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
6.3. Product Tokens
|
||
|
||
Product tokens are used to allow communicating applications to
|
||
identify themselves by software name and version. Most fields using
|
||
product tokens also allow sub-products which form a significant part
|
||
of the application to be listed, separated by whitespace. By
|
||
convention, the products are listed in order of their significance
|
||
for identifying the application.
|
||
|
||
product = token ["/" product-version]
|
||
product-version = token
|
||
|
||
Examples:
|
||
|
||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
|
||
Server: Apache/0.8.4
|
||
|
||
Product tokens SHOULD be short and to the point. They MUST NOT be
|
||
used for advertising or other non-essential information. Although
|
||
any token character MAY appear in a product-version, this token
|
||
SHOULD only be used for a version identifier (i.e., successive
|
||
versions of the same product SHOULD only differ in the product-
|
||
version portion of the product value).
|
||
|
||
6.4. Quality Values
|
||
|
||
Both transfer codings (TE request header, Section 9.5) and content
|
||
negotiation (Section 5 of [Part3]) use short "floating point" numbers
|
||
to indicate the relative importance ("weight") of various negotiable
|
||
parameters. A weight is normalized to a real number in the range 0
|
||
through 1, where 0 is the minimum and 1 the maximum value. If a
|
||
parameter has a quality value of 0, then content with this parameter
|
||
is "not acceptable" for the client. HTTP/1.1 applications MUST NOT
|
||
generate more than three digits after the decimal point. User
|
||
configuration of these values SHOULD also be limited in this fashion.
|
||
|
||
qvalue = ( "0" [ "." 0*3DIGIT ] )
|
||
/ ( "1" [ "." 0*3("0") ] )
|
||
|
||
Note: "Quality values" is a misnomer, since these values merely
|
||
represent relative degradation in desired quality.
|
||
|
||
7. Connections
|
||
|
||
7.1. Persistent Connections
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 39]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
7.1.1. Purpose
|
||
|
||
Prior to persistent connections, a separate TCP connection was
|
||
established to fetch each URL, increasing the load on HTTP servers
|
||
and causing congestion on the Internet. The use of inline images and
|
||
other associated data often requires a client to make multiple
|
||
requests of the same server in a short amount of time. Analysis of
|
||
these performance problems and results from a prototype
|
||
implementation are available [Pad1995] [Spe]. Implementation
|
||
experience and measurements of actual HTTP/1.1 implementations show
|
||
good results [Nie1997]. Alternatives have also been explored, for
|
||
example, T/TCP [Tou1998].
|
||
|
||
Persistent HTTP connections have a number of advantages:
|
||
|
||
o By opening and closing fewer TCP connections, CPU time is saved in
|
||
routers and hosts (clients, servers, proxies, gateways, tunnels,
|
||
or caches), and memory used for TCP protocol control blocks can be
|
||
saved in hosts.
|
||
|
||
o HTTP requests and responses can be pipelined on a connection.
|
||
Pipelining allows a client to make multiple requests without
|
||
waiting for each response, allowing a single TCP connection to be
|
||
used much more efficiently, with much lower elapsed time.
|
||
|
||
o Network congestion is reduced by reducing the number of packets
|
||
caused by TCP opens, and by allowing TCP sufficient time to
|
||
determine the congestion state of the network.
|
||
|
||
o Latency on subsequent requests is reduced since there is no time
|
||
spent in TCP's connection opening handshake.
|
||
|
||
o HTTP can evolve more gracefully, since errors can be reported
|
||
without the penalty of closing the TCP connection. Clients using
|
||
future versions of HTTP might optimistically try a new feature,
|
||
but if communicating with an older server, retry with old
|
||
semantics after an error is reported.
|
||
|
||
HTTP implementations SHOULD implement persistent connections.
|
||
|
||
7.1.2. Overall Operation
|
||
|
||
A significant difference between HTTP/1.1 and earlier versions of
|
||
HTTP is that persistent connections are the default behavior of any
|
||
HTTP connection. That is, unless otherwise indicated, the client
|
||
SHOULD assume that the server will maintain a persistent connection,
|
||
even after error responses from the server.
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 40]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Persistent connections provide a mechanism by which a client and a
|
||
server can signal the close of a TCP connection. This signaling
|
||
takes place using the Connection header field (Section 9.1). Once a
|
||
close has been signaled, the client MUST NOT send any more requests
|
||
on that connection.
|
||
|
||
7.1.2.1. Negotiation
|
||
|
||
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
|
||
maintain a persistent connection unless a Connection header including
|
||
the connection-token "close" was sent in the request. If the server
|
||
chooses to close the connection immediately after sending the
|
||
response, it SHOULD send a Connection header including the
|
||
connection-token "close".
|
||
|
||
An HTTP/1.1 client MAY expect a connection to remain open, but would
|
||
decide to keep it open based on whether the response from a server
|
||
contains a Connection header with the connection-token close. In
|
||
case the client does not want to maintain a connection for more than
|
||
that request, it SHOULD send a Connection header including the
|
||
connection-token close.
|
||
|
||
If either the client or the server sends the close token in the
|
||
Connection header, that request becomes the last one for the
|
||
connection.
|
||
|
||
Clients and servers SHOULD NOT assume that a persistent connection is
|
||
maintained for HTTP versions less than 1.1 unless it is explicitly
|
||
signaled. See Appendix B.2 for more information on backward
|
||
compatibility with HTTP/1.0 clients.
|
||
|
||
In order to remain persistent, all messages on the connection MUST
|
||
have a self-defined message length (i.e., one not defined by closure
|
||
of the connection), as described in Section 3.3.
|
||
|
||
7.1.2.2. Pipelining
|
||
|
||
A client that supports persistent connections MAY "pipeline" its
|
||
requests (i.e., send multiple requests without waiting for each
|
||
response). A server MUST send its responses to those requests in the
|
||
same order that the requests were received.
|
||
|
||
Clients which assume persistent connections and pipeline immediately
|
||
after connection establishment SHOULD be prepared to retry their
|
||
connection if the first pipelined attempt fails. If a client does
|
||
such a retry, it MUST NOT pipeline before it knows the connection is
|
||
persistent. Clients MUST also be prepared to resend their requests
|
||
if the server closes the connection before sending all of the
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 41]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
corresponding responses.
|
||
|
||
Clients SHOULD NOT pipeline requests using non-idempotent methods or
|
||
non-idempotent sequences of methods (see Section 7.1.2 of [Part2]).
|
||
Otherwise, a premature termination of the transport connection could
|
||
lead to indeterminate results. A client wishing to send a non-
|
||
idempotent request SHOULD wait to send that request until it has
|
||
received the response status line for the previous request.
|
||
|
||
7.1.3. Proxy Servers
|
||
|
||
It is especially important that proxies correctly implement the
|
||
properties of the Connection header field as specified in
|
||
Section 9.1.
|
||
|
||
The proxy server MUST signal persistent connections separately with
|
||
its clients and the origin servers (or other proxy servers) that it
|
||
connects to. Each persistent connection applies to only one
|
||
transport link.
|
||
|
||
A proxy server MUST NOT establish a HTTP/1.1 persistent connection
|
||
with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
|
||
information and discussion of the problems with the Keep-Alive header
|
||
implemented by many HTTP/1.0 clients).
|
||
|
||
7.1.3.1. End-to-end and Hop-by-hop Headers
|
||
|
||
For the purpose of defining the behavior of caches and non-caching
|
||
proxies, we divide HTTP headers into two categories:
|
||
|
||
o End-to-end headers, which are transmitted to the ultimate
|
||
recipient of a request or response. End-to-end headers in
|
||
responses MUST be stored as part of a cache entry and MUST be
|
||
transmitted in any response formed from a cache entry.
|
||
|
||
o Hop-by-hop headers, which are meaningful only for a single
|
||
transport-level connection, and are not stored by caches or
|
||
forwarded by proxies.
|
||
|
||
The following HTTP/1.1 headers are hop-by-hop headers:
|
||
|
||
o Connection
|
||
|
||
o Keep-Alive
|
||
|
||
o Proxy-Authenticate
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 42]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
o Proxy-Authorization
|
||
|
||
o TE
|
||
|
||
o Trailer
|
||
|
||
o Transfer-Encoding
|
||
|
||
o Upgrade
|
||
|
||
All other headers defined by HTTP/1.1 are end-to-end headers.
|
||
|
||
Other hop-by-hop headers MUST be listed in a Connection header
|
||
(Section 9.1).
|
||
|
||
7.1.3.2. Non-modifiable Headers
|
||
|
||
Some features of HTTP/1.1, such as Digest Authentication, depend on
|
||
the value of certain end-to-end headers. A transparent proxy SHOULD
|
||
NOT modify an end-to-end header unless the definition of that header
|
||
requires or specifically allows that.
|
||
|
||
A transparent proxy MUST NOT modify any of the following fields in a
|
||
request or response, and it MUST NOT add any of these fields if not
|
||
already present:
|
||
|
||
o Content-Location
|
||
|
||
o Content-MD5
|
||
|
||
o ETag
|
||
|
||
o Last-Modified
|
||
|
||
A transparent proxy MUST NOT modify any of the following fields in a
|
||
response:
|
||
|
||
o Expires
|
||
|
||
but it MAY add any of these fields if not already present. If an
|
||
Expires header is added, it MUST be given a field-value identical to
|
||
that of the Date header in that response.
|
||
|
||
A proxy MUST NOT modify or add any of the following fields in a
|
||
message that contains the no-transform cache-control directive, or in
|
||
any request:
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 43]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
o Content-Encoding
|
||
|
||
o Content-Range
|
||
|
||
o Content-Type
|
||
|
||
A non-transparent proxy MAY modify or add these fields to a message
|
||
that does not include no-transform, but if it does so, it MUST add a
|
||
Warning 214 (Transformation applied) if one does not already appear
|
||
in the message (see Section 3.6 of [Part6]).
|
||
|
||
Warning: Unnecessary modification of end-to-end headers might
|
||
cause authentication failures if stronger authentication
|
||
mechanisms are introduced in later versions of HTTP. Such
|
||
authentication mechanisms MAY rely on the values of header fields
|
||
not listed here.
|
||
|
||
A transparent proxy MUST preserve the message payload ([Part3]),
|
||
though it MAY change the message-body through application or removal
|
||
of a transfer-coding (Section 6.2).
|
||
|
||
7.1.4. Practical Considerations
|
||
|
||
Servers will usually have some time-out value beyond which they will
|
||
no longer maintain an inactive connection. Proxy servers might make
|
||
this a higher value since it is likely that the client will be making
|
||
more connections through the same server. The use of persistent
|
||
connections places no requirements on the length (or existence) of
|
||
this time-out for either the client or the server.
|
||
|
||
When a client or server wishes to time-out it SHOULD issue a graceful
|
||
close on the transport connection. Clients and servers SHOULD both
|
||
constantly watch for the other side of the transport close, and
|
||
respond to it as appropriate. If a client or server does not detect
|
||
the other side's close promptly it could cause unnecessary resource
|
||
drain on the network.
|
||
|
||
A client, server, or proxy MAY close the transport connection at any
|
||
time. For example, a client might have started to send a new request
|
||
at the same time that the server has decided to close the "idle"
|
||
connection. From the server's point of view, the connection is being
|
||
closed while it was idle, but from the client's point of view, a
|
||
request is in progress.
|
||
|
||
This means that clients, servers, and proxies MUST be able to recover
|
||
from asynchronous close events. Client software SHOULD reopen the
|
||
transport connection and retransmit the aborted sequence of requests
|
||
without user interaction so long as the request sequence is
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 44]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or
|
||
sequences MUST NOT be automatically retried, although user agents MAY
|
||
offer a human operator the choice of retrying the request(s).
|
||
Confirmation by user-agent software with semantic understanding of
|
||
the application MAY substitute for user confirmation. The automatic
|
||
retry SHOULD NOT be repeated if the second sequence of requests
|
||
fails.
|
||
|
||
Servers SHOULD always respond to at least one request per connection,
|
||
if at all possible. Servers SHOULD NOT close a connection in the
|
||
middle of transmitting a response, unless a network or client failure
|
||
is suspected.
|
||
|
||
Clients (including proxies) SHOULD limit the number of simultaneous
|
||
connections that they maintain to a given server (including proxies).
|
||
|
||
Previous revisions of HTTP gave a specific number of connections as a
|
||
ceiling, but this was found to be impractical for many applications.
|
||
As a result, this specification does not mandate a particular maximum
|
||
number of connections, but instead encourages clients to be
|
||
conservative when opening multiple connections.
|
||
|
||
In particular, while using multiple connections avoids the "head-of-
|
||
line blocking" problem (whereby a request that takes significant
|
||
server-side processing and/or has a large payload can block
|
||
subsequent requests on the same connection), each connection used
|
||
consumes server resources (sometimes significantly), and furthermore
|
||
using multiple connections can cause undesirable side effects in
|
||
congested networks.
|
||
|
||
Note that servers might reject traffic that they deem abusive,
|
||
including an excessive number of connections from a client.
|
||
|
||
7.2. Message Transmission Requirements
|
||
|
||
7.2.1. Persistent Connections and Flow Control
|
||
|
||
HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
|
||
flow control mechanisms to resolve temporary overloads, rather than
|
||
terminating connections with the expectation that clients will retry.
|
||
The latter technique can exacerbate network congestion.
|
||
|
||
7.2.2. Monitoring Connections for Error Status Messages
|
||
|
||
An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
|
||
the network connection for an error status code while it is
|
||
transmitting the request. If the client sees an error status code,
|
||
it SHOULD immediately cease transmitting the body. If the body is
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 45]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
being sent using a "chunked" encoding (Section 6.2), a zero length
|
||
chunk and empty trailer MAY be used to prematurely mark the end of
|
||
the message. If the body was preceded by a Content-Length header,
|
||
the client MUST close the connection.
|
||
|
||
7.2.3. Use of the 100 (Continue) Status
|
||
|
||
The purpose of the 100 (Continue) status code (see Section 8.1.1 of
|
||
[Part2]) is to allow a client that is sending a request message with
|
||
a request body to determine if the origin server is willing to accept
|
||
the request (based on the request headers) before the client sends
|
||
the request body. In some cases, it might either be inappropriate or
|
||
highly inefficient for the client to send the body if the server will
|
||
reject the message without looking at the body.
|
||
|
||
Requirements for HTTP/1.1 clients:
|
||
|
||
o If a client will wait for a 100 (Continue) response before sending
|
||
the request body, it MUST send an Expect request-header field
|
||
(Section 9.2 of [Part2]) with the "100-continue" expectation.
|
||
|
||
o A client MUST NOT send an Expect request-header field (Section 9.2
|
||
of [Part2]) with the "100-continue" expectation if it does not
|
||
intend to send a request body.
|
||
|
||
Because of the presence of older implementations, the protocol allows
|
||
ambiguous situations in which a client might send "Expect: 100-
|
||
continue" without receiving either a 417 (Expectation Failed) or a
|
||
100 (Continue) status code. Therefore, when a client sends this
|
||
header field to an origin server (possibly via a proxy) from which it
|
||
has never seen a 100 (Continue) status code, the client SHOULD NOT
|
||
wait for an indefinite period before sending the request body.
|
||
|
||
Requirements for HTTP/1.1 origin servers:
|
||
|
||
o Upon receiving a request which includes an Expect request-header
|
||
field with the "100-continue" expectation, an origin server MUST
|
||
either respond with 100 (Continue) status code and continue to
|
||
read from the input stream, or respond with a final status code.
|
||
The origin server MUST NOT wait for the request body before
|
||
sending the 100 (Continue) response. If it responds with a final
|
||
status code, it MAY close the transport connection or it MAY
|
||
continue to read and discard the rest of the request. It MUST NOT
|
||
perform the requested method if it returns a final status code.
|
||
|
||
o An origin server SHOULD NOT send a 100 (Continue) response if the
|
||
request message does not include an Expect request-header field
|
||
with the "100-continue" expectation, and MUST NOT send a 100
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 46]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
(Continue) response if such a request comes from an HTTP/1.0 (or
|
||
earlier) client. There is an exception to this rule: for
|
||
compatibility with [RFC2068], a server MAY send a 100 (Continue)
|
||
status code in response to an HTTP/1.1 PUT or POST request that
|
||
does not include an Expect request-header field with the "100-
|
||
continue" expectation. This exception, the purpose of which is to
|
||
minimize any client processing delays associated with an
|
||
undeclared wait for 100 (Continue) status code, applies only to
|
||
HTTP/1.1 requests, and not to requests with any other HTTP-version
|
||
value.
|
||
|
||
o An origin server MAY omit a 100 (Continue) response if it has
|
||
already received some or all of the request body for the
|
||
corresponding request.
|
||
|
||
o An origin server that sends a 100 (Continue) response MUST
|
||
ultimately send a final status code, once the request body is
|
||
received and processed, unless it terminates the transport
|
||
connection prematurely.
|
||
|
||
o If an origin server receives a request that does not include an
|
||
Expect request-header field with the "100-continue" expectation,
|
||
the request includes a request body, and the server responds with
|
||
a final status code before reading the entire request body from
|
||
the transport connection, then the server SHOULD NOT close the
|
||
transport connection until it has read the entire request, or
|
||
until the client closes the connection. Otherwise, the client
|
||
might not reliably receive the response message. However, this
|
||
requirement is not be construed as preventing a server from
|
||
defending itself against denial-of-service attacks, or from badly
|
||
broken client implementations.
|
||
|
||
Requirements for HTTP/1.1 proxies:
|
||
|
||
o If a proxy receives a request that includes an Expect request-
|
||
header field with the "100-continue" expectation, and the proxy
|
||
either knows that the next-hop server complies with HTTP/1.1 or
|
||
higher, or does not know the HTTP version of the next-hop server,
|
||
it MUST forward the request, including the Expect header field.
|
||
|
||
o If the proxy knows that the version of the next-hop server is
|
||
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
|
||
respond with a 417 (Expectation Failed) status code.
|
||
|
||
o Proxies SHOULD maintain a cache recording the HTTP version numbers
|
||
received from recently-referenced next-hop servers.
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 47]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
o A proxy MUST NOT forward a 100 (Continue) response if the request
|
||
message was received from an HTTP/1.0 (or earlier) client and did
|
||
not include an Expect request-header field with the "100-continue"
|
||
expectation. This requirement overrides the general rule for
|
||
forwarding of 1xx responses (see Section 8.1 of [Part2]).
|
||
|
||
7.2.4. Client Behavior if Server Prematurely Closes Connection
|
||
|
||
If an HTTP/1.1 client sends a request which includes a request body,
|
||
but which does not include an Expect request-header field with the
|
||
"100-continue" expectation, and if the client is not directly
|
||
connected to an HTTP/1.1 origin server, and if the client sees the
|
||
connection close before receiving a status line from the server, the
|
||
client SHOULD retry the request. If the client does retry this
|
||
request, it MAY use the following "binary exponential backoff"
|
||
algorithm to be assured of obtaining a reliable response:
|
||
|
||
1. Initiate a new connection to the server
|
||
|
||
2. Transmit the request-headers
|
||
|
||
3. Initialize a variable R to the estimated round-trip time to the
|
||
server (e.g., based on the time it took to establish the
|
||
connection), or to a constant value of 5 seconds if the round-
|
||
trip time is not available.
|
||
|
||
4. Compute T = R * (2**N), where N is the number of previous retries
|
||
of this request.
|
||
|
||
5. Wait either for an error response from the server, or for T
|
||
seconds (whichever comes first)
|
||
|
||
6. If no error response is received, after T seconds transmit the
|
||
body of the request.
|
||
|
||
7. If client sees that the connection is closed prematurely, repeat
|
||
from step 1 until the request is accepted, an error response is
|
||
received, or the user becomes impatient and terminates the retry
|
||
process.
|
||
|
||
If at any point an error status code is received, the client
|
||
|
||
o SHOULD NOT continue and
|
||
|
||
o SHOULD close the connection if it has not completed sending the
|
||
request message.
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 48]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
8. Miscellaneous notes that might disappear
|
||
|
||
8.1. Scheme aliases considered harmful
|
||
|
||
[[TBD-aliases-harmful: describe why aliases like webcal are
|
||
harmful.]]
|
||
|
||
8.2. Use of HTTP for proxy communication
|
||
|
||
[[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other
|
||
protocols.]]
|
||
|
||
8.3. Interception of HTTP for access control
|
||
|
||
[[TBD-intercept: Interception of HTTP traffic for initiating access
|
||
control.]]
|
||
|
||
8.4. Use of HTTP by other protocols
|
||
|
||
[[TBD-profiles: Profiles of HTTP defined by other protocol.
|
||
Extensions of HTTP like WebDAV.]]
|
||
|
||
8.5. Use of HTTP by media type specification
|
||
|
||
[[TBD-hypertext: Instructions on composing HTTP requests via
|
||
hypertext formats.]]
|
||
|
||
9. Header Field Definitions
|
||
|
||
This section defines the syntax and semantics of HTTP/1.1 header
|
||
fields related to message framing and transport protocols.
|
||
|
||
9.1. Connection
|
||
|
||
The "Connection" general-header field allows the sender to specify
|
||
options that are desired for that particular connection and MUST NOT
|
||
be communicated by proxies over further connections.
|
||
|
||
The Connection header's value has the following grammar:
|
||
|
||
Connection = "Connection" ":" OWS Connection-v
|
||
Connection-v = 1#connection-token
|
||
connection-token = token
|
||
|
||
HTTP/1.1 proxies MUST parse the Connection header field before a
|
||
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
|
||
connection-token. Connection options are signaled by the presence of
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 49]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
a connection-token in the Connection header field, not by any
|
||
corresponding additional header field(s), since the additional header
|
||
field might not be sent if there are no parameters associated with
|
||
that connection option.
|
||
|
||
Message headers listed in the Connection header MUST NOT include end-
|
||
to-end headers, such as Cache-Control.
|
||
|
||
HTTP/1.1 defines the "close" connection option for the sender to
|
||
signal that the connection will be closed after completion of the
|
||
response. For example,
|
||
|
||
Connection: close
|
||
|
||
in either the request or the response header fields indicates that
|
||
the connection SHOULD NOT be considered "persistent" (Section 7.1)
|
||
after the current request/response is complete.
|
||
|
||
An HTTP/1.1 client that does not support persistent connections MUST
|
||
include the "close" connection option in every request message.
|
||
|
||
An HTTP/1.1 server that does not support persistent connections MUST
|
||
include the "close" connection option in every response message that
|
||
does not have a 1xx (Informational) status code.
|
||
|
||
A system receiving an HTTP/1.0 (or lower-version) message that
|
||
includes a Connection header MUST, for each connection-token in this
|
||
field, remove and ignore any header field(s) from the message with
|
||
the same name as the connection-token. This protects against
|
||
mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
|
||
See Appendix B.2.
|
||
|
||
9.2. Content-Length
|
||
|
||
The "Content-Length" header field indicates the size of the message-
|
||
body, in decimal number of octets, for any message other than a
|
||
response to the HEAD method or a response with a status code of 304.
|
||
In the case of responses to the HEAD method, it indicates the size of
|
||
the payload body (not including any potential transfer-coding) that
|
||
would have been sent had the request been a GET. In the case of the
|
||
304 (Not Modified) response, it indicates the size of the payload
|
||
body (not including any potential transfer-coding) that would have
|
||
been sent in a 200 (OK) response.
|
||
|
||
Content-Length = "Content-Length" ":" OWS 1*Content-Length-v
|
||
Content-Length-v = 1*DIGIT
|
||
|
||
An example is
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 50]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Content-Length: 3495
|
||
|
||
Implementations SHOULD use this field to indicate the message-body
|
||
length when no transfer-coding is being applied and the payload's
|
||
body length can be determined prior to being transferred.
|
||
Section 3.3 describes how recipients determine the length of a
|
||
message-body.
|
||
|
||
Any Content-Length greater than or equal to zero is a valid value.
|
||
|
||
Note that the use of this field in HTTP is significantly different
|
||
from the corresponding definition in MIME, where it is an optional
|
||
field used within the "message/external-body" content-type.
|
||
|
||
9.3. Date
|
||
|
||
The "Date" general-header field represents the date and time at which
|
||
the message was originated, having the same semantics as the
|
||
Origination Date Field (orig-date) defined in Section 3.6.1 of
|
||
[RFC5322]. The field value is an HTTP-date, as described in
|
||
Section 6.1; it MUST be sent in rfc1123-date format.
|
||
|
||
Date = "Date" ":" OWS Date-v
|
||
Date-v = HTTP-date
|
||
|
||
An example is
|
||
|
||
Date: Tue, 15 Nov 1994 08:12:31 GMT
|
||
|
||
Origin servers MUST include a Date header field in all responses,
|
||
except in these cases:
|
||
|
||
1. If the response status code is 100 (Continue) or 101 (Switching
|
||
Protocols), the response MAY include a Date header field, at the
|
||
server's option.
|
||
|
||
2. If the response status code conveys a server error, e.g., 500
|
||
(Internal Server Error) or 503 (Service Unavailable), and it is
|
||
inconvenient or impossible to generate a valid Date.
|
||
|
||
3. If the server does not have a clock that can provide a reasonable
|
||
approximation of the current time, its responses MUST NOT include
|
||
a Date header field. In this case, the rules in Section 9.3.1
|
||
MUST be followed.
|
||
|
||
A received message that does not have a Date header field MUST be
|
||
assigned one by the recipient if the message will be cached by that
|
||
recipient or gatewayed via a protocol which requires a Date. An HTTP
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 51]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
implementation without a clock MUST NOT cache responses without
|
||
revalidating them on every use. An HTTP cache, especially a shared
|
||
cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize
|
||
its clock with a reliable external standard.
|
||
|
||
Clients SHOULD only send a Date header field in messages that include
|
||
a payload, as is usually the case for PUT and POST requests, and even
|
||
then it is optional. A client without a clock MUST NOT send a Date
|
||
header field in a request.
|
||
|
||
The HTTP-date sent in a Date header SHOULD NOT represent a date and
|
||
time subsequent to the generation of the message. It SHOULD
|
||
represent the best available approximation of the date and time of
|
||
message generation, unless the implementation has no means of
|
||
generating a reasonably accurate date and time. In theory, the date
|
||
ought to represent the moment just before the payload is generated.
|
||
In practice, the date can be generated at any time during the message
|
||
origination without affecting its semantic value.
|
||
|
||
9.3.1. Clockless Origin Server Operation
|
||
|
||
Some origin server implementations might not have a clock available.
|
||
An origin server without a clock MUST NOT assign Expires or Last-
|
||
Modified values to a response, unless these values were associated
|
||
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
|
||
configuration time, to be in the past (this allows "pre-expiration"
|
||
of responses without storing separate Expires values for each
|
||
resource).
|
||
|
||
9.4. Host
|
||
|
||
The "Host" request-header field specifies the Internet host and port
|
||
number of the resource being requested, allowing the origin server or
|
||
gateway to differentiate between internally-ambiguous URLs, such as
|
||
the root "/" URL of a server for multiple host names on a single IP
|
||
address.
|
||
|
||
The Host field value MUST represent the naming authority of the
|
||
origin server or gateway given by the original URL obtained from the
|
||
user or referring resource (generally an http URI, as described in
|
||
Section 2.6.1).
|
||
|
||
Host = "Host" ":" OWS Host-v
|
||
Host-v = uri-host [ ":" port ] ; Section 2.6.1
|
||
|
||
A "host" without any trailing port information implies the default
|
||
port for the service requested (e.g., "80" for an HTTP URL). For
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 52]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
example, a request on the origin server for
|
||
<http://www.example.org/pub/WWW/> would properly include:
|
||
|
||
GET /pub/WWW/ HTTP/1.1
|
||
Host: www.example.org
|
||
|
||
A client MUST include a Host header field in all HTTP/1.1 request
|
||
messages. If the requested URI does not include an Internet host
|
||
name for the service being requested, then the Host header field MUST
|
||
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
|
||
request message it forwards does contain an appropriate Host header
|
||
field that identifies the service being requested by the proxy. All
|
||
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
|
||
field.
|
||
|
||
See Sections 4.2 and B.1.1 for other requirements relating to Host.
|
||
|
||
9.5. TE
|
||
|
||
The "TE" request-header field indicates what extension transfer-
|
||
codings it is willing to accept in the response, and whether or not
|
||
it is willing to accept trailer fields in a chunked transfer-coding.
|
||
|
||
Its value consists of the keyword "trailers" and/or a comma-separated
|
||
list of extension transfer-coding names with optional accept
|
||
parameters (as described in Section 6.2).
|
||
|
||
TE = "TE" ":" OWS TE-v
|
||
TE-v = #t-codings
|
||
t-codings = "trailers" / ( transfer-extension [ te-params ] )
|
||
te-params = OWS ";" OWS "q=" qvalue *( te-ext )
|
||
te-ext = OWS ";" OWS token [ "=" word ]
|
||
|
||
The presence of the keyword "trailers" indicates that the client is
|
||
willing to accept trailer fields in a chunked transfer-coding, as
|
||
defined in Section 6.2.1. This keyword is reserved for use with
|
||
transfer-coding values even though it does not itself represent a
|
||
transfer-coding.
|
||
|
||
Examples of its use are:
|
||
|
||
TE: deflate
|
||
TE:
|
||
TE: trailers, deflate;q=0.5
|
||
|
||
The TE header field only applies to the immediate connection.
|
||
Therefore, the keyword MUST be supplied within a Connection header
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 53]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
field (Section 9.1) whenever TE is present in an HTTP/1.1 message.
|
||
|
||
A server tests whether a transfer-coding is acceptable, according to
|
||
a TE field, using these rules:
|
||
|
||
1. The "chunked" transfer-coding is always acceptable. If the
|
||
keyword "trailers" is listed, the client indicates that it is
|
||
willing to accept trailer fields in the chunked response on
|
||
behalf of itself and any downstream clients. The implication is
|
||
that, if given, the client is stating that either all downstream
|
||
clients are willing to accept trailer fields in the forwarded
|
||
response, or that it will attempt to buffer the response on
|
||
behalf of downstream recipients.
|
||
|
||
Note: HTTP/1.1 does not define any means to limit the size of a
|
||
chunked response such that a client can be assured of buffering
|
||
the entire response.
|
||
|
||
2. If the transfer-coding being tested is one of the transfer-
|
||
codings listed in the TE field, then it is acceptable unless it
|
||
is accompanied by a qvalue of 0. (As defined in Section 6.4, a
|
||
qvalue of 0 means "not acceptable".)
|
||
|
||
3. If multiple transfer-codings are acceptable, then the acceptable
|
||
transfer-coding with the highest non-zero qvalue is preferred.
|
||
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
|
||
transfer-coding is "chunked". A message with no transfer-coding is
|
||
always acceptable.
|
||
|
||
9.6. Trailer
|
||
|
||
The "Trailer" general-header field indicates that the given set of
|
||
header fields is present in the trailer of a message encoded with
|
||
chunked transfer-coding.
|
||
|
||
Trailer = "Trailer" ":" OWS Trailer-v
|
||
Trailer-v = 1#field-name
|
||
|
||
An HTTP/1.1 message SHOULD include a Trailer header field in a
|
||
message using chunked transfer-coding with a non-empty trailer.
|
||
Doing so allows the recipient to know which header fields to expect
|
||
in the trailer.
|
||
|
||
If no Trailer header field is present, the trailer SHOULD NOT include
|
||
any header fields. See Section 6.2.1 for restrictions on the use of
|
||
trailer fields in a "chunked" transfer-coding.
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 54]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Message header fields listed in the Trailer header field MUST NOT
|
||
include the following header fields:
|
||
|
||
o Transfer-Encoding
|
||
|
||
o Content-Length
|
||
|
||
o Trailer
|
||
|
||
9.7. Transfer-Encoding
|
||
|
||
The "Transfer-Encoding" general-header field indicates what transfer-
|
||
codings (if any) have been applied to the message body. It differs
|
||
from Content-Encoding (Section 2.2 of [Part3]) in that transfer-
|
||
codings are a property of the message (and therefore are removed by
|
||
intermediaries), whereas content-codings are not.
|
||
|
||
Transfer-Encoding = "Transfer-Encoding" ":" OWS
|
||
Transfer-Encoding-v
|
||
Transfer-Encoding-v = 1#transfer-coding
|
||
|
||
Transfer-codings are defined in Section 6.2. An example is:
|
||
|
||
Transfer-Encoding: chunked
|
||
|
||
If multiple encodings have been applied to a representation, the
|
||
transfer-codings MUST be listed in the order in which they were
|
||
applied. Additional information about the encoding parameters MAY be
|
||
provided by other header fields not defined by this specification.
|
||
|
||
Many older HTTP/1.0 applications do not understand the Transfer-
|
||
Encoding header.
|
||
|
||
9.8. Upgrade
|
||
|
||
The "Upgrade" general-header field allows the client to specify what
|
||
additional communication protocols it would like to use, if the
|
||
server chooses to switch protocols. Additionally, the server MUST
|
||
use the Upgrade header field within a 101 (Switching Protocols)
|
||
response to indicate which protocol(s) are being switched to.
|
||
|
||
Upgrade = "Upgrade" ":" OWS Upgrade-v
|
||
Upgrade-v = 1#product
|
||
|
||
For example,
|
||
|
||
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 55]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
The Upgrade header field is intended to provide a simple mechanism
|
||
for transition from HTTP/1.1 to some other, incompatible protocol.
|
||
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
|
||
version number, even though the current request has been made using
|
||
HTTP/1.1. This eases the difficult transition between incompatible
|
||
protocols by allowing the client to initiate a request in the more
|
||
commonly supported protocol while indicating to the server that it
|
||
would like to use a "better" protocol if available (where "better" is
|
||
determined by the server, possibly according to the nature of the
|
||
method and/or resource being requested).
|
||
|
||
The Upgrade header field only applies to switching application-layer
|
||
protocols upon the existing transport-layer connection. Upgrade
|
||
cannot be used to insist on a protocol change; its acceptance and use
|
||
by the server is optional. The capabilities and nature of the
|
||
application-layer communication after the protocol change is entirely
|
||
dependent upon the new protocol chosen, although the first action
|
||
after changing the protocol MUST be a response to the initial HTTP
|
||
request containing the Upgrade header field.
|
||
|
||
The Upgrade header field only applies to the immediate connection.
|
||
Therefore, the upgrade keyword MUST be supplied within a Connection
|
||
header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1
|
||
message.
|
||
|
||
The Upgrade header field cannot be used to indicate a switch to a
|
||
protocol on a different connection. For that purpose, it is more
|
||
appropriate to use a 301, 302, 303, or 305 redirection response.
|
||
|
||
This specification only defines the protocol name "HTTP" for use by
|
||
the family of Hypertext Transfer Protocols, as defined by the HTTP
|
||
version rules of Section 2.5 and future updates to this
|
||
specification. Additional tokens can be registered with IANA using
|
||
the registration procedure defined below.
|
||
|
||
9.8.1. Upgrade Token Registry
|
||
|
||
The HTTP Upgrade Token Registry defines the name space for product
|
||
tokens used to identify protocols in the Upgrade header field. Each
|
||
registered token is associated with contact information and an
|
||
optional set of specifications that details how the connection will
|
||
be processed after it has been upgraded.
|
||
|
||
Registrations are allowed on a First Come First Served basis as
|
||
described in Section 4.1 of [RFC5226]. The specifications need not
|
||
be IETF documents or be subject to IESG review. Registrations are
|
||
subject to the following rules:
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 56]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
1. A token, once registered, stays registered forever.
|
||
|
||
2. The registration MUST name a responsible party for the
|
||
registration.
|
||
|
||
3. The registration MUST name a point of contact.
|
||
|
||
4. The registration MAY name a set of specifications associated with
|
||
that token. Such specifications need not be publicly available.
|
||
|
||
5. The responsible party MAY change the registration at any time.
|
||
The IANA will keep a record of all such changes, and make them
|
||
available upon request.
|
||
|
||
6. The responsible party for the first registration of a "product"
|
||
token MUST approve later registrations of a "version" token
|
||
together with that "product" token before they can be registered.
|
||
|
||
7. If absolutely required, the IESG MAY reassign the responsibility
|
||
for a token. This will normally only be used in the case when a
|
||
responsible party cannot be contacted.
|
||
|
||
9.9. Via
|
||
|
||
The "Via" general-header field MUST be used by gateways and proxies
|
||
to indicate the intermediate protocols and recipients between the
|
||
user agent and the server on requests, and between the origin server
|
||
and the client on responses. It is analogous to the "Received" field
|
||
defined in Section 3.6.7 of [RFC5322] and is intended to be used for
|
||
tracking message forwards, avoiding request loops, and identifying
|
||
the protocol capabilities of all senders along the request/response
|
||
chain.
|
||
|
||
Via = "Via" ":" OWS Via-v
|
||
Via-v = 1#( received-protocol RWS received-by
|
||
[ RWS comment ] )
|
||
received-protocol = [ protocol-name "/" ] protocol-version
|
||
protocol-name = token
|
||
protocol-version = token
|
||
received-by = ( uri-host [ ":" port ] ) / pseudonym
|
||
pseudonym = token
|
||
|
||
The received-protocol indicates the protocol version of the message
|
||
received by the server or client along each segment of the request/
|
||
response chain. The received-protocol version is appended to the Via
|
||
field value when the message is forwarded so that information about
|
||
the protocol capabilities of upstream applications remains visible to
|
||
all recipients.
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 57]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
The protocol-name is optional if and only if it would be "HTTP". The
|
||
received-by field is normally the host and optional port number of a
|
||
recipient server or client that subsequently forwarded the message.
|
||
However, if the real host is considered to be sensitive information,
|
||
it MAY be replaced by a pseudonym. If the port is not given, it MAY
|
||
be assumed to be the default port of the received-protocol.
|
||
|
||
Multiple Via field values represent each proxy or gateway that has
|
||
forwarded the message. Each recipient MUST append its information
|
||
such that the end result is ordered according to the sequence of
|
||
forwarding applications.
|
||
|
||
Comments MAY be used in the Via header field to identify the software
|
||
of the recipient proxy or gateway, analogous to the User-Agent and
|
||
Server header fields. However, all comments in the Via field are
|
||
optional and MAY be removed by any recipient prior to forwarding the
|
||
message.
|
||
|
||
For example, a request message could be sent from an HTTP/1.0 user
|
||
agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
|
||
forward the request to a public proxy at p.example.net, which
|
||
completes the request by forwarding it to the origin server at
|
||
www.example.com. The request received by www.example.com would then
|
||
have the following Via header field:
|
||
|
||
Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
|
||
|
||
Proxies and gateways used as a portal through a network firewall
|
||
SHOULD NOT, by default, forward the names and ports of hosts within
|
||
the firewall region. This information SHOULD only be propagated if
|
||
explicitly enabled. If not enabled, the received-by host of any host
|
||
behind the firewall SHOULD be replaced by an appropriate pseudonym
|
||
for that host.
|
||
|
||
For organizations that have strong privacy requirements for hiding
|
||
internal structures, a proxy MAY combine an ordered subsequence of
|
||
Via header field entries with identical received-protocol values into
|
||
a single such entry. For example,
|
||
|
||
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
|
||
|
||
could be collapsed to
|
||
|
||
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
|
||
|
||
Applications SHOULD NOT combine multiple entries unless they are all
|
||
under the same organizational control and the hosts have already been
|
||
replaced by pseudonyms. Applications MUST NOT combine entries which
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 58]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
have different received-protocol values.
|
||
|
||
10. IANA Considerations
|
||
|
||
10.1. Header Field Registration
|
||
|
||
The Message Header Field Registry located at <http://www.iana.org/
|
||
assignments/message-headers/message-header-index.html> shall be
|
||
updated with the permanent registrations below (see [RFC3864]):
|
||
|
||
+-------------------+----------+----------+-------------+
|
||
| Header Field Name | Protocol | Status | Reference |
|
||
+-------------------+----------+----------+-------------+
|
||
| Connection | http | standard | Section 9.1 |
|
||
| Content-Length | http | standard | Section 9.2 |
|
||
| Date | http | standard | Section 9.3 |
|
||
| Host | http | standard | Section 9.4 |
|
||
| TE | http | standard | Section 9.5 |
|
||
| Trailer | http | standard | Section 9.6 |
|
||
| Transfer-Encoding | http | standard | Section 9.7 |
|
||
| Upgrade | http | standard | Section 9.8 |
|
||
| Via | http | standard | Section 9.9 |
|
||
+-------------------+----------+----------+-------------+
|
||
|
||
The change controller is: "IETF (iesg@ietf.org) - Internet
|
||
Engineering Task Force".
|
||
|
||
10.2. URI Scheme Registration
|
||
|
||
The entries for the "http" and "https" URI Schemes in the registry
|
||
located at <http://www.iana.org/assignments/uri-schemes.html> shall
|
||
be updated to point to Sections 2.6.1 and 2.6.2 of this document (see
|
||
[RFC4395]).
|
||
|
||
10.3. Internet Media Type Registrations
|
||
|
||
This document serves as the specification for the Internet media
|
||
types "message/http" and "application/http". The following is to be
|
||
registered with IANA (see [RFC4288]).
|
||
|
||
10.3.1. Internet Media Type message/http
|
||
|
||
The message/http type can be used to enclose a single HTTP request or
|
||
response message, provided that it obeys the MIME restrictions for
|
||
all "message" types regarding line length and encodings.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 59]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Type name: message
|
||
|
||
Subtype name: http
|
||
|
||
Required parameters: none
|
||
|
||
Optional parameters: version, msgtype
|
||
|
||
version: The HTTP-Version number of the enclosed message (e.g.,
|
||
"1.1"). If not present, the version can be determined from the
|
||
first line of the body.
|
||
|
||
msgtype: The message type -- "request" or "response". If not
|
||
present, the type can be determined from the first line of the
|
||
body.
|
||
|
||
Encoding considerations: only "7bit", "8bit", or "binary" are
|
||
permitted
|
||
|
||
Security considerations: none
|
||
|
||
Interoperability considerations: none
|
||
|
||
Published specification: This specification (see Section 10.3.1).
|
||
|
||
Applications that use this media type:
|
||
|
||
Additional information:
|
||
|
||
Magic number(s): none
|
||
|
||
File extension(s): none
|
||
|
||
Macintosh file type code(s): none
|
||
|
||
Person and email address to contact for further information: See
|
||
Authors Section.
|
||
|
||
Intended usage: COMMON
|
||
|
||
Restrictions on usage: none
|
||
|
||
Author/Change controller: IESG
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 60]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
10.3.2. Internet Media Type application/http
|
||
|
||
The application/http type can be used to enclose a pipeline of one or
|
||
more HTTP request or response messages (not intermixed).
|
||
|
||
Type name: application
|
||
|
||
Subtype name: http
|
||
|
||
Required parameters: none
|
||
|
||
Optional parameters: version, msgtype
|
||
|
||
version: The HTTP-Version number of the enclosed messages (e.g.,
|
||
"1.1"). If not present, the version can be determined from the
|
||
first line of the body.
|
||
|
||
msgtype: The message type -- "request" or "response". If not
|
||
present, the type can be determined from the first line of the
|
||
body.
|
||
|
||
Encoding considerations: HTTP messages enclosed by this type are in
|
||
"binary" format; use of an appropriate Content-Transfer-Encoding
|
||
is required when transmitted via E-mail.
|
||
|
||
Security considerations: none
|
||
|
||
Interoperability considerations: none
|
||
|
||
Published specification: This specification (see Section 10.3.2).
|
||
|
||
Applications that use this media type:
|
||
|
||
Additional information:
|
||
|
||
Magic number(s): none
|
||
|
||
File extension(s): none
|
||
|
||
Macintosh file type code(s): none
|
||
|
||
Person and email address to contact for further information: See
|
||
Authors Section.
|
||
|
||
Intended usage: COMMON
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 61]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Restrictions on usage: none
|
||
|
||
Author/Change controller: IESG
|
||
|
||
10.4. Transfer Coding Registry
|
||
|
||
The registration procedure for HTTP Transfer Codings is now defined
|
||
by Section 6.2.3 of this document.
|
||
|
||
The HTTP Transfer Codings Registry located at
|
||
<http://www.iana.org/assignments/http-parameters> shall be updated
|
||
with the registrations below:
|
||
|
||
+----------+--------------------------------------+-----------------+
|
||
| Name | Description | Reference |
|
||
+----------+--------------------------------------+-----------------+
|
||
| chunked | Transfer in a series of chunks | Section 6.2.1 |
|
||
| compress | UNIX "compress" program method | Section 6.2.2.1 |
|
||
| deflate | "deflate" compression mechanism | Section 6.2.2.2 |
|
||
| | ([RFC1951]) used inside the "zlib" | |
|
||
| | data format ([RFC1950]) | |
|
||
| gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 |
|
||
+----------+--------------------------------------+-----------------+
|
||
|
||
10.5. Upgrade Token Registration
|
||
|
||
The registration procedure for HTTP Upgrade Tokens -- previously
|
||
defined in Section 7.2 of [RFC2817] -- is now defined by
|
||
Section 9.8.1 of this document.
|
||
|
||
The HTTP Status Code Registry located at
|
||
<http://www.iana.org/assignments/http-upgrade-tokens/> shall be
|
||
updated with the registration below:
|
||
|
||
+-------+---------------------------+-------------------------------+
|
||
| Value | Description | Reference |
|
||
+-------+---------------------------+-------------------------------+
|
||
| HTTP | Hypertext Transfer | Section 2.5 of this |
|
||
| | Protocol | specification |
|
||
+-------+---------------------------+-------------------------------+
|
||
|
||
11. Security Considerations
|
||
|
||
This section is meant to inform application developers, information
|
||
providers, and users of the security limitations in HTTP/1.1 as
|
||
described by this document. The discussion does not include
|
||
definitive solutions to the problems revealed, though it does make
|
||
some suggestions for reducing security risks.
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 62]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
11.1. Personal Information
|
||
|
||
HTTP clients are often privy to large amounts of personal information
|
||
(e.g., the user's name, location, mail address, passwords, encryption
|
||
keys, etc.), and SHOULD be very careful to prevent unintentional
|
||
leakage of this information. We very strongly recommend that a
|
||
convenient interface be provided for the user to control
|
||
dissemination of such information, and that designers and
|
||
implementors be particularly careful in this area. History shows
|
||
that errors in this area often create serious security and/or privacy
|
||
problems and generate highly adverse publicity for the implementor's
|
||
company.
|
||
|
||
11.2. Abuse of Server Log Information
|
||
|
||
A server is in the position to save personal data about a user's
|
||
requests which might identify their reading patterns or subjects of
|
||
interest. This information is clearly confidential in nature and its
|
||
handling can be constrained by law in certain countries. People
|
||
using HTTP to provide data are responsible for ensuring that such
|
||
material is not distributed without the permission of any individuals
|
||
that are identifiable by the published results.
|
||
|
||
11.3. Attacks Based On File and Path Names
|
||
|
||
Implementations of HTTP origin servers SHOULD be careful to restrict
|
||
the documents returned by HTTP requests to be only those that were
|
||
intended by the server administrators. If an HTTP server translates
|
||
HTTP URIs directly into file system calls, the server MUST take
|
||
special care not to serve files that were not intended to be
|
||
delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
|
||
other operating systems use ".." as a path component to indicate a
|
||
directory level above the current one. On such a system, an HTTP
|
||
server MUST disallow any such construct in the request-target if it
|
||
would otherwise allow access to a resource outside those intended to
|
||
be accessible via the HTTP server. Similarly, files intended for
|
||
reference only internally to the server (such as access control
|
||
files, configuration files, and script code) MUST be protected from
|
||
inappropriate retrieval, since they might contain sensitive
|
||
information. Experience has shown that minor bugs in such HTTP
|
||
server implementations have turned into security risks.
|
||
|
||
11.4. DNS Spoofing
|
||
|
||
Clients using HTTP rely heavily on the Domain Name Service, and are
|
||
thus generally prone to security attacks based on the deliberate mis-
|
||
association of IP addresses and DNS names. Clients need to be
|
||
cautious in assuming the continuing validity of an IP number/DNS name
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 63]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
association.
|
||
|
||
In particular, HTTP clients SHOULD rely on their name resolver for
|
||
confirmation of an IP number/DNS name association, rather than
|
||
caching the result of previous host name lookups. Many platforms
|
||
already can cache host name lookups locally when appropriate, and
|
||
they SHOULD be configured to do so. It is proper for these lookups
|
||
to be cached, however, only when the TTL (Time To Live) information
|
||
reported by the name server makes it likely that the cached
|
||
information will remain useful.
|
||
|
||
If HTTP clients cache the results of host name lookups in order to
|
||
achieve a performance improvement, they MUST observe the TTL
|
||
information reported by DNS.
|
||
|
||
If HTTP clients do not observe this rule, they could be spoofed when
|
||
a previously-accessed server's IP address changes. As network
|
||
renumbering is expected to become increasingly common [RFC1900], the
|
||
possibility of this form of attack will grow. Observing this
|
||
requirement thus reduces this potential security vulnerability.
|
||
|
||
This requirement also improves the load-balancing behavior of clients
|
||
for replicated servers using the same DNS name and reduces the
|
||
likelihood of a user's experiencing failure in accessing sites which
|
||
use that strategy.
|
||
|
||
11.5. Proxies and Caching
|
||
|
||
By their very nature, HTTP proxies are men-in-the-middle, and
|
||
represent an opportunity for man-in-the-middle attacks. Compromise
|
||
of the systems on which the proxies run can result in serious
|
||
security and privacy problems. Proxies have access to security-
|
||
related information, personal information about individual users and
|
||
organizations, and proprietary information belonging to users and
|
||
content providers. A compromised proxy, or a proxy implemented or
|
||
configured without regard to security and privacy considerations,
|
||
might be used in the commission of a wide range of potential attacks.
|
||
|
||
Proxy operators need to protect the systems on which proxies run as
|
||
they would protect any system that contains or transports sensitive
|
||
information. In particular, log information gathered at proxies
|
||
often contains highly sensitive personal information, and/or
|
||
information about organizations. Log information needs to be
|
||
carefully guarded, and appropriate guidelines for use need to be
|
||
developed and followed. (Section 11.2).
|
||
|
||
Proxy implementors need to consider the privacy and security
|
||
implications of their design and coding decisions, and of the
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 64]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
configuration options they provide to proxy operators (especially the
|
||
default configuration).
|
||
|
||
Users of a proxy need to be aware that proxies are no trustworthier
|
||
than the people who run them; HTTP itself cannot solve this problem.
|
||
|
||
The judicious use of cryptography, when appropriate, might suffice to
|
||
protect against a broad range of security and privacy attacks. Such
|
||
cryptography is beyond the scope of the HTTP/1.1 specification.
|
||
|
||
11.6. Denial of Service Attacks on Proxies
|
||
|
||
They exist. They are hard to defend against. Research continues.
|
||
Beware.
|
||
|
||
12. Acknowledgments
|
||
|
||
HTTP has evolved considerably over the years. It has benefited from
|
||
a large and active developer community--the many people who have
|
||
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
|
||
World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel
|
||
W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
|
||
Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
|
||
Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
|
||
recognition for their efforts in defining early aspects of the
|
||
protocol.
|
||
|
||
This document has benefited greatly from the comments of all those
|
||
participating in the HTTP-WG. In addition to those already
|
||
mentioned, the following individuals have contributed to this
|
||
specification:
|
||
|
||
Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
|
||
Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman
|
||
Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan
|
||
Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob
|
||
Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster,
|
||
Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J.
|
||
Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin,
|
||
Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey
|
||
Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc
|
||
Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton,
|
||
Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill
|
||
(BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko.
|
||
|
||
Thanks to the "cave men" of Palo Alto. You know who you are.
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 65]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
|
||
Fielding, the editor of [RFC2068], along with John Klensin, Jeff
|
||
Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
|
||
Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
|
||
help. And thanks go particularly to Jeff Mogul and Scott Lawrence
|
||
for performing the "MUST/MAY/SHOULD" audit.
|
||
|
||
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
|
||
Frystyk implemented RFC 2068 early, and we wish to thank them for the
|
||
discovery of many of the problems that this document attempts to
|
||
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.
|
||
|
||
13. References
|
||
|
||
13.1. Normative References
|
||
|
||
[ISO-8859-1] International Organization for Standardization,
|
||
"Information technology -- 8-bit single-byte coded
|
||
graphic character sets -- Part 1: Latin alphabet No.
|
||
1", ISO/IEC 8859-1:1998, 1998.
|
||
|
||
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
|
||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
|
||
Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
|
||
Semantics", draft-ietf-httpbis-p2-semantics-11 (work in
|
||
progress), August 2010.
|
||
|
||
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
|
||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
|
||
Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
|
||
Payload and Content Negotiation",
|
||
draft-ietf-httpbis-p3-payload-11 (work in progress),
|
||
August 2010.
|
||
|
||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
|
||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
|
||
Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
|
||
"HTTP/1.1, part 6: Caching",
|
||
draft-ietf-httpbis-p6-cache-11 (work in progress),
|
||
August 2010.
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 66]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
|
||
Format Specification version 3.3", RFC 1950, May 1996.
|
||
|
||
RFC 1950 is an Informational RFC, thus it might be less
|
||
stable than this specification. On the other hand,
|
||
this downward reference was present since the
|
||
publication of RFC 2068 in 1997 ([RFC2068]), therefore
|
||
it is unlikely to cause problems in practice. See also
|
||
[BCP97].
|
||
|
||
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
|
||
Specification version 1.3", RFC 1951, May 1996.
|
||
|
||
RFC 1951 is an Informational RFC, thus it might be less
|
||
stable than this specification. On the other hand,
|
||
this downward reference was present since the
|
||
publication of RFC 2068 in 1997 ([RFC2068]), therefore
|
||
it is unlikely to cause problems in practice. See also
|
||
[BCP97].
|
||
|
||
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
|
||
G. Randers-Pehrson, "GZIP file format specification
|
||
version 4.3", RFC 1952, May 1996.
|
||
|
||
RFC 1952 is an Informational RFC, thus it might be less
|
||
stable than this specification. On the other hand,
|
||
this downward reference was present since the
|
||
publication of RFC 2068 in 1997 ([RFC2068]), therefore
|
||
it is unlikely to cause problems in practice. See also
|
||
[BCP97].
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
|
||
"Uniform Resource Identifier (URI): Generic Syntax",
|
||
RFC 3986, STD 66, January 2005.
|
||
|
||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
|
||
Syntax Specifications: ABNF", STD 68, RFC 5234,
|
||
January 2008.
|
||
|
||
[USASCII] American National Standards Institute, "Coded Character
|
||
Set -- 7-bit American Standard Code for Information
|
||
Interchange", ANSI X3.4, 1986.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 67]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
13.2. Informative References
|
||
|
||
[BCP97] Klensin, J. and S. Hartman, "Handling Normative
|
||
References to Standards-Track Documents", BCP 97,
|
||
RFC 4897, June 2007.
|
||
|
||
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
|
||
Politics", ACM Transactions on Internet Technology Vol.
|
||
1, #2, November 2001,
|
||
<http://arxiv.org/abs/cs.SE/0105018>.
|
||
|
||
[Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
|
||
and C. Lilley, "Network Performance Effects of
|
||
HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
|
||
SIGCOMM '97 conference on Applications, technologies,
|
||
architectures, and protocols for computer communication
|
||
SIGCOMM '97, September 1997,
|
||
<http://doi.acm.org/10.1145/263105.263157>.
|
||
|
||
[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
|
||
Computer Networks and ISDN Systems v. 28, pp. 25-35,
|
||
December 1995,
|
||
<http://portal.acm.org/citation.cfm?id=219094>.
|
||
|
||
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
||
Application and Support", STD 3, RFC 1123,
|
||
October 1989.
|
||
|
||
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
|
||
Specification, Implementation", RFC 1305, March 1992.
|
||
|
||
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
|
||
RFC 1900, February 1996.
|
||
|
||
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
|
||
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
|
||
May 1996.
|
||
|
||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
|
||
Mail Extensions (MIME) Part One: Format of Internet
|
||
Message Bodies", RFC 2045, November 1996.
|
||
|
||
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
|
||
Extensions) Part Three: Message Header Extensions for
|
||
Non-ASCII Text", RFC 2047, November 1996.
|
||
|
||
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
|
||
T. Berners-Lee, "Hypertext Transfer Protocol --
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 68]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
HTTP/1.1", RFC 2068, January 1997.
|
||
|
||
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
|
||
Mechanism", RFC 2109, February 1997.
|
||
|
||
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
|
||
"Use and Interpretation of HTTP Version Numbers",
|
||
RFC 2145, May 1997.
|
||
|
||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
|
||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
|
||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
|
||
|
||
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
|
||
HTTP/1.1", RFC 2817, May 2000.
|
||
|
||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
|
||
|
||
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
|
||
Mechanism", RFC 2965, October 2000.
|
||
|
||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
|
||
Procedures for Message Header Fields", BCP 90,
|
||
RFC 3864, September 2004.
|
||
|
||
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
|
||
and Registration Procedures", BCP 13, RFC 4288,
|
||
December 2005.
|
||
|
||
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
|
||
and Registration Procedures for New URI Schemes",
|
||
BCP 115, RFC 4395, February 2006.
|
||
|
||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
|
||
an IANA Considerations Section in RFCs", BCP 26,
|
||
RFC 5226, May 2008.
|
||
|
||
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
|
||
October 2008.
|
||
|
||
[Spe] Spero, S., "Analysis of HTTP Performance Problems",
|
||
<http://sunsite.unc.edu/mdma-release/http-prob.html>.
|
||
|
||
[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
|
||
HTTP Performance", ISI Research Report ISI/RR-98-463,
|
||
Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
|
||
|
||
(original report dated Aug. 1996)
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 69]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Appendix A. Tolerant Applications
|
||
|
||
Although this document specifies the requirements for the generation
|
||
of HTTP/1.1 messages, not all applications will be correct in their
|
||
implementation. We therefore recommend that operational applications
|
||
be tolerant of deviations whenever those deviations can be
|
||
interpreted unambiguously.
|
||
|
||
Clients SHOULD be tolerant in parsing the Status-Line and servers
|
||
SHOULD be tolerant when parsing the Request-Line. In particular,
|
||
they SHOULD accept any amount of WSP characters between fields, even
|
||
though only a single SP is required.
|
||
|
||
The line terminator for header fields is the sequence CRLF. However,
|
||
we recommend that applications, when parsing such headers, recognize
|
||
a single LF as a line terminator and ignore the leading CR.
|
||
|
||
The character set of a representation SHOULD be labeled as the lowest
|
||
common denominator of the character codes used within that
|
||
representation, with the exception that not labeling the
|
||
representation is preferred over labeling the representation with the
|
||
labels US-ASCII or ISO-8859-1. See [Part3].
|
||
|
||
Additional rules for requirements on parsing and encoding of dates
|
||
and other potential problems with date encodings include:
|
||
|
||
o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
|
||
which appears to be more than 50 years in the future is in fact in
|
||
the past (this helps solve the "year 2000" problem).
|
||
|
||
o Although all date formats are specified to be case-sensitive,
|
||
recipients SHOULD match day, week and timezone names case-
|
||
insensitively.
|
||
|
||
o An HTTP/1.1 implementation MAY internally represent a parsed
|
||
Expires date as earlier than the proper value, but MUST NOT
|
||
internally represent a parsed Expires date as later than the
|
||
proper value.
|
||
|
||
o All expiration-related calculations MUST be done in GMT. The
|
||
local time zone MUST NOT influence the calculation or comparison
|
||
of an age or expiration time.
|
||
|
||
o If an HTTP header incorrectly carries a date value with a time
|
||
zone other than GMT, it MUST be converted into GMT using the most
|
||
conservative possible conversion.
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 70]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Appendix B. 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
|
||
compliance with previous versions. HTTP/1.1 was deliberately
|
||
designed, however, to make supporting previous versions easy. It is
|
||
worth noting that, at the time of composing this specification, we
|
||
would expect general-purpose HTTP/1.1 servers to:
|
||
|
||
o understand any valid request in the format of HTTP/1.0 and 1.1;
|
||
|
||
o respond appropriately with a message in the same major version
|
||
used by the client.
|
||
|
||
And we would expect HTTP/1.1 clients to:
|
||
|
||
o understand any valid response in the format of HTTP/1.0 or 1.1.
|
||
|
||
For most implementations of HTTP/1.0, each connection is established
|
||
by the client prior to the request and closed by the server after
|
||
sending the response. Some implementations implement the Keep-Alive
|
||
version of persistent connections described in Section 19.7.1 of
|
||
[RFC2068].
|
||
|
||
B.1. Changes from HTTP/1.0
|
||
|
||
This section summarizes major differences between versions HTTP/1.0
|
||
and HTTP/1.1.
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 71]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP
|
||
Addresses
|
||
|
||
The requirements that clients and servers support the Host request-
|
||
header, report an error if the Host request-header (Section 9.4) is
|
||
missing from an HTTP/1.1 request, and accept absolute URIs
|
||
(Section 4.1.2) are among the most important changes defined by this
|
||
specification.
|
||
|
||
Older HTTP/1.0 clients assumed a one-to-one relationship of IP
|
||
addresses and servers; there was no other established mechanism for
|
||
distinguishing the intended server of a request than the IP address
|
||
to which that request was directed. The changes outlined above will
|
||
allow the Internet, once older HTTP clients are no longer common, to
|
||
support multiple Web sites from a single IP address, greatly
|
||
simplifying large operational Web servers, where allocation of many
|
||
IP addresses to a single host has created serious problems. The
|
||
Internet will also be able to recover the IP addresses that have been
|
||
allocated for the sole purpose of allowing special-purpose domain
|
||
names to be used in root-level HTTP URLs. Given the rate of growth
|
||
of the Web, and the number of servers already deployed, it is
|
||
extremely important that all implementations of HTTP (including
|
||
updates to existing HTTP/1.0 applications) correctly implement these
|
||
requirements:
|
||
|
||
o Both clients and servers MUST support the Host request-header.
|
||
|
||
o A client that sends an HTTP/1.1 request MUST send a Host header.
|
||
|
||
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
|
||
request does not include a Host request-header.
|
||
|
||
o Servers MUST accept absolute URIs.
|
||
|
||
B.2. Compatibility with HTTP/1.0 Persistent Connections
|
||
|
||
Some clients and servers might wish to be compatible with some
|
||
previous implementations of persistent connections in HTTP/1.0
|
||
clients and servers. Persistent connections in HTTP/1.0 are
|
||
explicitly negotiated as they are not the default behavior. HTTP/1.0
|
||
experimental implementations of persistent connections are faulty,
|
||
and the new facilities in HTTP/1.1 are designed to rectify these
|
||
problems. The problem was that some existing HTTP/1.0 clients might
|
||
send Keep-Alive to a proxy server that doesn't understand Connection,
|
||
which would then erroneously forward it to the next inbound server,
|
||
which would establish the Keep-Alive connection and result in a hung
|
||
HTTP/1.0 proxy waiting for the close on the response. The result is
|
||
that HTTP/1.0 clients must be prevented from using Keep-Alive when
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 72]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
talking to proxies.
|
||
|
||
However, talking to proxies is the most important use of persistent
|
||
connections, so that prohibition is clearly unacceptable. Therefore,
|
||
we need some other mechanism for indicating a persistent connection
|
||
is desired, which is safe to use even when talking to an old proxy
|
||
that ignores Connection. Persistent connections are the default for
|
||
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
|
||
declaring non-persistence. See Section 9.1.
|
||
|
||
The original HTTP/1.0 form of persistent connections (the Connection:
|
||
Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of
|
||
[RFC2068].
|
||
|
||
B.3. Changes from RFC 2616
|
||
|
||
Empty list elements in list productions have been deprecated.
|
||
(Section 1.2.1)
|
||
|
||
Rules about implicit linear whitespace between certain grammar
|
||
productions have been removed; now it's only allowed when
|
||
specifically pointed out in the ABNF. The NUL character is no longer
|
||
allowed in comment and quoted-string text. The quoted-pair rule no
|
||
longer allows escaping control characters other than HTAB. Non-ASCII
|
||
content in header fields and reason phrase has been obsoleted and
|
||
made opaque (the TEXT rule was removed) (Section 1.2.2)
|
||
|
||
Clarify that HTTP-Version is case sensitive. (Section 2.5)
|
||
|
||
Remove reference to non-existent identity transfer-coding value
|
||
tokens. (Sections 6.2 and 3.3)
|
||
|
||
Require that invalid whitespace around field-names be rejected.
|
||
(Section 3.2)
|
||
|
||
Update use of abs_path production from RFC1808 to the path-absolute +
|
||
query components of RFC3986. (Section 4.1.2)
|
||
|
||
Clarification that the chunk length does not include the count of the
|
||
octets in the chunk header and trailer. Furthermore disallowed line
|
||
folding in chunk extensions. (Section 6.2.1)
|
||
|
||
Remove hard limit of two connections per server. (Section 7.1.4)
|
||
|
||
Clarify exactly when close connection options must be sent.
|
||
(Section 9.1)
|
||
|
||
Appendix C. Collected ABNF
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 73]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
BWS = OWS
|
||
|
||
Cache-Control = <Cache-Control, defined in [Part6], Section 3.4>
|
||
Chunked-Body = *chunk last-chunk trailer-part CRLF
|
||
Connection = "Connection:" OWS Connection-v
|
||
Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS
|
||
connection-token ] )
|
||
Content-Length = "Content-Length:" OWS 1*Content-Length-v
|
||
Content-Length-v = 1*DIGIT
|
||
|
||
Date = "Date:" OWS Date-v
|
||
Date-v = HTTP-date
|
||
|
||
GMT = %x47.4D.54 ; GMT
|
||
|
||
HTTP-Prot-Name = %x48.54.54.50 ; HTTP
|
||
HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
|
||
HTTP-date = rfc1123-date / obs-date
|
||
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
|
||
]
|
||
Host = "Host:" OWS Host-v
|
||
Host-v = uri-host [ ":" port ]
|
||
|
||
MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1>
|
||
Method = token
|
||
|
||
OWS = *( [ obs-fold ] WSP )
|
||
|
||
Pragma = <Pragma, defined in [Part6], Section 3.4>
|
||
|
||
RWS = 1*( [ obs-fold ] WSP )
|
||
Reason-Phrase = *( WSP / VCHAR / obs-text )
|
||
Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
|
||
Request-Line = Method SP request-target SP HTTP-Version CRLF
|
||
Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
|
||
|
||
Status-Code = 3DIGIT
|
||
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
|
||
|
||
TE = "TE:" OWS TE-v
|
||
TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
|
||
Trailer = "Trailer:" OWS Trailer-v
|
||
Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
|
||
Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
|
||
Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
|
||
transfer-coding ] )
|
||
|
||
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 74]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Upgrade = "Upgrade:" OWS Upgrade-v
|
||
Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
|
||
|
||
Via = "Via:" OWS Via-v
|
||
Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment
|
||
] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
|
||
] )
|
||
|
||
Warning = <Warning, defined in [Part6], Section 3.6>
|
||
|
||
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
|
||
asctime-date = day-name SP date3 SP time-of-day SP year
|
||
attribute = token
|
||
authority = <authority, defined in [RFC3986], Section 3.2>
|
||
|
||
chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
|
||
chunk-data = 1*OCTET
|
||
chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )
|
||
chunk-ext-name = token
|
||
chunk-ext-val = token / quoted-str-nf
|
||
chunk-size = 1*HEXDIG
|
||
comment = "(" *( ctext / quoted-cpair / comment ) ")"
|
||
connection-token = token
|
||
ctext = OWS / %x21-27 ; '!'-'''
|
||
/ %x2A-5B ; '*'-'['
|
||
/ %x5D-7E ; ']'-'~'
|
||
/ obs-text
|
||
|
||
date1 = day SP month SP year
|
||
date2 = day "-" month "-" 2DIGIT
|
||
date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
|
||
day = 2DIGIT
|
||
day-name = %x4D.6F.6E ; Mon
|
||
/ %x54.75.65 ; Tue
|
||
/ %x57.65.64 ; Wed
|
||
/ %x54.68.75 ; Thu
|
||
/ %x46.72.69 ; Fri
|
||
/ %x53.61.74 ; Sat
|
||
/ %x53.75.6E ; Sun
|
||
day-name-l = %x4D.6F.6E.64.61.79 ; Monday
|
||
/ %x54.75.65.73.64.61.79 ; Tuesday
|
||
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
|
||
/ %x54.68.75.72.73.64.61.79 ; Thursday
|
||
/ %x46.72.69.64.61.79 ; Friday
|
||
/ %x53.61.74.75.72.64.61.79 ; Saturday
|
||
/ %x53.75.6E.64.61.79 ; Sunday
|
||
|
||
field-content = *( WSP / VCHAR / obs-text )
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 75]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
field-name = token
|
||
field-value = *( field-content / OWS )
|
||
|
||
general-header = Cache-Control / Connection / Date / Pragma / Trailer
|
||
/ Transfer-Encoding / Upgrade / Via / Warning / MIME-Version
|
||
|
||
header-field = field-name ":" OWS [ field-value ] OWS
|
||
hour = 2DIGIT
|
||
http-URI = "http://" authority path-abempty [ "?" query ]
|
||
https-URI = "https://" authority path-abempty [ "?" query ]
|
||
|
||
last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF
|
||
|
||
message-body = *OCTET
|
||
minute = 2DIGIT
|
||
month = %x4A.61.6E ; Jan
|
||
/ %x46.65.62 ; Feb
|
||
/ %x4D.61.72 ; Mar
|
||
/ %x41.70.72 ; Apr
|
||
/ %x4D.61.79 ; May
|
||
/ %x4A.75.6E ; Jun
|
||
/ %x4A.75.6C ; Jul
|
||
/ %x41.75.67 ; Aug
|
||
/ %x53.65.70 ; Sep
|
||
/ %x4F.63.74 ; Oct
|
||
/ %x4E.6F.76 ; Nov
|
||
/ %x44.65.63 ; Dec
|
||
|
||
obs-date = rfc850-date / asctime-date
|
||
obs-fold = CRLF
|
||
obs-text = %x80-FF
|
||
|
||
partial-URI = relative-part [ "?" query ]
|
||
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
|
||
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
|
||
port = <port, defined in [RFC3986], Section 3.2.3>
|
||
product = token [ "/" product-version ]
|
||
product-version = token
|
||
protocol-name = token
|
||
protocol-version = token
|
||
pseudonym = token
|
||
|
||
qdtext = OWS / "!" / %x23-5B ; '#'-'['
|
||
/ %x5D-7E ; ']'-'~'
|
||
/ obs-text
|
||
qdtext-nf = WSP / "!" / %x23-5B ; '#'-'['
|
||
/ %x5D-7E ; ']'-'~'
|
||
/ obs-text
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 76]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
query = <query, defined in [RFC3986], Section 3.4>
|
||
quoted-cpair = "\" ( WSP / VCHAR / obs-text )
|
||
quoted-pair = "\" ( WSP / VCHAR / obs-text )
|
||
quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
|
||
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
|
||
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
|
||
|
||
received-by = ( uri-host [ ":" port ] ) / pseudonym
|
||
received-protocol = [ protocol-name "/" ] protocol-version
|
||
relative-part = <relative-part, defined in [RFC3986], Section 4.2>
|
||
request-header = <request-header, defined in [Part2], Section 3>
|
||
request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
|
||
/ authority
|
||
response-header = <response-header, defined in [Part2], Section 5>
|
||
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
|
||
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
|
||
|
||
second = 2DIGIT
|
||
special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
|
||
DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
|
||
start-line = Request-Line / Status-Line
|
||
|
||
t-codings = "trailers" / ( transfer-extension [ te-params ] )
|
||
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
|
||
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
|
||
te-ext = OWS ";" OWS token [ "=" word ]
|
||
te-params = OWS ";" OWS "q=" qvalue *te-ext
|
||
time-of-day = hour ":" minute ":" second
|
||
token = 1*tchar
|
||
trailer-part = *( header-field CRLF )
|
||
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
|
||
transfer-extension
|
||
transfer-extension = token *( OWS ";" OWS transfer-parameter )
|
||
transfer-parameter = attribute BWS "=" BWS value
|
||
|
||
uri-host = <host, defined in [RFC3986], Section 3.2.2>
|
||
|
||
value = word
|
||
|
||
word = token / quoted-string
|
||
|
||
year = 4DIGIT
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 77]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
ABNF diagnostics:
|
||
|
||
; Chunked-Body defined but not used
|
||
; Content-Length defined but not used
|
||
; HTTP-message defined but not used
|
||
; Host defined but not used
|
||
; Request defined but not used
|
||
; Response defined but not used
|
||
; TE defined but not used
|
||
; URI-reference defined but not used
|
||
; general-header defined but not used
|
||
; http-URI defined but not used
|
||
; https-URI defined but not used
|
||
; partial-URI defined but not used
|
||
; request-header defined but not used
|
||
; response-header defined but not used
|
||
; special defined but not used
|
||
|
||
Appendix D. Change Log (to be removed by RFC Editor before publication)
|
||
|
||
D.1. Since RFC2616
|
||
|
||
Extracted relevant partitions from [RFC2616].
|
||
|
||
D.2. Since draft-ietf-httpbis-p1-messaging-00
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
|
||
should be case sensitive"
|
||
(<http://purl.org/NET/http-errata#verscase>)
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
|
||
characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
|
||
Definition" (<http://purl.org/NET/http-errata#chunk-size>)
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length"
|
||
(<http://purl.org/NET/http-errata#msg-len-chars>)
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
|
||
Registrations" (<http://purl.org/NET/http-errata#media-reg>)
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes
|
||
query" (<http://purl.org/NET/http-errata#uriquery>)
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 78]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on
|
||
1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
|
||
'identity' token references"
|
||
(<http://purl.org/NET/http-errata#identity>)
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query
|
||
BNF"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
|
||
Informative references"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
|
||
Compliance"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
|
||
reference"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
|
||
references"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency
|
||
in date format explanation"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
|
||
typo"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
|
||
references"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
|
||
Reference"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
|
||
to-date references"
|
||
|
||
Other changes:
|
||
|
||
o Update media type registrations to use RFC4288 template.
|
||
|
||
o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF
|
||
for chunk-data (work in progress on
|
||
<http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 79]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
D.3. Since draft-ietf-httpbis-p1-messaging-01
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
|
||
(and other) requests"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
|
||
RFC4288"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
|
||
and Reason Phrase"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
|
||
used"
|
||
|
||
Ongoing work on ABNF conversion
|
||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
||
|
||
o Get rid of duplicate BNF rule names ("host" -> "uri-host",
|
||
"trailer" -> "trailer-part").
|
||
|
||
o Avoid underscore character in rule names ("http_URL" -> "http-
|
||
URL", "abs_path" -> "path-absolute").
|
||
|
||
o Add rules for terms imported from URI spec ("absoluteURI",
|
||
"authority", "path-absolute", "port", "query", "relativeURI",
|
||
"host) -- these will have to be updated when switching over to
|
||
RFC3986.
|
||
|
||
o Synchronize core rules with RFC5234.
|
||
|
||
o Get rid of prose rules that span multiple lines.
|
||
|
||
o Get rid of unused rules LOALPHA and UPALPHA.
|
||
|
||
o Move "Product Tokens" section (back) into Part 1, as "token" is
|
||
used in the definition of the Upgrade header.
|
||
|
||
o Add explicit references to BNF syntax and rules imported from
|
||
other parts of the specification.
|
||
|
||
o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
|
||
"TEXT".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 80]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
D.4. Since draft-ietf-httpbis-p1-messaging-02
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
|
||
rfc1123-date"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
|
||
pair"
|
||
|
||
Ongoing work on IANA Message Header Registration
|
||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
|
||
|
||
o Reference RFC 3984, and update header registrations for headers
|
||
defined in this document.
|
||
|
||
Ongoing work on ABNF conversion
|
||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
||
|
||
o Replace string literals when the string really is case-sensitive
|
||
(HTTP-Version).
|
||
|
||
D.5. Since draft-ietf-httpbis-p1-messaging-03
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
|
||
closing"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
|
||
registrations and registry information to IANA Considerations"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
|
||
for PAD1995 reference"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
|
||
Considerations: update HTTP URI scheme registration"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
|
||
URI scheme definition"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type
|
||
headers vs Set-Cookie"
|
||
|
||
Ongoing work on ABNF conversion
|
||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 81]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
o Replace string literals when the string really is case-sensitive
|
||
(HTTP-Date).
|
||
|
||
o Replace HEX by HEXDIG for future consistence with RFC 5234's core
|
||
rules.
|
||
|
||
D.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.
|
||
|
||
D.7. Since draft-ietf-httpbis-p1-messaging-05
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3
|
||
Terminology"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047
|
||
encoded words"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character
|
||
Encodings in TEXT"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding"
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 82]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
|
||
proxies"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
|
||
BNF"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
|
||
"Differences Between HTTP Entities and RFC 2045 Entities"?"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822
|
||
reference left in discussion of date formats"
|
||
|
||
Final work on ABNF conversion
|
||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
||
|
||
o Rewrite definition of list rules, deprecate empty list elements.
|
||
|
||
o Add appendix containing collected and expanded ABNF.
|
||
|
||
Other changes:
|
||
|
||
o Rewrite introduction; add mostly new Architecture Section.
|
||
|
||
o Move definition of quality values from Part 3 into Part 1; make TE
|
||
request header grammar independent of accept-params (defined in
|
||
Part 3).
|
||
|
||
D.8. Since draft-ietf-httpbis-p1-messaging-06
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
|
||
numeric protocol elements"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
|
||
|
||
Partly resolved issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
|
||
(took out language that implied that there might be methods for
|
||
which a request body MUST NOT be included)
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial
|
||
improvements around HTTP-date"
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 83]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
D.9. Since draft-ietf-httpbis-p1-messaging-07
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating
|
||
single-value headers"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase
|
||
connection limit"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses
|
||
in URLs"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over
|
||
HTTP Upgrade Token Registry"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in
|
||
chunk extension values"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9
|
||
support"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA
|
||
policy (RFC5226) for Transfer Coding / Content Coding"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move
|
||
definitions of gzip/deflate/compress to part 1"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow
|
||
control characters in quoted-pair"
|
||
|
||
Partly resolved issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
|
||
requirements wrt Transfer-Coding values" (add the IANA
|
||
Considerations subsection)
|
||
|
||
D.10. Since draft-ietf-httpbis-p1-messaging-08
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header
|
||
parsing, treatment of leading and trailing OWS"
|
||
|
||
Partly resolved issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
|
||
13.5.1 and 13.5.2"
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 84]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
|
||
"word" when talking about header structure"
|
||
|
||
D.11. Since draft-ietf-httpbis-p1-messaging-09
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification
|
||
of the term 'deflate'"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
|
||
proxies"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version
|
||
not listed in P1, general header fields"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
|
||
for content/transfer encodings"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case-
|
||
sensitivity of HTTP-date"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
|
||
"word" when talking about header structure"
|
||
|
||
Partly resolved issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
|
||
requested resource's URI"
|
||
|
||
D.12. Since draft-ietf-httpbis-p1-messaging-10
|
||
|
||
Closed issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
|
||
Closing"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting
|
||
messages with multipart/byteranges"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
|
||
multiple Content-Length headers"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
|
||
entity / representation / variant terminology"
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
|
||
removing the 'changes from 2068' sections"
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 85]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Partly resolved issues:
|
||
|
||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
|
||
scheme definitions"
|
||
|
||
Index
|
||
|
||
A
|
||
application/http Media Type 61
|
||
|
||
B
|
||
browser 10
|
||
|
||
C
|
||
cache 13
|
||
cacheable 14
|
||
chunked (Coding Format) 35
|
||
client 10
|
||
Coding Format
|
||
chunked 35
|
||
compress 38
|
||
deflate 38
|
||
gzip 38
|
||
compress (Coding Format) 38
|
||
connection 10
|
||
Connection header 49
|
||
Content-Length header 50
|
||
|
||
D
|
||
Date header 51
|
||
deflate (Coding Format) 38
|
||
downstream 12
|
||
|
||
E
|
||
effective request URI 29
|
||
|
||
G
|
||
gateway 13
|
||
Grammar
|
||
absolute-URI 16
|
||
ALPHA 7
|
||
asctime-date 34
|
||
attribute 34
|
||
authority 16
|
||
BWS 9
|
||
chunk 35
|
||
chunk-data 35
|
||
chunk-ext 35
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 86]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
chunk-ext-name 35
|
||
chunk-ext-val 35
|
||
chunk-size 35
|
||
Chunked-Body 35
|
||
comment 22
|
||
Connection 49
|
||
connection-token 49
|
||
Connection-v 49
|
||
Content-Length 50
|
||
Content-Length-v 50
|
||
CR 7
|
||
CRLF 7
|
||
ctext 22
|
||
CTL 7
|
||
Date 51
|
||
Date-v 51
|
||
date1 33
|
||
date2 34
|
||
date3 34
|
||
day 33
|
||
day-name 33
|
||
day-name-l 33
|
||
DIGIT 7
|
||
DQUOTE 7
|
||
extension-code 32
|
||
extension-method 26
|
||
field-content 20
|
||
field-name 20
|
||
field-value 20
|
||
general-header 26
|
||
GMT 33
|
||
header-field 20
|
||
HEXDIG 7
|
||
Host 52
|
||
Host-v 52
|
||
hour 33
|
||
HTTP-date 32
|
||
HTTP-message 19
|
||
HTTP-Prot-Name 15
|
||
http-URI 16
|
||
HTTP-Version 15
|
||
https-URI 18
|
||
last-chunk 35
|
||
LF 7
|
||
message-body 22
|
||
Method 26
|
||
minute 33
|
||
month 33
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 87]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
obs-date 33
|
||
obs-text 10
|
||
OCTET 7
|
||
OWS 9
|
||
path-absolute 16
|
||
port 16
|
||
product 39
|
||
product-version 39
|
||
protocol-name 57
|
||
protocol-version 57
|
||
pseudonym 57
|
||
qdtext 10
|
||
qdtext-nf 35
|
||
query 16
|
||
quoted-cpair 22
|
||
quoted-pair 10
|
||
quoted-str-nf 35
|
||
quoted-string 10
|
||
qvalue 39
|
||
Reason-Phrase 32
|
||
received-by 57
|
||
received-protocol 57
|
||
Request 26
|
||
Request-Line 26
|
||
request-target 27
|
||
Response 31
|
||
rfc850-date 34
|
||
rfc1123-date 33
|
||
RWS 9
|
||
second 33
|
||
SP 7
|
||
special 9
|
||
Status-Code 32
|
||
Status-Line 31
|
||
t-codings 53
|
||
tchar 9
|
||
TE 53
|
||
te-ext 53
|
||
te-params 53
|
||
TE-v 53
|
||
time-of-day 33
|
||
token 9
|
||
Trailer 54
|
||
trailer-part 35
|
||
Trailer-v 54
|
||
transfer-coding 34
|
||
Transfer-Encoding 55
|
||
Transfer-Encoding-v 55
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 88]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
transfer-extension 34
|
||
transfer-parameter 34
|
||
Upgrade 55
|
||
Upgrade-v 55
|
||
uri-host 16
|
||
URI-reference 16
|
||
value 34
|
||
VCHAR 7
|
||
Via 57
|
||
Via-v 57
|
||
word 9
|
||
WSP 7
|
||
year 33
|
||
gzip (Coding Format) 38
|
||
|
||
H
|
||
header field 19
|
||
header section 19
|
||
Headers
|
||
Connection 49
|
||
Content-Length 50
|
||
Date 51
|
||
Host 52
|
||
TE 53
|
||
Trailer 54
|
||
Transfer-Encoding 55
|
||
Upgrade 55
|
||
Via 57
|
||
headers 19
|
||
Host header 52
|
||
http URI scheme 16
|
||
https URI scheme 18
|
||
|
||
I
|
||
inbound 12
|
||
intermediary 12
|
||
|
||
M
|
||
Media Type
|
||
application/http 61
|
||
message/http 59
|
||
message 11
|
||
message/http Media Type 59
|
||
|
||
O
|
||
origin server 10
|
||
outbound 12
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 89]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
P
|
||
proxy 12
|
||
|
||
R
|
||
request 11
|
||
resource 16
|
||
response 11
|
||
reverse proxy 13
|
||
|
||
S
|
||
server 10
|
||
spider 10
|
||
|
||
T
|
||
target resource 29
|
||
TE header 53
|
||
Trailer header 54
|
||
Transfer-Encoding header 55
|
||
tunnel 13
|
||
|
||
U
|
||
Upgrade header 55
|
||
upstream 12
|
||
URI scheme
|
||
http 16
|
||
https 18
|
||
user agent 10
|
||
|
||
V
|
||
Via header 57
|
||
|
||
Authors' Addresses
|
||
|
||
Roy T. Fielding (editor)
|
||
Day Software
|
||
23 Corporate Plaza DR, Suite 280
|
||
Newport Beach, CA 92660
|
||
USA
|
||
|
||
Phone: +1-949-706-5300
|
||
Fax: +1-949-706-5305
|
||
EMail: fielding@gbiv.com
|
||
URI: http://roy.gbiv.com/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 90]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Jim Gettys
|
||
Alcatel-Lucent Bell Labs
|
||
21 Oak Knoll Road
|
||
Carlisle, MA 01741
|
||
USA
|
||
|
||
EMail: jg@freedesktop.org
|
||
URI: http://gettys.wordpress.com/
|
||
|
||
|
||
Jeffrey C. Mogul
|
||
Hewlett-Packard Company
|
||
HP Labs, Large Scale Systems Group
|
||
1501 Page Mill Road, MS 1177
|
||
Palo Alto, CA 94304
|
||
USA
|
||
|
||
EMail: JeffMogul@acm.org
|
||
|
||
|
||
Henrik Frystyk Nielsen
|
||
Microsoft Corporation
|
||
1 Microsoft Way
|
||
Redmond, WA 98052
|
||
USA
|
||
|
||
EMail: henrikn@microsoft.com
|
||
|
||
|
||
Larry Masinter
|
||
Adobe Systems, Incorporated
|
||
345 Park Ave
|
||
San Jose, CA 95110
|
||
USA
|
||
|
||
EMail: LMM@acm.org
|
||
URI: http://larry.masinter.net/
|
||
|
||
|
||
Paul J. Leach
|
||
Microsoft Corporation
|
||
1 Microsoft Way
|
||
Redmond, WA 98052
|
||
|
||
EMail: paulle@microsoft.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 91]
|
||
|
||
Internet-Draft HTTP/1.1, Part 1 August 2010
|
||
|
||
|
||
Tim Berners-Lee
|
||
World Wide Web Consortium
|
||
MIT Computer Science and Artificial Intelligence Laboratory
|
||
The Stata Center, Building 32
|
||
32 Vassar Street
|
||
Cambridge, MA 02139
|
||
USA
|
||
|
||
EMail: timbl@w3.org
|
||
URI: http://www.w3.org/People/Berners-Lee/
|
||
|
||
|
||
Yves Lafon (editor)
|
||
World Wide Web Consortium
|
||
W3C / ERCIM
|
||
2004, rte des Lucioles
|
||
Sophia-Antipolis, AM 06902
|
||
France
|
||
|
||
EMail: ylafon@w3.org
|
||
URI: http://www.raubacapeu.net/people/yves/
|
||
|
||
|
||
Julian F. Reschke (editor)
|
||
greenbytes GmbH
|
||
Hafenweg 16
|
||
Muenster, NW 48155
|
||
Germany
|
||
|
||
Phone: +49 251 2807760
|
||
Fax: +49 251 2807761
|
||
EMail: julian.reschke@greenbytes.de
|
||
URI: http://greenbytes.de/tech/webdav/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Fielding, et al. Expires February 5, 2011 [Page 92]
|
||
|