< draft-ietf-httpbis-p1-messaging-11.txt   draft-ietf-httpbis-p1-messaging-12.txt >
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Updates: 2817 (if approved) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: February 5, 2011 HP Expires: April 28, 2011 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
August 4, 2010 October 25, 2010
HTTP/1.1, part 1: URIs, Connections, and Message Parsing HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-ietf-httpbis-p1-messaging-11 draft-ietf-httpbis-p1-messaging-12
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
an overview of HTTP and its associated terminology, defines the an overview of HTTP and its associated terminology, defines the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
frames, and describes general security concerns for implementations. frames, and describes general security concerns for implementations.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.12. The changes in this draft are summarized in Appendix D.13.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 40 skipping to change at page 3, line 40
5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32
6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32
6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34
6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35
6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37
6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 39 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 40
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44
7.2. Message Transmission Requirements . . . . . . . . . . . . 45 7.2. Message Transmission Requirements . . . . . . . . . . . . 45
7.2.1. Persistent Connections and Flow Control . . . . . . . 45 7.2.1. Persistent Connections and Flow Control . . . . . . . 45
7.2.2. Monitoring Connections for Error Status Messages . . . 45 7.2.2. Monitoring Connections for Error Status Messages . . . 45
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 48 Connection . . . . . . . . . . . . . . . . . . . . . . 48
skipping to change at page 4, line 50 skipping to change at page 4, line 50
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70
Appendix B. Compatibility with Previous Versions . . . . . . . . 71 Appendix B. Compatibility with Previous Versions . . . . . . . . 71
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71
B.1.1. Changes to Simplify Multi-homed Web Servers and B.1.1. Changes to Simplify Multi-homed Web Servers and
Conserve IP Addresses . . . . . . . . . . . . . . . . 72 Conserve IP Addresses . . . . . . . . . . . . . . . . 72
B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72
B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 78 publication) . . . . . . . . . . . . . . . . . . . . 78
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 78
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84
D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85
D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85 D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85
D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 86
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
request/response protocol that uses extensible semantics and MIME- request/response protocol that uses extensible semantics and MIME-
like message payloads for flexible interaction with network-based like message payloads for flexible interaction with network-based
hypertext information systems. HTTP relies upon the Uniform Resource hypertext information systems. HTTP relies upon the Uniform Resource
Identifier (URI) standard [RFC3986] to indicate request targets and Identifier (URI) standard [RFC3986] to indicate request targets and
relationships between resources. Messages are passed in a format relationships between resources. Messages are passed in a format
skipping to change at page 21, line 39 skipping to change at page 21, line 39
message unless the entire field value for that header field is message unless the entire field value for that header field is
defined as a comma-separated list [i.e., #(values)]. Multiple header defined as a comma-separated list [i.e., #(values)]. Multiple header
fields with the same field name can be combined into one "field-name: fields with the same field name can be combined into one "field-name:
field-value" pair, without changing the semantics of the message, by field-value" pair, without changing the semantics of the message, by
appending each subsequent field value to the combined field value in appending each subsequent field value to the combined field value in
order, separated by a comma. The order in which header fields with order, separated by a comma. The order in which header fields with
the same field name are received is therefore significant to the the same field name are received is therefore significant to the
interpretation of the combined field value; a proxy MUST NOT change interpretation of the combined field value; a proxy MUST NOT change
the order of these field values when forwarding a message. the order of these field values when forwarding a message.
Note: The "Set-Cookie" header as implemented in practice (as Note: The "Set-Cookie" header field as implemented in practice (as
opposed to how it is specified in [RFC2109]) can occur multiple opposed to how it is specified in [RFC2109]) can occur multiple
times, but does not use the list syntax, and thus cannot be 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 combined into a single line. (See Appendix A.2.3 of [Kri2001] for
details.) Also note that the Set-Cookie2 header specified in details.) Also note that the Set-Cookie2 header field specified
[RFC2965] does not share this problem. in [RFC2965] does not share this problem.
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab character (line folding). This specification or horizontal tab character (line folding). This specification
deprecates such line folding except within the message/http media deprecates such line folding except within the message/http media
type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages 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 that include line folding (i.e., that contain any field-content that
matches the obs-fold rule) unless the message is intended for matches the obs-fold rule) unless the message is intended for
packaging within the message/http media type. HTTP/1.1 recipients packaging within the message/http media type. HTTP/1.1 recipients
SHOULD accept line folding and replace any embedded obs-fold SHOULD accept line folding and replace any embedded obs-fold
skipping to change at page 24, line 16 skipping to change at page 24, line 16
3. If a message is received without Transfer-Encoding and with 3. If a message is received without Transfer-Encoding and with
either multiple Content-Length header fields or a single Content- either multiple Content-Length header fields or a single Content-
Length header field with an invalid value, then the message Length header field with an invalid value, then the message
framing is invalid and MUST be treated as an error to prevent framing is invalid and MUST be treated as an error to prevent
request or response smuggling. If this is a request message, the request or response smuggling. If this is a request message, the
server MUST respond with a 400 (Bad Request) status code and then server MUST respond with a 400 (Bad Request) status code and then
close the connection. If this is a response message received by close the connection. If this is a response message received by
a proxy or gateway, the proxy or gateway MUST discard the a proxy or gateway, the proxy or gateway MUST discard the
received response, send a 502 (Bad Gateway) status code as its received response, send a 502 (Bad Gateway) status code as its
downstream response, and then close the connection. If this is a downstream response, and then close the connection. If this is a
response message received by a user-agent, the message-body response message received by a user-agent, it SHOULD be treated
length is determined by reading the connection until it is as an error by discarding the message and closing the connection.
closed; an error SHOULD be indicated to the user.
4. If a valid Content-Length header field (Section 9.2) is present 4. If a valid Content-Length header field (Section 9.2) is present
without Transfer-Encoding, its decimal value defines the message- without Transfer-Encoding, its decimal value defines the message-
body length in octets. If the actual number of octets sent in body length in octets. If the actual number of octets sent in
the message is less than the indicated Content-Length, the the message is less than the indicated Content-Length, the
recipient MUST consider the message to be incomplete and treat recipient MUST consider the message to be incomplete and treat
the connection as no longer usable. If the actual number of the connection as no longer usable. If the actual number of
octets sent in the message is more than the indicated Content- octets sent in the message is more than the indicated Content-
Length, the recipient MUST only process the message-body up to Length, the recipient MUST only process the message-body up to
the field value's number of octets; the remainder of the message the field value's number of octets; the remainder of the message
skipping to change at page 27, line 18 skipping to change at page 27, line 18
request. request.
request-target = "*" request-target = "*"
/ absolute-URI / absolute-URI
/ ( path-absolute [ "?" query ] ) / ( path-absolute [ "?" query ] )
/ authority / authority
The four options for request-target are dependent on the nature of The four options for request-target are dependent on the nature of
the request. the request.
The asterisk "*" means that the request does not apply to a The asterisk "*" ("asterisk form") means that the request does not
particular resource, but to the server itself, and is only allowed apply to a particular resource, but to the server itself, and is only
when the method used does not necessarily apply to a resource. One allowed when the method used does not necessarily apply to a
example would be resource. One example would be
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
The absolute-URI form is REQUIRED when the request is being made to a The absolute-URI form is REQUIRED when the request is being made to a
proxy. The proxy is requested to forward the request or service it proxy. The proxy is requested to forward the request or service it
from a valid cache, and return the response. Note that the proxy MAY from a valid cache, and return the response. Note that the proxy MAY
forward the request on to another proxy or directly to the server forward the request on to another proxy or directly to the server
specified by the absolute-URI. In order to avoid request loops, a specified by the absolute-URI. In order to avoid request loops, a
proxy MUST be able to recognize all of its server names, including proxy MUST be able to recognize all of its server names, including
any aliases, local variations, and the numeric IP address. An any aliases, local variations, and the numeric IP address. An
skipping to change at page 27, line 45 skipping to change at page 27, line 45
To allow for transition to absolute-URIs in all requests in future To allow for transition to absolute-URIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
form in requests, even though HTTP/1.1 clients will only generate form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies. them in requests to proxies.
The authority form is only used by the CONNECT method (Section 7.9 of The authority form is only used by the CONNECT method (Section 7.9 of
[Part2]). [Part2]).
The most common form of request-target is that used to identify a 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 resource on an origin server or gateway ("path-absolute form"). In
path of the URI MUST be transmitted (see Section 2.6.1, path- this case the absolute path of the URI MUST be transmitted (see
absolute) as the request-target, and the network location of the URI Section 2.6.1, path-absolute) as the request-target, and the network
(authority) MUST be transmitted in a Host header field. For example, location of the URI (authority) MUST be transmitted in a Host header
a client wishing to retrieve the resource above directly from the field. For example, a client wishing to retrieve the resource above
origin server would create a TCP connection to port 80 of the host directly from the origin server would create a TCP connection to port
"www.example.org" and send the lines: 80 of the host "www.example.org" and send the lines:
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org Host: www.example.org
followed by the remainder of the Request. Note that the absolute followed by the remainder of the Request. Note that the absolute
path cannot be empty; if none is present in the original URI, it MUST path cannot be empty; if none is present in the original URI, it MUST
be given as "/" (the server root). be given as "/" (the server root).
If a proxy receives a request without any path in the request-target If a proxy receives a request without any path in the request-target
and the method specified is capable of supporting the asterisk form and the method specified is capable of supporting the asterisk form
skipping to change at page 30, line 6 skipping to change at page 30, line 6
HTTP requests often do not carry the absolute URI ([RFC3986], Section HTTP requests often do not carry the absolute URI ([RFC3986], Section
4.3) for the target resource; instead, the URI needs to be inferred 4.3) for the target resource; instead, the URI needs to be inferred
from the request-target, Host header field, and connection context. from the request-target, Host header field, and connection context.
The result of this process is called the "effective request URI". The result of this process is called the "effective request URI".
The "target resource" is the resource identified by the effective The "target resource" is the resource identified by the effective
request URI. request URI.
If the request-target is an absolute-URI, then the effective request If the request-target is an absolute-URI, then the effective request
URI is the request-target. URI is the request-target.
If the request-target uses the path-absolute (plus optional query) If the request-target uses the path-absolute form or the asterisk
syntax or if it is just the asterisk "*", then the effective request form, and the Host header field is present, then the effective
URI is constructed by concatenating request URI is constructed by concatenating
o the scheme name: "http" if the request was received over an o the scheme name: "http" if the request was received over an
insecure TCP connection, or "https" when received over a SSL/ insecure TCP connection, or "https" when received over a SSL/
TLS-secured TCP connection, TLS-secured TCP connection,
o the character sequence "://", o the character sequence "://",
o the authority component, as specified in the Host header o the authority component, as specified in the Host header field
(Section 9.4) and determined by the rules in Section 4.2, (Section 9.4), and
[[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 o the request-target obtained from the Request-Line, unless the
request-target is just the asterisk "*". request-target is just the asterisk "*".
If the request-target uses the path-absolute form or the asterisk
form, and the Host header field is not present, then the effective
request URI is undefined.
Otherwise, when request-target uses the authority form, the effective Otherwise, when request-target uses the authority form, the effective
Request URI is undefined. request URI is undefined.
Example 1: the effective request URI for the message Example 1: the effective request URI for the message
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080 Host: www.example.org:8080
(received over an insecure TCP connection) is "http", plus "://", (received over an insecure TCP connection) is "http", plus "://",
plus the authority component "www.example.org:8080", plus the plus the authority component "www.example.org:8080", plus the
request-target "/pub/WWW/TheProject.html", thus request-target "/pub/WWW/TheProject.html", thus
"http://www.example.org:8080/pub/WWW/TheProject.html". "http://www.example.org:8080/pub/WWW/TheProject.html".
skipping to change at page 33, line 6 skipping to change at page 33, line 6
abbreviation for time zone, and MUST be assumed when reading the abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include asctime format. HTTP-date is case sensitive and MUST NOT include
additional whitespace beyond that specifically included as SP in the additional whitespace beyond that specifically included as SP in the
grammar. grammar.
HTTP-date = rfc1123-date / obs-date HTTP-date = rfc1123-date / obs-date
Preferred format: Preferred format:
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
; fixed length subset of the format defined in
; Section 5.2.14 of [RFC1123]
day-name = %x4D.6F.6E ; "Mon", case-sensitive day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive / %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive / %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive / %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive / %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive / %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive / %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year date1 = day SP month SP year
skipping to change at page 36, line 23 skipping to change at page 36, line 23
Section 9.6). Section 9.6).
A server using chunked transfer-coding in a response MUST NOT use the 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 trailer for any header fields unless at least one of the following is
true: true:
1. the request included a TE header field that indicates "trailers" 1. the request included a TE header field that indicates "trailers"
is acceptable in the transfer-coding of the response, as is acceptable in the transfer-coding of the response, as
described in Section 9.5; or, described in Section 9.5; or,
2. the server is the origin server for the response, the trailer 2. the trailer fields consist entirely of optional metadata, and the
fields consist entirely of optional metadata, and the recipient recipient could use the message (in a manner acceptable to the
could use the message (in a manner acceptable to the origin server where the field originated) without receiving it. In
server) without receiving this metadata. In other words, the other words, the server that generated the header (often but not
origin server is willing to accept the possibility that the always the origin server) is willing to accept the possibility
trailer fields might be silently discarded along the path to the that the trailer fields might be silently discarded along the
client. path to the client.
This requirement prevents an interoperability failure when the This requirement prevents an interoperability failure when the
message is being received by an HTTP/1.1 (or later) proxy and message is being received by an HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 recipient. It avoids a situation where forwarded to an HTTP/1.0 recipient. It avoids a situation where
compliance with the protocol would have necessitated a possibly compliance with the protocol would have necessitated a possibly
infinite buffer on the proxy. infinite buffer on the proxy.
A process for decoding the "chunked" transfer-coding can be A process for decoding the "chunked" transfer-coding can be
represented in pseudo-code as: represented in pseudo-code as:
skipping to change at page 39, line 31 skipping to change at page 39, line 31
Product tokens SHOULD be short and to the point. They MUST NOT be Product tokens SHOULD be short and to the point. They MUST NOT be
used for advertising or other non-essential information. Although used for advertising or other non-essential information. Although
any token character MAY appear in a product-version, this token any token character MAY appear in a product-version, this token
SHOULD only be used for a version identifier (i.e., successive SHOULD only be used for a version identifier (i.e., successive
versions of the same product SHOULD only differ in the product- versions of the same product SHOULD only differ in the product-
version portion of the product value). version portion of the product value).
6.4. Quality Values 6.4. Quality Values
Both transfer codings (TE request header, Section 9.5) and content Both transfer codings (TE request header field, Section 9.5) and
negotiation (Section 5 of [Part3]) use short "floating point" numbers content negotiation (Section 5 of [Part3]) use short "floating point"
to indicate the relative importance ("weight") of various negotiable numbers to indicate the relative importance ("weight") of various
parameters. A weight is normalized to a real number in the range 0 negotiable parameters. A weight is normalized to a real number in
through 1, where 0 is the minimum and 1 the maximum value. If a the range 0 through 1, where 0 is the minimum and 1 the maximum
parameter has a quality value of 0, then content with this parameter value. If a parameter has a quality value of 0, then content with
is "not acceptable" for the client. HTTP/1.1 applications MUST NOT this parameter is "not acceptable" for the client. HTTP/1.1
generate more than three digits after the decimal point. User applications MUST NOT generate more than three digits after the
configuration of these values SHOULD also be limited in this fashion. decimal point. User configuration of these values SHOULD also be
limited in this fashion.
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
Note: "Quality values" is a misnomer, since these values merely Note: "Quality values" is a misnomer, since these values merely
represent relative degradation in desired quality. represent relative degradation in desired quality.
7. Connections 7. Connections
7.1. Persistent Connections 7.1. Persistent Connections
7.1.1. Purpose 7.1.1. Purpose
Prior to persistent connections, a separate TCP connection was Prior to persistent connections, a separate TCP connection was
established to fetch each URL, increasing the load on HTTP servers established to fetch each URL, increasing the load on HTTP servers
and causing congestion on the Internet. The use of inline images and and causing congestion on the Internet. The use of inline images and
other associated data often requires a client to make multiple other associated data often requires a client to make multiple
requests of the same server in a short amount of time. Analysis of requests of the same server in a short amount of time. Analysis of
these performance problems and results from a prototype these performance problems and results from a prototype
implementation are available [Pad1995] [Spe]. Implementation implementation are available [Pad1995] [Spe]. Implementation
experience and measurements of actual HTTP/1.1 implementations show experience and measurements of actual HTTP/1.1 implementations show
skipping to change at page 41, line 14 skipping to change at page 41, line 15
Persistent connections provide a mechanism by which a client and a Persistent connections provide a mechanism by which a client and a
server can signal the close of a TCP connection. This signaling server can signal the close of a TCP connection. This signaling
takes place using the Connection header field (Section 9.1). Once a takes place using the Connection header field (Section 9.1). Once a
close has been signaled, the client MUST NOT send any more requests close has been signaled, the client MUST NOT send any more requests
on that connection. on that connection.
7.1.2.1. Negotiation 7.1.2.1. Negotiation
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header including maintain a persistent connection unless a Connection header field
the connection-token "close" was sent in the request. If the server including the connection-token "close" was sent in the request. If
chooses to close the connection immediately after sending the the server chooses to close the connection immediately after sending
response, it SHOULD send a Connection header including the the response, it SHOULD send a Connection header field including the
connection-token "close". connection-token "close".
An HTTP/1.1 client MAY expect a connection to remain open, but would 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 decide to keep it open based on whether the response from a server
contains a Connection header with the connection-token close. In contains a Connection header field with the connection-token close.
case the client does not want to maintain a connection for more than In case the client does not want to maintain a connection for more
that request, it SHOULD send a Connection header including the than that request, it SHOULD send a Connection header field including
connection-token close. the connection-token close.
If either the client or the server sends the close token in the If either the client or the server sends the close token in the
Connection header, that request becomes the last one for the Connection header field, that request becomes the last one for the
connection. connection.
Clients and servers SHOULD NOT assume that a persistent connection is Clients and servers SHOULD NOT assume that a persistent connection is
maintained for HTTP versions less than 1.1 unless it is explicitly maintained for HTTP versions less than 1.1 unless it is explicitly
signaled. See Appendix B.2 for more information on backward signaled. See Appendix B.2 for more information on backward
compatibility with HTTP/1.0 clients. compatibility with HTTP/1.0 clients.
In order to remain persistent, all messages on the connection MUST In order to remain persistent, all messages on the connection MUST
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 3.3. of the connection), as described in Section 3.3.
skipping to change at page 42, line 27 skipping to change at page 42, line 29
Section 9.1. Section 9.1.
The proxy server MUST signal persistent connections separately with The proxy server MUST signal persistent connections separately with
its clients and the origin servers (or other proxy servers) that it its clients and the origin servers (or other proxy servers) that it
connects to. Each persistent connection applies to only one connects to. Each persistent connection applies to only one
transport link. transport link.
A proxy server MUST NOT establish a HTTP/1.1 persistent connection 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 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 information and discussion of the problems with the Keep-Alive header
implemented by many HTTP/1.0 clients). field implemented by many HTTP/1.0 clients).
7.1.3.1. End-to-end and Hop-by-hop Headers 7.1.3.1. End-to-end and Hop-by-hop Header Fields
For the purpose of defining the behavior of caches and non-caching For the purpose of defining the behavior of caches and non-caching
proxies, we divide HTTP headers into two categories: proxies, we divide HTTP header fields into two categories:
o End-to-end headers, which are transmitted to the ultimate o End-to-end header fields, which are transmitted to the ultimate
recipient of a request or response. End-to-end headers in recipient of a request or response. End-to-end header fields in
responses MUST be stored as part of a cache entry and MUST be responses MUST be stored as part of a cache entry and MUST be
transmitted in any response formed from a cache entry. transmitted in any response formed from a cache entry.
o Hop-by-hop headers, which are meaningful only for a single o Hop-by-hop header fields, which are meaningful only for a single
transport-level connection, and are not stored by caches or transport-level connection, and are not stored by caches or
forwarded by proxies. forwarded by proxies.
The following HTTP/1.1 headers are hop-by-hop headers: The following HTTP/1.1 header fields are hop-by-hop header fields:
o Connection o Connection
o Keep-Alive o Keep-Alive
o Proxy-Authenticate o Proxy-Authenticate
o Proxy-Authorization o Proxy-Authorization
o TE o TE
o Trailer o Trailer
o Transfer-Encoding o Transfer-Encoding
o Upgrade o Upgrade
All other headers defined by HTTP/1.1 are end-to-end headers. All other header fields defined by HTTP/1.1 are end-to-end header
fields.
Other hop-by-hop headers MUST be listed in a Connection header Other hop-by-hop header fields MUST be listed in a Connection header
(Section 9.1). field (Section 9.1).
7.1.3.2. Non-modifiable Headers 7.1.3.2. Non-modifiable Header Fields
Some features of HTTP/1.1, such as Digest Authentication, depend on Some features of HTTP/1.1, such as Digest Authentication, depend on
the value of certain end-to-end headers. A transparent proxy SHOULD the value of certain end-to-end header fields. A transparent proxy
NOT modify an end-to-end header unless the definition of that header SHOULD NOT modify an end-to-end header field unless the definition of
requires or specifically allows that. that header field requires or specifically allows that.
A transparent proxy MUST NOT modify any of the following fields in a 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 request or response, and it MUST NOT add any of these fields if not
already present: already present:
o Content-Location o Content-Location
o Content-MD5 o Content-MD5
o ETag o ETag
o Last-Modified o Last-Modified
A transparent proxy MUST NOT modify any of the following fields in a A transparent proxy MUST NOT modify any of the following fields in a
response: response:
o Expires o Expires
but it MAY add any of these fields if not already present. If an 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 Expires header field is added, it MUST be given a field-value
that of the Date header in that response. identical to that of the Date header field in that response.
A proxy MUST NOT modify or add any of the following fields in a 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 message that contains the no-transform cache-control directive, or in
any request: any request:
o Content-Encoding o Content-Encoding
o Content-Range o Content-Range
o Content-Type o Content-Type
A non-transparent proxy MAY modify or add these fields to a message 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 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 Warning 214 (Transformation applied) if one does not already appear
in the message (see Section 3.6 of [Part6]). in the message (see Section 3.6 of [Part6]).
Warning: Unnecessary modification of end-to-end headers might Warning: Unnecessary modification of end-to-end header fields
cause authentication failures if stronger authentication might cause authentication failures if stronger authentication
mechanisms are introduced in later versions of HTTP. Such mechanisms are introduced in later versions of HTTP. Such
authentication mechanisms MAY rely on the values of header fields authentication mechanisms MAY rely on the values of header fields
not listed here. not listed here.
A transparent proxy MUST preserve the message payload ([Part3]), A transparent proxy MUST preserve the message payload ([Part3]),
though it MAY change the message-body through application or removal though it MAY change the message-body through application or removal
of a transfer-coding (Section 6.2). of a transfer-coding (Section 6.2).
7.1.4. Practical Considerations 7.1.4. Practical Considerations
skipping to change at page 46, line 6 skipping to change at page 46, line 8
The latter technique can exacerbate network congestion. The latter technique can exacerbate network congestion.
7.2.2. Monitoring Connections for Error Status Messages 7.2.2. Monitoring Connections for Error Status Messages
An HTTP/1.1 (or later) client sending a message-body SHOULD monitor An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
the network connection for an error status code while it is the network connection for an error status code while it is
transmitting the request. If the client sees an error status code, transmitting the request. If the client sees an error status code,
it SHOULD immediately cease transmitting the body. If the body is it SHOULD immediately cease transmitting the body. If the body is
being sent using a "chunked" encoding (Section 6.2), a zero length 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 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 message. If the body was preceded by a Content-Length header
the client MUST close the connection. field, the client MUST close the connection.
7.2.3. Use of the 100 (Continue) Status 7.2.3. Use of the 100 (Continue) Status
The purpose of the 100 (Continue) status code (see Section 8.1.1 of 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 [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 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 (based on the request header fields) before the client
the request body. In some cases, it might either be inappropriate or sends the request body. In some cases, it might either be
highly inefficient for the client to send the body if the server will inappropriate or highly inefficient for the client to send the body
reject the message without looking at the body. if the server will reject the message without looking at the body.
Requirements for HTTP/1.1 clients: Requirements for HTTP/1.1 clients:
o If a client will wait for a 100 (Continue) response before sending o If a client will wait for a 100 (Continue) response before sending
the request body, it MUST send an Expect request-header field the request body, it MUST send an Expect request-header field
(Section 9.2 of [Part2]) with the "100-continue" expectation. (Section 9.2 of [Part2]) with the "100-continue" expectation.
o A client MUST NOT send an Expect request-header field (Section 9.2 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 of [Part2]) with the "100-continue" expectation if it does not
intend to send a request body. intend to send a request body.
skipping to change at page 48, line 24 skipping to change at page 48, line 27
but which does not include an Expect request-header field with the but which does not include an Expect request-header field with the
"100-continue" expectation, and if the client is not directly "100-continue" expectation, and if the client is not directly
connected to an HTTP/1.1 origin server, and if the client sees the 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 connection close before receiving a status line from the server, the
client SHOULD retry the request. If the client does retry this client SHOULD retry the request. If the client does retry this
request, it MAY use the following "binary exponential backoff" request, it MAY use the following "binary exponential backoff"
algorithm to be assured of obtaining a reliable response: algorithm to be assured of obtaining a reliable response:
1. Initiate a new connection to the server 1. Initiate a new connection to the server
2. Transmit the request-headers 2. Transmit the request-header fields
3. Initialize a variable R to the estimated round-trip time to the 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 server (e.g., based on the time it took to establish the
connection), or to a constant value of 5 seconds if the round- connection), or to a constant value of 5 seconds if the round-
trip time is not available. trip time is not available.
4. Compute T = R * (2**N), where N is the number of previous retries 4. Compute T = R * (2**N), where N is the number of previous retries
of this request. of this request.
5. Wait either for an error response from the server, or for T 5. Wait either for an error response from the server, or for T
skipping to change at page 49, line 43 skipping to change at page 49, line 45
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to message framing and transport protocols. fields related to message framing and transport protocols.
9.1. Connection 9.1. Connection
The "Connection" general-header field allows the sender to specify The "Connection" general-header field allows the sender to specify
options that are desired for that particular connection and MUST NOT options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections. be communicated by proxies over further connections.
The Connection header's value has the following grammar: The Connection header field's value has the following grammar:
Connection = "Connection" ":" OWS Connection-v Connection = "Connection" ":" OWS Connection-v
Connection-v = 1#connection-token Connection-v = 1#connection-token
connection-token = token connection-token = token
HTTP/1.1 proxies MUST parse the Connection header field before a HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token in this field, message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the remove any header field(s) from the message with the same name as the
connection-token. Connection options are signaled by the presence of connection-token. Connection options are signaled by the presence of
a connection-token in the Connection header field, not by any a connection-token in the Connection header field, not by any
corresponding additional header field(s), since the additional header corresponding additional header field(s), since the additional header
field might not be sent if there are no parameters associated with field might not be sent if there are no parameters associated with
that connection option. that connection option.
Message headers listed in the Connection header MUST NOT include end- Message header fields listed in the Connection header field MUST NOT
to-end headers, such as Cache-Control. include end-to-end header fields, such as Cache-Control.
HTTP/1.1 defines the "close" connection option for the sender to HTTP/1.1 defines the "close" connection option for the sender to
signal that the connection will be closed after completion of the signal that the connection will be closed after completion of the
response. For example, response. For example,
Connection: close Connection: close
in either the request or the response header fields indicates that in either the request or the response header fields indicates that
the connection SHOULD NOT be considered "persistent" (Section 7.1) the connection SHOULD NOT be considered "persistent" (Section 7.1)
after the current request/response is complete. after the current request/response is complete.
An HTTP/1.1 client that does not support persistent connections MUST An HTTP/1.1 client that does not support persistent connections MUST
include the "close" connection option in every request message. include the "close" connection option in every request message.
An HTTP/1.1 server that does not support persistent connections MUST An HTTP/1.1 server that does not support persistent connections MUST
include the "close" connection option in every response message that include the "close" connection option in every response message that
does not have a 1xx (Informational) status code. does not have a 1xx (Informational) status code.
A system receiving an HTTP/1.0 (or lower-version) message that A system receiving an HTTP/1.0 (or lower-version) message that
includes a Connection header MUST, for each connection-token in this includes a Connection header field MUST, for each connection-token in
field, remove and ignore any header field(s) from the message with this field, remove and ignore any header field(s) from the message
the same name as the connection-token. This protects against with the same name as the connection-token. This protects against
mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
See Appendix B.2. See Appendix B.2.
9.2. Content-Length 9.2. Content-Length
The "Content-Length" header field indicates the size of the message- The "Content-Length" header field indicates the size of the message-
body, in decimal number of octets, for any message other than a 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. 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 In the case of responses to the HEAD method, it indicates the size of
the payload body (not including any potential transfer-coding) that the payload body (not including any potential transfer-coding) that
skipping to change at page 51, line 51 skipping to change at page 52, line 7
(Internal Server Error) or 503 (Service Unavailable), and it is (Internal Server Error) or 503 (Service Unavailable), and it is
inconvenient or impossible to generate a valid Date. inconvenient or impossible to generate a valid Date.
3. If the server does not have a clock that can provide a reasonable 3. If the server does not have a clock that can provide a reasonable
approximation of the current time, its responses MUST NOT include approximation of the current time, its responses MUST NOT include
a Date header field. In this case, the rules in Section 9.3.1 a Date header field. In this case, the rules in Section 9.3.1
MUST be followed. MUST be followed.
A received message that does not have a Date header field MUST be 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 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 recipient or gatewayed via a protocol which requires a Date.
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 Clients can use the Date header field as well; in order to keep
a payload, as is usually the case for PUT and POST requests, and even request messages small, they are advised not to include it when it
then it is optional. A client without a clock MUST NOT send a Date doesn't convey any useful information (as it is usually the case for
header field in a request. requests that do not contain a payload).
The HTTP-date sent in a Date header SHOULD NOT represent a date and The HTTP-date sent in a Date header field SHOULD NOT represent a date
time subsequent to the generation of the message. It SHOULD and time subsequent to the generation of the message. It SHOULD
represent the best available approximation of the date and time of represent the best available approximation of the date and time of
message generation, unless the implementation has no means of message generation, unless the implementation has no means of
generating a reasonably accurate date and time. In theory, the date generating a reasonably accurate date and time. In theory, the date
ought to represent the moment just before the payload is generated. ought to represent the moment just before the payload is generated.
In practice, the date can be generated at any time during the message In practice, the date can be generated at any time during the message
origination without affecting its semantic value. origination without affecting its semantic value.
9.3.1. Clockless Origin Server Operation 9.3.1. Clockless Origin Server Operation
Some origin server implementations might not have a clock available. Some origin server implementations might not have a clock available.
skipping to change at page 55, line 36 skipping to change at page 55, line 34
Transfer-codings are defined in Section 6.2. An example is: Transfer-codings are defined in Section 6.2. An example is:
Transfer-Encoding: chunked Transfer-Encoding: chunked
If multiple encodings have been applied to a representation, the If multiple encodings have been applied to a representation, the
transfer-codings MUST be listed in the order in which they were transfer-codings MUST be listed in the order in which they were
applied. Additional information about the encoding parameters MAY be applied. Additional information about the encoding parameters MAY be
provided by other header fields not defined by this specification. provided by other header fields not defined by this specification.
Many older HTTP/1.0 applications do not understand the Transfer- Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header. Encoding header field.
9.8. Upgrade 9.8. Upgrade
The "Upgrade" general-header field allows the client to specify what The "Upgrade" general-header field allows the client to specify what
additional communication protocols it would like to use, if the additional communication protocols it would like to use, if the
server chooses to switch protocols. Additionally, the server MUST server chooses to switch protocols. Additionally, the server MUST
use the Upgrade header field within a 101 (Switching Protocols) use the Upgrade header field within a 101 (Switching Protocols)
response to indicate which protocol(s) are being switched to. response to indicate which protocol(s) are being switched to.
Upgrade = "Upgrade" ":" OWS Upgrade-v Upgrade = "Upgrade" ":" OWS Upgrade-v
skipping to change at page 66, line 36 skipping to change at page 66, line 36
13.1. Normative References 13.1. Normative References
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998. 1", ISO/IEC 8859-1:1998, 1998.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-11 (work in Semantics", draft-ietf-httpbis-p2-semantics-12 (work in
progress), August 2010. progress), October 2010.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
Payload and Content Negotiation", Payload and Content Negotiation",
draft-ietf-httpbis-p3-payload-11 (work in progress), draft-ietf-httpbis-p3-payload-12 (work in progress),
August 2010. October 2010.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., Nottingham, M., Ed., and J. Reschke, Ed., Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 6: Caching", "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-11 (work in progress), draft-ietf-httpbis-p6-cache-12 (work in progress),
August 2010. October 2010.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus it might be less RFC 1950 is an Informational RFC, thus it might be less
stable than this specification. On the other hand, stable than this specification. On the other hand,
this downward reference was present since the this downward reference was present since the
publication of RFC 2068 in 1997 ([RFC2068]), therefore publication of RFC 2068 in 1997 ([RFC2068]), therefore
it is unlikely to cause problems in practice. See also it is unlikely to cause problems in practice. See also
[BCP97]. [BCP97].
skipping to change at page 67, line 41 skipping to change at page 67, line 41
this downward reference was present since the this downward reference was present since the
publication of RFC 2068 in 1997 ([RFC2068]), therefore publication of RFC 2068 in 1997 ([RFC2068]), therefore
it is unlikely to cause problems in practice. See also it is unlikely to cause problems in practice. See also
[BCP97]. [BCP97].
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
RFC 3986, STD 66, January 2005. STD 66, RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008. January 2008.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
13.2. Informative References 13.2. Informative References
skipping to change at page 68, line 33 skipping to change at page 68, line 33
[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
Computer Networks and ISDN Systems v. 28, pp. 25-35, Computer Networks and ISDN Systems v. 28, pp. 25-35,
December 1995, December 1995,
<http://portal.acm.org/citation.cfm?id=219094>. <http://portal.acm.org/citation.cfm?id=219094>.
[RFC1123] Braden, R., "Requirements for Internet Hosts - [RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
October 1989. 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", [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
RFC 1900, February 1996. RFC 1900, February 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996. May 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
skipping to change at page 70, line 19 skipping to change at page 70, line 19
implementation. We therefore recommend that operational applications implementation. We therefore recommend that operational applications
be tolerant of deviations whenever those deviations can be be tolerant of deviations whenever those deviations can be
interpreted unambiguously. interpreted unambiguously.
Clients SHOULD be tolerant in parsing the Status-Line and servers Clients SHOULD be tolerant in parsing the Status-Line and servers
SHOULD be tolerant when parsing the Request-Line. In particular, SHOULD be tolerant when parsing the Request-Line. In particular,
they SHOULD accept any amount of WSP characters between fields, even they SHOULD accept any amount of WSP characters between fields, even
though only a single SP is required. though only a single SP is required.
The line terminator for header fields is the sequence CRLF. However, The line terminator for header fields is the sequence CRLF. However,
we recommend that applications, when parsing such headers, recognize we recommend that applications, when parsing such headers fields,
a single LF as a line terminator and ignore the leading CR. 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 The character set of a representation SHOULD be labeled as the lowest
common denominator of the character codes used within that common denominator of the character codes used within that
representation, with the exception that not labeling the representation, with the exception that not labeling the
representation is preferred over labeling the representation with the representation is preferred over labeling the representation with the
labels US-ASCII or ISO-8859-1. See [Part3]. labels US-ASCII or ISO-8859-1. See [Part3].
Additional rules for requirements on parsing and encoding of dates Additional rules for requirements on parsing and encoding of dates
and other potential problems with date encodings include: and other potential problems with date encodings include:
skipping to change at page 70, line 48 skipping to change at page 70, line 48
o An HTTP/1.1 implementation MAY internally represent a parsed o An HTTP/1.1 implementation MAY internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the internally represent a parsed Expires date as later than the
proper value. proper value.
o All expiration-related calculations MUST be done in GMT. The o All expiration-related calculations MUST be done in GMT. The
local time zone MUST NOT influence the calculation or comparison local time zone MUST NOT influence the calculation or comparison
of an age or expiration time. of an age or expiration time.
o If an HTTP header incorrectly carries a date value with a time o If an HTTP header field incorrectly carries a date value with a
zone other than GMT, it MUST be converted into GMT using the most time zone other than GMT, it MUST be converted into GMT using the
conservative possible conversion. most conservative possible conversion.
Appendix B. Compatibility with Previous Versions Appendix B. Compatibility with Previous Versions
HTTP has been in use by the World-Wide Web global information HTTP has been in use by the World-Wide Web global information
initiative since 1990. The first version of HTTP, later referred to initiative since 1990. The first version of HTTP, later referred to
as HTTP/0.9, was a simple protocol for hypertext data transfer across 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 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 defined by [RFC1945], added a range of request methods and MIME-like
messaging that could include metadata about the data transferred and messaging that could include metadata about the data transferred and
modifiers on the request/response semantics. However, HTTP/1.0 did modifiers on the request/response semantics. However, HTTP/1.0 did
skipping to change at page 72, line 9 skipping to change at page 72, line 9
B.1. Changes from HTTP/1.0 B.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP
Addresses Addresses
The requirements that clients and servers support the Host request- The requirements that clients and servers support the Host request-
header, report an error if the Host request-header (Section 9.4) is header field (Section 9.4), report an error if it is missing from an
missing from an HTTP/1.1 request, and accept absolute URIs HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among
(Section 4.1.2) are among the most important changes defined by this the most important changes defined by this specification.
specification.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The changes outlined above will to which that request was directed. The changes outlined above will
allow the Internet, once older HTTP clients are no longer common, to allow the Internet, once older HTTP clients are no longer common, to
support multiple Web sites from a single IP address, greatly support multiple Web sites from a single IP address, greatly
simplifying large operational Web servers, where allocation of many simplifying large operational Web servers, where allocation of many
IP addresses to a single host has created serious problems. The IP addresses to a single host has created serious problems. The
Internet will also be able to recover the IP addresses that have been Internet will also be able to recover the IP addresses that have been
allocated for the sole purpose of allowing special-purpose domain allocated for the sole purpose of allowing special-purpose domain
names to be used in root-level HTTP URLs. Given the rate of growth 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 of the Web, and the number of servers already deployed, it is
extremely important that all implementations of HTTP (including extremely important that all implementations of HTTP (including
updates to existing HTTP/1.0 applications) correctly implement these updates to existing HTTP/1.0 applications) correctly implement these
requirements: requirements:
o Both clients and servers MUST support the Host request-header. o Both clients and servers MUST support the Host request-header
field.
o A client that sends an HTTP/1.1 request MUST send a Host header. o A client that sends an HTTP/1.1 request MUST send a Host header
field.
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header. request does not include a Host request-header field.
o Servers MUST accept absolute URIs. o Servers MUST accept absolute URIs.
B.2. Compatibility with HTTP/1.0 Persistent Connections B.2. Compatibility with HTTP/1.0 Persistent Connections
Some clients and servers might wish to be compatible with some Some clients and servers might wish to be compatible with some
previous implementations of persistent connections in HTTP/1.0 previous implementations of persistent connections in HTTP/1.0
clients and servers. Persistent connections in HTTP/1.0 are clients and servers. Persistent connections in HTTP/1.0 are
explicitly negotiated as they are not the default behavior. HTTP/1.0 explicitly negotiated as they are not the default behavior. HTTP/1.0
experimental implementations of persistent connections are faulty, experimental implementations of persistent connections are faulty,
skipping to change at page 73, line 15 skipping to change at page 73, line 16
However, talking to proxies is the most important use of persistent However, talking to proxies is the most important use of persistent
connections, so that prohibition is clearly unacceptable. Therefore, connections, so that prohibition is clearly unacceptable. Therefore,
we need some other mechanism for indicating a persistent connection we need some other mechanism for indicating a persistent connection
is desired, which is safe to use even when talking to an old proxy is desired, which is safe to use even when talking to an old proxy
that ignores Connection. Persistent connections are the default for that ignores Connection. Persistent connections are the default for
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
declaring non-persistence. See Section 9.1. declaring non-persistence. See Section 9.1.
The original HTTP/1.0 form of persistent connections (the Connection: The original HTTP/1.0 form of persistent connections (the Connection:
Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of Keep-Alive and Keep-Alive header field) is documented in Section
[RFC2068]. 19.7.1 of [RFC2068].
B.3. Changes from RFC 2616 B.3. Changes from RFC 2616
Empty list elements in list productions have been deprecated. Empty list elements in list productions have been deprecated.
(Section 1.2.1) (Section 1.2.1)
Rules about implicit linear whitespace between certain grammar Rules about implicit linear whitespace between certain grammar
productions have been removed; now it's only allowed when productions have been removed; now it's only allowed when
specifically pointed out in the ABNF. The NUL character is no longer specifically pointed out in the ABNF. The NUL character is no longer
allowed in comment and quoted-string text. The quoted-pair rule no allowed in comment and quoted-string text. The quoted-pair rule no
longer allows escaping control characters other than HTAB. Non-ASCII longer allows escaping control characters other than HTAB. Non-ASCII
content in header fields and reason phrase has been obsoleted and content in header fields and reason phrase has been obsoleted and
made opaque (the TEXT rule was removed) (Section 1.2.2) made opaque (the TEXT rule was removed) (Section 1.2.2)
Clarify that HTTP-Version is case sensitive. (Section 2.5) 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. Require that invalid whitespace around field-names be rejected.
(Section 3.2) (Section 3.2)
Update use of abs_path production from RFC1808 to the path-absolute + Require recipients to handle bogus Content-Length header fields as
query components of RFC3986. (Section 4.1.2) errors. (Section 3.3)
Remove reference to non-existent identity transfer-coding value
tokens. (Sections 3.3 and 6.2)
Update use of abs_path production from RFC 1808 to the path-absolute
+ query components of RFC 3986. (Section 4.1.2)
Clarification that the chunk length does not include the count of the Clarification that the chunk length does not include the count of the
octets in the chunk header and trailer. Furthermore disallowed line octets in the chunk header and trailer. Furthermore disallowed line
folding in chunk extensions. (Section 6.2.1) folding in chunk extensions. (Section 6.2.1)
Remove hard limit of two connections per server. (Section 7.1.4) Remove hard limit of two connections per server. (Section 7.1.4)
Clarify exactly when close connection options must be sent. Clarify exactly when close connection options must be sent.
(Section 9.1) (Section 9.1)
Appendix C. Collected ABNF Appendix C. Collected ABNF
BWS = OWS BWS = OWS
Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> Cache-Control = <Cache-Control, defined in [Part6], Section 3.4>
Chunked-Body = *chunk last-chunk trailer-part CRLF Chunked-Body = *chunk last-chunk trailer-part CRLF
Connection = "Connection:" OWS Connection-v Connection = "Connection:" OWS Connection-v
Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS
connection-token ] ) connection-token ] )
Content-Length = "Content-Length:" OWS 1*Content-Length-v Content-Length = "Content-Length:" OWS 1*Content-Length-v
Content-Length-v = 1*DIGIT Content-Length-v = 1*DIGIT
skipping to change at page 77, line 43 skipping to change at page 78, line 4
token = 1*tchar token = 1*tchar
trailer-part = *( header-field CRLF ) trailer-part = *( header-field CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = attribute BWS "=" BWS value transfer-parameter = attribute BWS "=" BWS value
uri-host = <host, defined in [RFC3986], Section 3.2.2> uri-host = <host, defined in [RFC3986], Section 3.2.2>
value = word value = word
word = token / quoted-string word = token / quoted-string
year = 4DIGIT year = 4DIGIT
ABNF diagnostics: ABNF diagnostics:
; Chunked-Body defined but not used ; Chunked-Body defined but not used
; Content-Length defined but not used ; Content-Length defined but not used
; HTTP-message defined but not used ; HTTP-message defined but not used
; Host defined but not used ; Host defined but not used
; Request defined but not used ; Request defined but not used
; Response defined but not used ; Response defined but not used
; TE defined but not used ; TE defined but not used
; URI-reference defined but not used ; URI-reference defined but not used
; general-header defined but not used ; general-header defined but not used
; http-URI defined but not used ; http-URI defined but not used
; https-URI defined but not used ; https-URI defined but not used
; partial-URI defined but not used ; partial-URI defined but not used
; request-header defined but not used ; request-header defined but not used
; response-header defined but not used ; response-header defined but not used
; special defined but not used ; special defined but not used
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
D.1. Since RFC2616 D.1. Since RFC 2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
D.2. Since draft-ietf-httpbis-p1-messaging-00 D.2. Since draft-ietf-httpbis-p1-messaging-00
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
should be case sensitive" should be case sensitive"
(<http://purl.org/NET/http-errata#verscase>) (<http://purl.org/NET/http-errata#verscase>)
skipping to change at page 80, line 42 skipping to change at page 80, line 43
"host) -- these will have to be updated when switching over to "host) -- these will have to be updated when switching over to
RFC3986. RFC3986.
o Synchronize core rules with RFC5234. o Synchronize core rules with RFC5234.
o Get rid of prose rules that span multiple lines. o Get rid of prose rules that span multiple lines.
o Get rid of unused rules LOALPHA and UPALPHA. o Get rid of unused rules LOALPHA and UPALPHA.
o Move "Product Tokens" section (back) into Part 1, as "token" is o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header. used in the definition of the Upgrade header field.
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
"TEXT". "TEXT".
D.4. Since draft-ietf-httpbis-p1-messaging-02 D.4. Since draft-ietf-httpbis-p1-messaging-02
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
rfc1123-date" rfc1123-date"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
pair" pair"
Ongoing work on IANA Message Header Registration Ongoing work on IANA Message Header Field Registration
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header registrations for headers o Reference RFC 3984, and update header field registrations for
defined in this document. headers defined in this document.
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive o Replace string literals when the string really is case-sensitive
(HTTP-Version). (HTTP-Version).
D.5. Since draft-ietf-httpbis-p1-messaging-03 D.5. Since draft-ietf-httpbis-p1-messaging-03
Closed issues: Closed issues:
skipping to change at page 82, line 34 skipping to change at page 82, line 34
o Use "/" instead of "|" for alternatives. o Use "/" instead of "|" for alternatives.
o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. o Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
o Only reference RFC 5234's core rules. o Only reference RFC 5234's core rules.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS"). whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header o Rewrite ABNFs to spell out whitespace rules, factor out header
value format definitions. field value format definitions.
D.7. Since draft-ietf-httpbis-p1-messaging-05 D.7. Since draft-ietf-httpbis-p1-messaging-05
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" 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 o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3
Terminology" Terminology"
skipping to change at page 83, line 30 skipping to change at page 83, line 30
o Rewrite definition of list rules, deprecate empty list elements. o Rewrite definition of list rules, deprecate empty list elements.
o Add appendix containing collected and expanded ABNF. o Add appendix containing collected and expanded ABNF.
Other changes: Other changes:
o Rewrite introduction; add mostly new Architecture Section. o Rewrite introduction; add mostly new Architecture Section.
o Move definition of quality values from Part 3 into Part 1; make TE o Move definition of quality values from Part 3 into Part 1; make TE
request header grammar independent of accept-params (defined in request header field grammar independent of accept-params (defined
Part 3). in Part 3).
D.8. Since draft-ietf-httpbis-p1-messaging-06 D.8. Since draft-ietf-httpbis-p1-messaging-06
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
numeric protocol elements" numeric protocol elements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
skipping to change at page 86, line 10 skipping to change at page 86, line 10
entity / representation / variant terminology" entity / representation / variant terminology"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
removing the 'changes from 2068' sections" removing the 'changes from 2068' sections"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
scheme definitions" scheme definitions"
D.13. Since draft-ietf-httpbis-p1-messaging-11
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer
requirements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about
clock requirement for caches belongs in p6"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective
request URI: handling of missing host in HTTP/1.0"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing
Date requirements for clients"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
multiple Content-Length headers"
Index Index
A A
absolute-URI form (of request-target) 27
application/http Media Type 61 application/http Media Type 61
asterisk form (of request-target) 27
authority form (of request-target) 27
B B
browser 10 browser 10
C C
cache 13 cache 13
cacheable 14 cacheable 14
chunked (Coding Format) 35 chunked (Coding Format) 35
client 10 client 10
Coding Format Coding Format
skipping to change at page 90, line 6 skipping to change at page 90, line 29
application/http 61 application/http 61
message/http 59 message/http 59
message 11 message 11
message/http Media Type 59 message/http Media Type 59
O O
origin server 10 origin server 10
outbound 12 outbound 12
P P
path-absolute form (of request-target) 27
proxy 12 proxy 12
R R
request 11 request 11
resource 16 resource 16
response 11 response 11
reverse proxy 13 reverse proxy 13
S S
server 10 server 10
 End of changes. 77 change blocks. 
142 lines changed or deleted 169 lines changed or added

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