draft-ietf-httpbis-p1-messaging-02.txt   draft-ietf-httpbis-p1-messaging-03.txt 
Network Working Group R. Fielding, Ed. Network Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: August 27, 2008 J. Mogul Expires: December 19, 2008 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
February 24, 2008 June 17, 2008
HTTP/1.1, part 1: URIs, Connections, and Message Parsing HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-ietf-httpbis-p1-messaging-02 draft-ietf-httpbis-p1-messaging-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2008. This Internet-Draft will expire on December 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
an overview of HTTP and its associated terminology, defines the an overview of HTTP and its associated terminology, defines the
skipping to change at page 2, line 30 skipping to change at page 2, line 26
frames, and describes general security concerns for implementations. frames, and describes general security concerns for implementations.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://www.tools.ietf.org/wg/httpbis/>. <http://www.tools.ietf.org/wg/httpbis/>.
This draft incorporates those issue resolutions that were either The changes in this draft are summarized in Appendix E.4.
collected in the original RFC2616 errata list
(<http://purl.org/NET/http-errata>), or which were agreed upon on the
mailing list between October 2006 and November 2007 (as published in
"draft-lafon-rfc2616bis-03").
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9
2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 4, line 16 skipping to change at page 4, line 16
8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40
8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42
8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44
8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 47 9.1. Message Header Registration . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 48
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 48 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 49
10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 49 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 50
10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . . 52 12.2. Informative References . . . . . . . . . . . . . . . . . . 53
Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 54 Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 55
A.1. Internet Media Type message/http . . . . . . . . . . . . . 54 A.1. Internet Media Type message/http . . . . . . . . . . . . . 55
A.2. Internet Media Type application/http . . . . . . . . . . . 56 A.2. Internet Media Type application/http . . . . . . . . . . . 56
Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57 Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57
Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58 Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58
Appendix D. Compatibility with Previous Versions . . . . . . . . 58 Appendix D. Compatibility with Previous Versions . . . . . . . . 58
D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 58 D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59
D.1.1. Changes to Simplify Multi-homed Web Servers and D.1.1. Changes to Simplify Multi-homed Web Servers and
Conserve IP Addresses . . . . . . . . . . . . . . . . 59 Conserve IP Addresses . . . . . . . . . . . . . . . . 59
D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59 D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 60
D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60
D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 60 D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 61 publication) . . . . . . . . . . . . . . . . . . . . 61
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61
E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61
E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62 E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 63
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Intellectual Property and Copyright Statements . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
Intellectual Property and Copyright Statements . . . . . . . . . . 71
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World-Wide Web global systems. HTTP has been in use by the World-Wide Web global
information initiative since 1990. The first version of HTTP, information initiative since 1990. The first version of HTTP,
commonly referred to as HTTP/0.9, was a simple protocol for raw data commonly referred to as HTTP/0.9, was a simple protocol for raw data
transfer across the Internet with only a single method and no transfer across the Internet with only a single method and no
metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol
skipping to change at page 15, line 46 skipping to change at page 15, line 46
A string of text is parsed as a single word if it is quoted using A string of text is parsed as a single word if it is quoted using
double-quote marks. double-quote marks.
quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE ) quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE )
qdtext = <any TEXT excluding DQUOTE and "\"> qdtext = <any TEXT excluding DQUOTE and "\">
The backslash character ("\") MAY be used as a single-character The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs. quoting mechanism only within quoted-string and comment constructs.
quoted-pair = "\" CHAR quoted-text = %x01-09 |
%x0B-0C |
%x0E-FF ; Characters excluding NUL, CR and LF
quoted-pair = "\" quoted-text
2.3. ABNF Rules defined in other Parts of the Specification 2.3. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
request-header = <request-header, defined in [Part2], Section 4> request-header = <request-header, defined in [Part2], Section 4>
response-header = <response-header, defined in [Part2], Section 6> response-header = <response-header, defined in [Part2], Section 6>
accept-params = <accept-params, defined in [Part3], Section 6.1> accept-params = <accept-params, defined in [Part3], Section 6.1>
entity-body = <entity-body, defined in [Part3], Section 4.2> entity-body = <entity-body, defined in [Part3], Section 4.2>
skipping to change at page 16, line 41 skipping to change at page 16, line 41
The <minor> number is incremented when the changes made to the The <minor> number is incremented when the changes made to the
protocol add features which do not change the general message parsing protocol add features which do not change the general message parsing
algorithm, but which may add to the message semantics and imply algorithm, but which may add to the message semantics and imply
additional capabilities of the sender. The <major> number is additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is incremented when the format of a message within the protocol is
changed. See [RFC2145] for a fuller explanation. changed. See [RFC2145] for a fuller explanation.
The version of an HTTP message is indicated by an HTTP-Version field 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. in the first line of the message. HTTP-Version is case-sensitive.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT 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 Note that the major and minor numbers MUST be treated as separate
integers and that each MAY be incremented higher than a single digit. 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 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 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
and MUST NOT be sent. and MUST NOT be sent.
An application that sends a request or response message that includes An application that sends a request or response message that includes
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
with this specification. Applications that are at least with this specification. Applications that are at least
skipping to change at page 20, line 8 skipping to change at page 20, line 10
All HTTP date/time stamps MUST be represented in Greenwich Mean Time All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly (GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time). This is indicated in the equal to UTC (Coordinated Universal Time). This is indicated in the
first two formats by the inclusion of "GMT" as the three-letter first two formats by the inclusion of "GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include asctime format. HTTP-date is case sensitive and MUST NOT include
additional LWS beyond that specifically included as SP in the additional LWS beyond that specifically included as SP in the
grammar. grammar.
HTTP-date = rfc1123-date | rfc850-date | asctime-date HTTP-date = rfc1123-date | obsolete-date
obsolete-date = rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT" rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982) ; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82) ; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2) ; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
skipping to change at page 46, line 22 skipping to change at page 46, line 22
version rules of Section 3.1 and future updates to this version rules of Section 3.1 and future updates to this
specification. Any token can be used as a protocol name; however, it specification. Any token can be used as a protocol name; however, it
will only be useful if both the client and server associate the name will only be useful if both the client and server associate the name
with the same protocol. with the same protocol.
8.9. Via 8.9. Via
The Via general-header field MUST be used by gateways and proxies to The Via general-header field MUST be used by gateways and proxies to
indicate the intermediate protocols and recipients between the user indicate the intermediate protocols and recipients between the user
agent and the server on requests, and between the origin server and agent and the server on requests, and between the origin server and
the client on responses. It is analogous to the "Received" field of the client on responses. It is analogous to the "Received" field
[RFC2822] and is intended to be used for tracking message forwards, defined in Section 3.6.7 of [RFC2822] and is intended to be used for
avoiding request loops, and identifying the protocol capabilities of tracking message forwards, avoiding request loops, and identifying
all senders along the request/response chain. the protocol capabilities of all senders along the request/response
chain.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
received-by = ( uri-host [ ":" port ] ) | pseudonym received-by = ( uri-host [ ":" port ] ) | pseudonym
pseudonym = token pseudonym = token
The received-protocol indicates the protocol version of the message The received-protocol indicates the protocol version of the message
received by the server or client along each segment of the request/ received by the server or client along each segment of the request/
skipping to change at page 47, line 45 skipping to change at page 47, line 46
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Applications SHOULD NOT combine multiple entries unless they are all Applications SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been under the same organizational control and the hosts have already been
replaced by pseudonyms. Applications MUST NOT combine entries which replaced by pseudonyms. Applications MUST NOT combine entries which
have different received-protocol values. have different received-protocol values.
9. IANA Considerations 9. IANA Considerations
[[anchor1: TBD.]] 9.1. Message Header Registration
The Message Header Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> should be
updated with the permanent registrations below (see [RFC3864]):
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Connection | http | standard | Section 8.1 |
| Content-Length | http | standard | Section 8.2 |
| Date | http | standard | Section 8.3 |
| Host | http | standard | Section 8.4 |
| TE | http | standard | Section 8.5 |
| Trailer | http | standard | Section 8.6 |
| Transfer-Encoding | http | standard | Section 8.7 |
| Upgrade | http | standard | Section 8.8 |
| Via | http | standard | Section 8.9 |
+-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force".
10. Security Considerations 10. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
10.1. Personal Information 10.1. Personal Information
skipping to change at page 51, line 43 skipping to change at page 52, line 16
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-02 (work in Semantics", draft-ietf-httpbis-p2-semantics-03 (work in
progress), February 2008. progress), June 2008.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-02 and Content Negotiation", draft-ietf-httpbis-p3-payload-03
(work in progress), February 2008. (work in progress), June 2008.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-02 (work Partial Responses", draft-ietf-httpbis-p5-range-03 (work
in progress), February 2008. in progress), June 2008.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-02 (work in progress), draft-ietf-httpbis-p6-cache-03 (work in progress),
February 2008. June 2008.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 54, line 13 skipping to change at page 54, line 35
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006. RFC 3977, October 2006.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet [RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
skipping to change at page 60, line 48 skipping to change at page 61, line 23
codings), a new header field (TE) and enabling trailer headers in the codings), a new header field (TE) and enabling trailer headers in the
future. Transfer encoding is a major performance benefit, so it was future. Transfer encoding is a major performance benefit, so it was
worth fixing [Nie1997]. TE also solves another, obscure, downward worth fixing [Nie1997]. TE also solves another, obscure, downward
interoperability problem that could have occurred due to interactions interoperability problem that could have occurred due to interactions
between authentication trailers, chunked encoding and HTTP/1.0 between authentication trailers, chunked encoding and HTTP/1.0
clients.(Section 3.4, 3.4.1, and 8.5) clients.(Section 3.4, 3.4.1, and 8.5)
D.4. Changes from RFC 2616 D.4. Changes from RFC 2616
The CHAR rule does not allow the NUL character anymore (this affects The CHAR rule does not allow the NUL character anymore (this affects
the comment and quoted-string rules). (Section 2.2) the comment and quoted-string rules). Furthermore, the quoted-pair
rule does not allow escaping NUL, CR or LF anymore. (Section 2.2)
Clarify that HTTP-Version is case sensitive. (Section 3.1) Clarify that HTTP-Version is case sensitive. (Section 3.1)
Remove reference to non-existant identity transfer-coding value Remove reference to non-existant identity transfer-coding value
tokens. (Sections 3.4 and 4.4) tokens. (Sections 3.4 and 4.4)
Clarification that the chunk length does not include the count of the Clarification that the chunk length does not include the count of the
octets in the chunk header and trailer. (Section 3.4.1) octets in the chunk header and trailer. (Section 3.4.1)
Fix BNF to add query, as the abs_path production in Section 3 of Fix BNF to add query, as the abs_path production in Section 3 of
[RFC2396] doesn't define it. (Section 5.1.2) [RFC2396] doesn't define it. (Section 5.1.2)
Clarify exactly when close connection options must be sent. Clarify exactly when close connection options must be sent.
skipping to change at page 63, line 43 skipping to change at page 64, line 22
o Move "Product Tokens" section (back) into Part 1, as "token" is o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header. used in the definition of the Upgrade header.
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
"TEXT". "TEXT".
E.4. Since draft-ietf-httpbis-p1-messaging-02
Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date
vs. rfc1123-date"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in
quoted-pair"
Ongoing work on IANA Message Header Registration
(<http://www3.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://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive
(HTTP-Version).
Index Index
A A
application/http Media Type 56 application/http Media Type 56
C C
cache 8 cache 8
cacheable 9 cacheable 9
client 7 client 7
connection 6 connection 6
skipping to change at page 65, line 11 skipping to change at page 66, line 12
field-content 25 field-content 25
field-name 25 field-name 25
field-value 25 field-value 25
general-header 28 general-header 28
generic-message 24 generic-message 24
HEX 15 HEX 15
Host 42 Host 42
HTAB 14 HTAB 14
HTTP-date 20 HTTP-date 20
HTTP-message 24 HTTP-message 24
HTTP-Prot-Name 16
http-URL 18 http-URL 18
HTTP-Version 16 HTTP-Version 16
last-chunk 22 last-chunk 22
LF 14 LF 14
LWS 14 LWS 14
message-body 25 message-body 25
message-header 25 message-header 25
Method 29 Method 29
month 20 month 20
obsolete-date 20
OCTET 14 OCTET 14
parameter 20 parameter 20
path-absolute 18 path-absolute 18
port 18 port 18
product 23 product 23
product-version 23 product-version 23
protocol-name 46 protocol-name 46
protocol-version 46 protocol-version 46
pseudonym 46 pseudonym 46
qdtext 15 qdtext 15
query 18 query 18
quoted-pair 15 quoted-pair 15
quoted-string 15 quoted-string 15
quoted-text 15
Reason-Phrase 32 Reason-Phrase 32
received-by 46 received-by 46
received-protocol 46 received-protocol 46
relativeURI 18 relativeURI 18
Request 28 Request 28
Request-Line 28 Request-Line 28
Request-URI 29 Request-URI 29
Response 31 Response 31
rfc850-date 20 rfc850-date 20
rfc1123-date 20 rfc1123-date 20
skipping to change at page 66, line 32 skipping to change at page 67, line 36
Date 41 Date 41
Host 42 Host 42
TE 43 TE 43
Trailer 44 Trailer 44
Transfer-Encoding 44 Transfer-Encoding 44
Upgrade 45 Upgrade 45
Via 46 Via 46
Host header 42 Host header 42
I I
implied *LWS 13
inbound 9 inbound 9
M M
Media Type Media Type
application/http 56 application/http 56
message/http 54 message/http 55
message 6 message 6
message/http Media Type 54 message/http Media Type 55
O O
origin server 8 origin server 8
outbound 9 outbound 9
P P
proxy 8 proxy 8
R R
representation 7 representation 7
request 6 request 6
resource 7 resource 7
response 6 response 6
S S
server 8 server 8
T T
skipping to change at page 70, line 44 skipping to change at line 3284
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 34 change blocks. 
48 lines changed or deleted 100 lines changed or added

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