draft-ietf-httpbis-p1-messaging-06.txt   draft-ietf-httpbis-p1-messaging-07.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
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: September 10, 2009 J. Mogul Expires: January 14, 2010 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
March 9, 2009 July 13, 2009
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-06 draft-ietf-httpbis-p1-messaging-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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."
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 September 10, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 44 skipping to change at page 2, line 44
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/11> and related at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.7. The changes in this draft are summarized in Appendix E.8.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7
1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8
1.2.3. ABNF Rules defined in other Parts of the 1.2.3. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 9 Specification . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 27 skipping to change at page 3, line 27
2.1.2. https URI scheme . . . . . . . . . . . . . . . . . . . 11 2.1.2. https URI scheme . . . . . . . . . . . . . . . . . . . 11
2.1.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 11 2.1.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 11
2.1.4. Scheme aliases considered harmful . . . . . . . . . . 12 2.1.4. Scheme aliases considered harmful . . . . . . . . . . 12
2.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 12 2.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 12
2.3. Use of HTTP for proxy communication . . . . . . . . . . . 14 2.3. Use of HTTP for proxy communication . . . . . . . . . . . 14
2.4. Interception of HTTP for access control . . . . . . . . . 14 2.4. Interception of HTTP for access control . . . . . . . . . 14
2.5. Use of HTTP by other protocols . . . . . . . . . . . . . . 14 2.5. Use of HTTP by other protocols . . . . . . . . . . . . . . 14
2.6. Use of HTTP by media type specification . . . . . . . . . 14 2.6. Use of HTTP by media type specification . . . . . . . . . 14
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 14 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 14
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 15 3.2. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 15
3.2.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 18
3.3. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 17 3.3.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 19
3.3.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 18 3.4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 21
3.4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 20 3.5. Quality Values . . . . . . . . . . . . . . . . . . . . . . 22
3.5. Quality Values . . . . . . . . . . . . . . . . . . . . . . 21 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 22 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 23 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 24 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 27
4.5. General Header Fields . . . . . . . . . . . . . . . . . . 26 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27 5.1.2. request-target . . . . . . . . . . . . . . . . . . . . 28
5.2. The Resource Identified by a Request . . . . . . . . . . . 29 5.2. The Resource Identified by a Request . . . . . . . . . . . 30
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 31 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 31 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 32 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 32
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 33 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 33 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 34
7.2. Message Transmission Requirements . . . . . . . . . . . . 34 7.2. Message Transmission Requirements . . . . . . . . . . . . 35
7.2.1. Persistent Connections and Flow Control . . . . . . . 34 7.2.1. Persistent Connections and Flow Control . . . . . . . 35
7.2.2. Monitoring Connections for Error Status Messages . . . 35 7.2.2. Monitoring Connections for Error Status Messages . . . 35
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 35 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 37 Connection . . . . . . . . . . . . . . . . . . . . . . 38
8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 38 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 38
8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 39 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40
8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.3.1. Clockless Origin Server Operation . . . . . . . . . . 41 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 41
8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 43 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44
8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
9.1. Message Header Registration . . . . . . . . . . . . . . . 47 9.1. Message Header Registration . . . . . . . . . . . . . . . 47
9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 47 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 48
9.3. Internet Media Type Registrations . . . . . . . . . . . . 47 9.3. Internet Media Type Registrations . . . . . . . . . . . . 48
9.3.1. Internet Media Type message/http . . . . . . . . . . . 47 9.3.1. Internet Media Type message/http . . . . . . . . . . . 48
9.3.2. Internet Media Type application/http . . . . . . . . . 48 9.3.2. Internet Media Type application/http . . . . . . . . . 49
10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 50 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 51
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 50 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 51
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 50 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 51
10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 51 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 51
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 51 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 52
10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 52 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 53
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.1. Normative References . . . . . . . . . . . . . . . . . . . 53 12.1. Normative References . . . . . . . . . . . . . . . . . . . 54
12.2. Informative References . . . . . . . . . . . . . . . . . . 54 12.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 56 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 57
Appendix B. Compatibility with Previous Versions . . . . . . . . 57 Appendix B. Compatibility with Previous Versions . . . . . . . . 58
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 58 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59
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 . . . . . . . . . . . . . . . . 58 Conserve IP Addresses . . . . . . . . . . . . . . . . 59
B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59
B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 59 B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60
B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 60 B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61
Appendix C. Terminology . . . . . . . . . . . . . . . . . . . . . 60 Appendix C. Terminology . . . . . . . . . . . . . . . . . . . . . 61
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 64 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 64
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 68 publication) . . . . . . . . . . . . . . . . . . . . 69
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 68 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 69
E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 68 E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 69
E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 70 E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 70
E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 71 E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 71
E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 71 E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 72
E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 72 E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 72
E.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 72 E.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 73
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 E.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78
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
similar to that used by Internet mail [RFC5322] and the Multipurpose similar to that used by Internet mail [RFC5322] and the Multipurpose
skipping to change at page 9, line 29 skipping to change at page 9, line 29
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
token = 1*tchar token = 1*tchar
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 = *( OWS / %x21 / %x23-5B / %x5D-7E / obs-text ) qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
; OWS / <VCHAR except DQUOTE and "\"> / obs-text
obs-text = %x80-FF obs-text = %x80-FF
The backslash character ("\") MAY be used as a single-character The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs. quoting mechanism only within quoted-string and comment constructs.
quoted-text = %x01-09 / quoted-text = %x01-09 /
%x0B-0C / %x0B-0C /
%x0E-FF ; Characters excluding NUL, CR and LF %x0E-FF ; Characters excluding NUL, CR and LF
quoted-pair = "\" quoted-text quoted-pair = "\" quoted-text
skipping to change at page 15, line 41 skipping to change at page 15, line 41
Due to interoperability problems with HTTP/1.0 proxies discovered Due to interoperability problems with HTTP/1.0 proxies discovered
since the publication of [RFC2068], caching proxies MUST, gateways since the publication of [RFC2068], caching proxies MUST, gateways
MAY, and tunnels MUST NOT upgrade the request to the highest version MAY, and tunnels MUST NOT upgrade the request to the highest version
they support. The proxy/gateway's response to that request MUST be they support. The proxy/gateway's response to that request MUST be
in the same major version as the request. in the same major version as the request.
Note: Converting between versions of HTTP may involve modification Note: Converting between versions of HTTP may involve modification
of header fields required or forbidden by the versions involved. of header fields required or forbidden by the versions involved.
3.2. Date/Time Formats 3.2. Date/Time Formats: Full Date
3.2.1. Full Date
HTTP applications have historically allowed three different formats HTTP applications have historically allowed three different formats
for the representation of date/time stamps: for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The first format is preferred as an Internet standard and represents The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by [RFC1123]. The other a fixed-length subset of that defined by [RFC1123]. The other
formats are described here only for compatibility with obsolete formats are described here only for compatibility with obsolete
implementations. HTTP/1.1 clients and servers that parse the date implementations. HTTP/1.1 clients and servers that parse the date
value MUST accept all three formats (for compatibility with value MUST accept all three formats (for compatibility with
HTTP/1.0), though they MUST only generate the RFC 1123 format for HTTP/1.0), though they MUST only generate the RFC 1123 format for
representing HTTP-date values in header fields. See Appendix A for representing HTTP-date values in header fields. See Appendix A for
further information. further information.
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP.
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 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 / obsolete-date HTTP-date = rfc1123-date / obs-date
obsolete-date = rfc850-date / asctime-date
rfc1123-date = wkday "," SP date1 SP time SP GMT Preferred format:
rfc850-date = weekday "," SP date2 SP time SP GMT
asctime-date = wkday SP date3 SP time SP 4DIGIT rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982) day-name = %x4D.6F.6E ; "Mon", case-sensitive
date2 = 2DIGIT "-" month "-" 2DIGIT / %x54.75.65 ; "Tue", case-sensitive
; day-month-year (e.g., 02-Jun-82) / %x57.65.64 ; "Wed", case-sensitive
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) / %x54.68.75 ; "Thu", case-sensitive
; month day (e.g., Jun 2) / %x46.72.69 ; "Fri", case-sensitive
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT / %x53.61.74 ; "Sat", case-sensitive
; 00:00:00 - 23:59:59 / %x53.75.6E ; "Sun", case-sensitive
wkday = s-Mon / s-Tue / s-Wed
/ s-Thu / s-Fri / s-Sat / s-Sun date1 = day SP month SP year
weekday = l-Mon / l-Tue / l-Wed day = 2DIGIT
/ l-Thu / l-Fri / l-Sat / l-Sun month = %x4A.61.6E ; "Jan", case-sensitive
month = s-Jan / s-Feb / s-Mar / s-Apr / %x46.65.62 ; "Feb", case-sensitive
/ s-May / s-Jun / s-Jul / s-Aug / %x4D.61.72 ; "Mar", case-sensitive
/ s-Sep / s-Oct / s-Nov / s-Dec / %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT
GMT = %x47.4D.54 ; "GMT", case-sensitive GMT = %x47.4D.54 ; "GMT", case-sensitive
s-Mon = %x4D.6F.6E ; "Mon", case-sensitive time-of-day = hour ":" minute ":" second
s-Tue = %x54.75.65 ; "Tue", case-sensitive ; 00:00:00 - 23:59:59
s-Wed = %x57.65.64 ; "Wed", case-sensitive
s-Thu = %x54.68.75 ; "Thu", case-sensitive
s-Fri = %x46.72.69 ; "Fri", case-sensitive
s-Sat = %x53.61.74 ; "Sat", case-sensitive
s-Sun = %x53.75.6E ; "Sun", case-sensitive
l-Mon = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive hour = 2DIGIT
l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive minute = 2DIGIT
l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive second = 2DIGIT
l-Thu = %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
l-Fri = %x46.72.69.64.61.79 ; "Friday", case-sensitive
l-Sat = %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
l-Sun = %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
s-Jan = %x4A.61.6E ; "Jan", case-sensitive The semantics of day-name, day, month, year, and time-of-day are the
s-Feb = %x46.65.62 ; "Feb", case-sensitive same as those defined for the RFC 5322 constructs with the
s-Mar = %x4D.61.72 ; "Mar", case-sensitive corresponding name ([RFC5322], Section 3.3).
s-Apr = %x41.70.72 ; "Apr", case-sensitive
s-May = %x4D.61.79 ; "May", case-sensitive
s-Jun = %x4A.75.6E ; "Jun", case-sensitive
s-Jul = %x4A.75.6C ; "Jul", case-sensitive
s-Aug = %x41.75.67 ; "Aug", case-sensitive
s-Sep = %x53.65.70 ; "Sep", case-sensitive
s-Oct = %x4F.63.74 ; "Oct", case-sensitive
s-Nov = %x4E.6F.76 ; "Nov", case-sensitive
s-Dec = %x44.65.63 ; "Dec", case-sensitive
Note: HTTP requirements for the date/time stamp format apply only to Obsolete formats:
their usage within the protocol stream. Clients and servers are not
required to use these formats for user presentation, request logging, obs-date = rfc850-date / asctime-date
etc. rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; month day (e.g., Jun 2)
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP.
Note: HTTP requirements for the date/time stamp format apply only
to their usage within the protocol stream. Clients and servers
are not required to use these formats for user presentation,
request logging, etc.
3.3. Transfer Codings 3.3. Transfer Codings
Transfer-coding values are used to indicate an encoding Transfer-coding values are used to indicate an encoding
transformation that has been, can be, or may need to be applied to an transformation that has been, can be, or may need to be applied to an
entity-body in order to ensure "safe transport" through the network. entity-body in order to ensure "safe transport" through the network.
This differs from a content coding in that the transfer-coding is a This differs from a content coding in that the transfer-coding is a
property of the message, not of the original entity. property of the message, not of the original entity.
transfer-coding = "chunked" / transfer-extension transfer-coding = "chunked" / transfer-extension
transfer-extension = token *( OWS ";" OWS parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of attribute/value pairs. Parameters are in the form of attribute/value pairs.
parameter = attribute BWS "=" BWS value transfer-parameter = attribute BWS "=" BWS value
attribute = token attribute = token
value = token / quoted-string value = token / quoted-string
All transfer-coding values are case-insensitive. HTTP/1.1 uses All transfer-coding values are case-insensitive. HTTP/1.1 uses
transfer-coding values in the TE header field (Section 8.5) and in transfer-coding values in the TE header field (Section 8.5) and in
the Transfer-Encoding header field (Section 8.7). the Transfer-Encoding header field (Section 8.7).
Whenever a transfer-coding is applied to a message-body, the set of Whenever a transfer-coding is applied to a message-body, the set of
transfer-codings MUST include "chunked", unless the message indicates transfer-codings MUST include "chunked", unless the message indicates
it is terminated by closing the connection. When the "chunked" it is terminated by closing the connection. When the "chunked"
transfer-coding is used, it MUST be the last transfer-coding applied transfer-coding is used, it MUST be the last transfer-coding applied
to the message-body. The "chunked" transfer-coding MUST NOT be to the message-body. The "chunked" transfer-coding MUST NOT be
applied more than once to a message-body. These rules allow the applied more than once to a message-body. These rules allow the
skipping to change at page 23, line 18 skipping to change at page 24, line 18
whitespace with a single SP prior to interpreting the field value or whitespace with a single SP prior to interpreting the field value or
forwarding the message downstream. forwarding the message downstream.
Comments can be included in some HTTP header fields by surrounding Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition. fields containing "comment" as part of their field value definition.
In all other fields, parentheses are considered part of the field In all other fields, parentheses are considered part of the field
value. value.
comment = "(" *( ctext / quoted-pair / comment ) ")" comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = *( OWS / %x21-27 / %x2A-7E / obs-text ) ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
; OWS / <VCHAR except "(", ")", and "\"> / obs-text
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response- general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields. header fields, and ending with the entity-header fields.
Multiple message-header fields with the same field-name MAY be Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)]. header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one It MUST be possible to combine the multiple header fields into one
skipping to change at page 24, line 18 skipping to change at page 25, line 20
message. Transfer-Encoding is a property of the message, not of the message. Transfer-Encoding is a property of the message, not of the
entity, and thus MAY be added or removed by any application along the entity, and thus MAY be added or removed by any application along the
request/response chain. (However, Section 3.3 places restrictions on request/response chain. (However, Section 3.3 places restrictions on
when certain transfer-codings may be used.) when certain transfer-codings may be used.)
The rules for when a message-body is allowed in a message differ for The rules for when a message-body is allowed in a message differ for
requests and responses. requests and responses.
The presence of a message-body in a request is signaled by the The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included the request's message-headers. When a request message contains both
in a request if the specification of the request method (Section 2 of a message-body of non-zero length and a method that does not define
[Part2]) explicitly disallows an entity-body in requests. When a any semantics for that request message-body, then an origin server
request message contains both a message-body of non-zero length and a SHOULD either ignore the message-body or respond with an appropriate
method that does not define any semantics for that request message- error message (e.g., 413). A proxy or gateway, when presented the
body, then an origin server SHOULD either ignore the message-body or same request, SHOULD either forward the request inbound with the
respond with an appropriate error message (e.g., 413). A proxy or message-body or ignore the message-body when determining a response.
gateway, when presented the same request, SHOULD either forward the
request inbound with the message-body or ignore the message-body when
determining a response.
For response messages, whether or not a message-body is included with For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response a message is dependent on both the request method and the response
status code (Section 6.1.1). All responses to the HEAD request status code (Section 6.1.1). All responses to the HEAD request
method MUST NOT include a message-body, even though the presence of method MUST NOT include a message-body, even though the presence of
entity-header fields might lead one to believe they do. All 1xx entity-header fields might lead one to believe they do. All 1xx
(informational), 204 (No Content), and 304 (Not Modified) responses (informational), 204 (No Content), and 304 (Not Modified) responses
MUST NOT include a message-body. All other responses do include a MUST NOT include a message-body. All other responses do include a
message-body, although it MAY be of zero length. message-body, although it MAY be of zero length.
skipping to change at page 25, line 13 skipping to change at page 26, line 10
in the message. in the message.
2. If a Transfer-Encoding header field (Section 8.7) is present and 2. If a Transfer-Encoding header field (Section 8.7) is present and
the "chunked" transfer-coding (Section 3.3) is used, the the "chunked" transfer-coding (Section 3.3) is used, the
transfer-length is defined by the use of this transfer-coding. transfer-length is defined by the use of this transfer-coding.
If a Transfer-Encoding header field is present and the "chunked" If a Transfer-Encoding header field is present and the "chunked"
transfer-coding is not present, the transfer-length is defined by transfer-coding is not present, the transfer-length is defined by
the sender closing the connection. the sender closing the connection.
3. If a Content-Length header field (Section 8.2) is present, its 3. If a Content-Length header field (Section 8.2) is present, its
decimal value in OCTETs represents both the entity-length and the value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be transfer-length. The Content-Length header field MUST NOT be
sent if these two lengths are different (i.e., if a Transfer- sent if these two lengths are different (i.e., if a Transfer-
Encoding header field is present). If a message is received with Encoding header field is present). If a message is received with
both a Transfer-Encoding header field and a Content-Length header both a Transfer-Encoding header field and a Content-Length header
field, the latter MUST be ignored. field, the latter MUST be ignored.
4. If the message uses the media type "multipart/byteranges", and 4. If the message uses the media type "multipart/byteranges", and
the transfer-length is not otherwise specified, then this self- the transfer-length is not otherwise specified, then this self-
delimiting media type defines the transfer-length. This media delimiting media type defines the transfer-length. This media
type MUST NOT be used unless the sender knows that the recipient type MUST NOT be used unless the sender knows that the recipient
skipping to change at page 31, line 23 skipping to change at page 32, line 18
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 require a client to make multiple other associated data often require 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 (RFC 2068) experience and measurements of actual HTTP/1.1 implementations show
implementations show good results [Nie1997]. Alternatives have also good results [Nie1997]. Alternatives have also been explored, for
been explored, for example, T/TCP [Tou1998]. example, T/TCP [Tou1998].
Persistent HTTP connections have a number of advantages: Persistent HTTP connections have a number of advantages:
o By opening and closing fewer TCP connections, CPU time is saved in o By opening and closing fewer TCP connections, CPU time is saved in
routers and hosts (clients, servers, proxies, gateways, tunnels, routers and hosts (clients, servers, proxies, gateways, tunnels,
or caches), and memory used for TCP protocol control blocks can be or caches), and memory used for TCP protocol control blocks can be
saved in hosts. saved in hosts.
o HTTP requests and responses can be pipelined on a connection. o HTTP requests and responses can be pipelined on a connection.
Pipelining allows a client to make multiple requests without Pipelining allows a client to make multiple requests without
skipping to change at page 33, line 39 skipping to change at page 34, line 29
It is especially important that proxies correctly implement the It is especially important that proxies correctly implement the
properties of the Connection header field as specified in properties of the Connection header field as specified in
Section 8.1. Section 8.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 [RFC2068] for information and with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
discussion of the problems with the Keep-Alive header implemented by information and discussion of the problems with the Keep-Alive header
many HTTP/1.0 clients). implemented by many HTTP/1.0 clients).
7.1.4. Practical Considerations 7.1.4. Practical Considerations
Servers will usually have some time-out value beyond which they will Servers will usually have some time-out value beyond which they will
no longer maintain an inactive connection. Proxy servers might make no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making this a higher value since it is likely that the client will be making
more connections through the same server. The use of persistent more connections through the same server. The use of persistent
connections places no requirements on the length (or existence) of connections places no requirements on the length (or existence) of
this time-out for either the client or the server. this time-out for either the client or the server.
skipping to change at page 39, line 20 skipping to change at page 40, line 10
A system receiving an HTTP/1.0 (or lower-version) message that A system receiving an HTTP/1.0 (or lower-version) message that
includes a Connection header MUST, for each connection-token in this includes a Connection header MUST, for each connection-token in this
field, remove and ignore any header field(s) from the message with field, remove and ignore any header field(s) from the message with
the same name as the connection-token. This protects against the same name as the connection-token. This protects against
mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
See Appendix B.2. See Appendix B.2.
8.2. Content-Length 8.2. Content-Length
The entity-header field "Content-Length" indicates the size of the The entity-header field "Content-Length" indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient or, entity-body, in number of OCTETs, sent to the recipient or, in the
in the case of the HEAD method, the size of the entity-body that case of the HEAD method, the size of the entity-body that would have
would have been sent had the request been a GET. been sent had the request been a GET.
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
An example is An example is
Content-Length: 3495 Content-Length: 3495
Applications SHOULD use this field to indicate the transfer-length of Applications SHOULD use this field to indicate the transfer-length of
the message-body, unless this is prohibited by the rules in the message-body, unless this is prohibited by the rules in
skipping to change at page 39, line 51 skipping to change at page 40, line 41
used within the "message/external-body" content-type. In HTTP, it used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined prior SHOULD be sent whenever the message's length can be determined prior
to being transferred, unless this is prohibited by the rules in to being transferred, unless this is prohibited by the rules in
Section 4.4. Section 4.4.
8.3. Date 8.3. Date
The general-header field "Date" represents the date and time at which The general-header field "Date" represents the date and time at which
the message was originated, having the same semantics as orig-date in the message was originated, having the same semantics as orig-date in
Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as
described in Section 3.2.1; it MUST be sent in rfc1123-date format. described in Section 3.2; it MUST be sent in rfc1123-date format.
Date = "Date" ":" OWS Date-v Date = "Date" ":" OWS Date-v
Date-v = HTTP-date Date-v = HTTP-date
An example is An example is
Date: Tue, 15 Nov 1994 08:12:31 GMT Date: Tue, 15 Nov 1994 08:12:31 GMT
Origin servers MUST include a Date header field in all responses, Origin servers MUST include a Date header field in all responses,
except in these cases: except in these cases:
skipping to change at page 53, line 45 skipping to change at page 54, line 37
[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-06 (work in Semantics", draft-ietf-httpbis-p2-semantics-07 (work in
progress), March 2009. progress), July 2009.
[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-06 and Content Negotiation", draft-ietf-httpbis-p3-payload-07
(work in progress), March 2009. (work in progress), July 2009.
[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-06 (work Partial Responses", draft-ietf-httpbis-p5-range-07 (work
in progress), March 2009. in progress), July 2009.
[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", Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
draft-ietf-httpbis-p6-cache-06 (work in progress), 6: Caching", draft-ietf-httpbis-p6-cache-07 (work in
March 2009. progress), July 2009.
[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, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, Resource Identifier (URI): Generic Syntax", RFC 3986,
STD 66, January 2005. STD 66, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 59, line 35 skipping to change at page 60, line 23
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 8.1. declaring non-persistence. See Section 8.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 [RFC2068]. Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of
[RFC2068].
B.3. Changes from RFC 2068 B.3. Changes from RFC 2068
This specification has been carefully audited to correct and This specification has been carefully audited to correct and
disambiguate key word usage; RFC 2068 had many problems in respect to disambiguate key word usage; RFC 2068 had many problems in respect to
the conventions laid out in [RFC2119]. the conventions laid out in [RFC2119].
Transfer-coding and message lengths all interact in ways that Transfer-coding and message lengths all interact in ways that
required fixing exactly when chunked encoding is used (to allow for required fixing exactly when chunked encoding is used (to allow for
transfer encoding that may not be self delimiting); it was important transfer encoding that may not be self delimiting); it was important
skipping to change at page 64, line 20 skipping to change at page 65, line 9
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
Date = "Date:" OWS Date-v Date = "Date:" OWS Date-v
Date-v = HTTP-date Date-v = HTTP-date
GMT = %x47.4D.54 GMT = %x47.4D.54 ; GMT
HTTP-Prot-Name = %x48.54.54.50 HTTP-Prot-Name = %x48.54.54.50 ; HTTP
HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
HTTP-date = rfc1123-date / obsolete-date HTTP-date = rfc1123-date / obs-date
HTTP-message = Request / Response HTTP-message = Request / Response
Host = "Host:" OWS Host-v Host = "Host:" OWS Host-v
Host-v = uri-host [ ":" port ] Host-v = uri-host [ ":" port ]
Method = token Method = token
OWS = *( [ obs-fold ] WSP ) OWS = *( [ obs-fold ] WSP )
Pragma = <Pragma, defined in [Part6], Section 3.4> Pragma = <Pragma, defined in [Part6], Section 3.4>
skipping to change at page 65, line 4 skipping to change at page 65, line 42
Status-Code = 3DIGIT Status-Code = 3DIGIT
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
TE = "TE:" OWS TE-v TE = "TE:" OWS TE-v
TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Trailer = "Trailer:" OWS Trailer-v Trailer = "Trailer:" OWS Trailer-v
Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] ) transfer-coding ] )
URI = <URI, defined in [RFC3986], Section 3> URI = <URI, defined in [RFC3986], Section 3>
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
Upgrade = "Upgrade:" OWS Upgrade-v Upgrade = "Upgrade:" OWS Upgrade-v
Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
Via = "Via:" OWS Via-v Via = "Via:" OWS Via-v
Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment
] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
] ) ] )
Warning = <Warning, defined in [Part6], Section 3.6> Warning = <Warning, defined in [Part6], Section 3.6>
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
asctime-date = wkday SP date3 SP time SP 4DIGIT asctime-date = day-name SP date3 SP time-of-day SP year
attribute = token attribute = token
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, defined in [RFC3986], Section 3.2>
chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET chunk-data = 1*OCTET
chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token / quoted-string chunk-ext-val = token / quoted-string
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
comment = "(" *( ctext / quoted-pair / comment ) ")" comment = "(" *( ctext / quoted-pair / comment ) ")"
connection-token = token connection-token = token
ctext = *( OWS / %x21-27 / %x2A-7E / obs-text ) ctext = OWS / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
date1 = 2DIGIT SP month SP 4DIGIT date1 = day SP month SP year
date2 = 2DIGIT "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT
day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue
/ %x57.65.64 ; Wed
/ %x54.68.75 ; Thu
/ %x46.72.69 ; Fri
/ %x53.61.74 ; Sat
/ %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday
entity-body = <entity-body, defined in [Part3], Section 3.2> entity-body = <entity-body, defined in [Part3], Section 3.2>
entity-header = <entity-header, defined in [Part3], Section 3.1> entity-header = <entity-header, defined in [Part3], Section 3.1>
field-content = *( WSP / VCHAR / obs-text ) field-content = *( WSP / VCHAR / obs-text )
field-name = token field-name = token
field-value = *( field-content / OWS ) field-value = *( field-content / OWS )
fragment = <fragment, defined in [RFC3986], Section 3.5> fragment = <fragment, defined in [RFC3986], Section 3.5>
general-header = Cache-Control / Connection / Date / Pragma / Trailer general-header = Cache-Control / Connection / Date / Pragma / Trailer
/ Transfer-Encoding / Upgrade / Via / Warning / Transfer-Encoding / Upgrade / Via / Warning
generic-message = start-line *( message-header CRLF ) CRLF [ generic-message = start-line *( message-header CRLF ) CRLF [
message-body ] message-body ]
hour = 2DIGIT
http-URI = "http://" authority path-abempty [ "?" query ] http-URI = "http://" authority path-abempty [ "?" query ]
l-Fri = %x46.72.69.64.61.79
l-Mon = %x4D.6F.6E.64.61.79
l-Sat = %x53.61.74.75.72.64.61.79
l-Sun = %x53.75.6E.64.61.79
l-Thu = %x54.68.75.72.73.64.61.79
l-Tue = %x54.75.65.73.64.61.79
l-Wed = %x57.65.64.6E.65.73.64.61.79
last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF
message-body = entity-body / message-body = entity-body /
<entity-body encoded as per Transfer-Encoding> <entity-body encoded as per Transfer-Encoding>
message-header = field-name ":" OWS [ field-value ] OWS message-header = field-name ":" OWS [ field-value ] OWS
month = s-Jan / s-Feb / s-Mar / s-Apr / s-May / s-Jun / s-Jul / s-Aug minute = 2DIGIT
/ s-Sep / s-Oct / s-Nov / s-Dec month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr
/ %x4D.61.79 ; May
/ %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug
/ %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date
obs-fold = CRLF obs-fold = CRLF
obs-text = %x80-FF obs-text = %x80-FF
obsolete-date = rfc850-date / asctime-date
parameter = attribute BWS "=" BWS value
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
port = <port, defined in [RFC3986], Section 3.2.3> port = <port, defined in [RFC3986], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
pseudonym = token pseudonym = token
qdtext = *( OWS / "!" / %x23-5B / %x5D-7E / obs-text ) qdtext = OWS / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
query = <query, defined in [RFC3986], Section 3.4> query = <query, defined in [RFC3986], Section 3.4>
quoted-pair = "\" quoted-text quoted-pair = "\" quoted-text
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
quoted-text = %x01-09 / %x0B-0C / %x0E-FF quoted-text = %x01-09 / %x0B-0C / %x0E-FF
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = ( uri-host [ ":" port ] ) / pseudonym
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, defined in [RFC3986], Section 4.2> relative-part = <relative-part, defined in [RFC3986], Section 4.2>
request-header = <request-header, defined in [Part2], Section 3> request-header = <request-header, defined in [Part2], Section 3>
request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
/ authority / authority
response-header = <response-header, defined in [Part2], Section 5> response-header = <response-header, defined in [Part2], Section 5>
rfc1123-date = wkday "," SP date1 SP time SP GMT rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
rfc850-date = weekday "," SP date2 SP time SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
s-Apr = %x41.70.72 second = 2DIGIT
s-Aug = %x41.75.67
s-Dec = %x44.65.63
s-Feb = %x46.65.62
s-Fri = %x46.72.69
s-Jan = %x4A.61.6E
s-Jul = %x4A.75.6C
s-Jun = %x4A.75.6E
s-Mar = %x4D.61.72
s-May = %x4D.61.79
s-Mon = %x4D.6F.6E
s-Nov = %x4E.6F.76
s-Oct = %x4F.63.74
s-Sat = %x53.61.74
s-Sep = %x53.65.70
s-Sun = %x53.75.6E
s-Thu = %x54.68.75
s-Tue = %x54.75.65
s-Wed = %x57.65.64
start-line = Request-Line / Status-Line start-line = Request-Line / Status-Line
t-codings = "trailers" / ( transfer-extension [ te-params ] ) t-codings = "trailers" / ( transfer-extension [ te-params ] )
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
te-params = OWS ";" OWS "q=" qvalue *te-ext te-params = OWS ";" OWS "q=" qvalue *te-ext
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time-of-day = hour ":" minute ":" second
token = 1*tchar token = 1*tchar
trailer-part = *( entity-header CRLF ) trailer-part = *( entity-header CRLF )
transfer-coding = "chunked" / transfer-extension transfer-coding = "chunked" / transfer-extension
transfer-extension = token *( OWS ";" OWS parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
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 = token / quoted-string value = token / quoted-string
weekday = l-Mon / l-Tue / l-Wed / l-Thu / l-Fri / l-Sat / l-Sun year = 4DIGIT
wkday = s-Mon / s-Tue / s-Wed / s-Thu / s-Fri / s-Sat / s-Sun
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
; TE defined but not used ; TE defined but not used
; URI defined but not used ; URI defined but not used
; URI-reference defined but not used ; URI-reference defined but not used
; fragment defined but not used ; fragment defined but not used
skipping to change at page 73, line 33 skipping to change at page 74, line 11
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 grammar independent of accept-params (defined in
Part 3). Part 3).
E.8. Since draft-ietf-httpbis-p1-messaging-06
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
numeric protocol elements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
(took out language that implied that there may be methods for
which a request body MUST NOT be included)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial
improvements around HTTP-date"
Index Index
A A
application/http Media Type 48 application/http Media Type 49
C C
cache 61 cache 61
cacheable 61 cacheable 62
client 61 client 62
connection 61 connection 62
Connection header 38 Connection header 39
content negotiation 61 content negotiation 62
Content-Length header 39 Content-Length header 40
D D
Date header 39 Date header 40
downstream 63 downstream 64
E E
entity 61 entity 62
G G
gateway 61 gateway 62
Grammar Grammar
absolute-URI 10 absolute-URI 10
ALPHA 7 ALPHA 7
asctime-date 16 asctime-date 18
attribute 17 attribute 18
authority 10 authority 10
BWS 9 BWS 9
chunk 19 chunk 20
chunk-data 19 chunk-data 20
chunk-ext 19 chunk-ext 20
chunk-ext-name 19 chunk-ext-name 20
chunk-ext-val 19 chunk-ext-val 20
chunk-size 19 chunk-size 20
Chunked-Body 19 Chunked-Body 20
comment 23 comment 24
Connection 38 Connection 39
connection-token 38 connection-token 39
Connection-v 38 Connection-v 39
Content-Length 39 Content-Length 40
Content-Length-v 39 Content-Length-v 40
CR 7 CR 7
CRLF 7 CRLF 7
ctext 23 ctext 24
CTL 7 CTL 7
Date 40 Date 40
Date-v 40 Date-v 40
date1 16 date1 17
date2 16 date2 18
date3 16 date3 18
day 17
day-name 17
day-name-l 17
DIGIT 7 DIGIT 7
DQUOTE 7 DQUOTE 7
extension-code 31 extension-code 31
extension-method 27 extension-method 28
field-content 22 field-content 23
field-name 22 field-name 23
field-value 22 field-value 23
general-header 26 general-header 27
generic-message 21 generic-message 22
GMT 17
HEXDIG 7 HEXDIG 7
Host 41 Host 42
Host-v 41 Host-v 42
hour 17
HTTP-date 16 HTTP-date 16
HTTP-message 21 HTTP-message 22
HTTP-Prot-Name 14 HTTP-Prot-Name 14
http-URI 11 http-URI 11
HTTP-Version 14 HTTP-Version 14
last-chunk 19 last-chunk 20
LF 7 LF 7
message-body 23 message-body 25
message-header 22 message-header 23
Method 27 Method 28
month 16 minute 17
month 17
obs-date 17
obs-text 9 obs-text 9
obsolete-date 16
OCTET 7 OCTET 7
OWS 9 OWS 9
parameter 17
path-absolute 10 path-absolute 10
port 10 port 10
product 20 product 21
product-version 20 product-version 21
protocol-name 45 protocol-name 46
protocol-version 45 protocol-version 46
pseudonym 45 pseudonym 46
qdtext 9 qdtext 9
query 10 query 10
quoted-pair 9 quoted-pair 9
quoted-string 9 quoted-string 9
quoted-text 9 quoted-text 9
qvalue 21 qvalue 22
Reason-Phrase 31 Reason-Phrase 31
received-by 45 received-by 46
received-protocol 45 received-protocol 46
Request 26 Request 27
Request-Line 27 Request-Line 28
request-target 27 request-target 28
Response 30 Response 31
rfc850-date 16 rfc850-date 18
rfc1123-date 16 rfc1123-date 17
RWS 9 RWS 9
second 17
SP 7 SP 7
start-line 21 start-line 22
Status-Code 31 Status-Code 31
Status-Line 30 Status-Line 31
t-codings 42 t-codings 42
tchar 9 tchar 9
TE 42 TE 42
te-ext 42 te-ext 42
te-params 42 te-params 42
TE-v 42 TE-v 42
time 16 time-of-day 17
token 9 token 9
Trailer 43 Trailer 44
trailer-part 19 trailer-part 20
Trailer-v 43 Trailer-v 44
transfer-coding 17 transfer-coding 18
Transfer-Encoding 44 Transfer-Encoding 44
Transfer-Encoding-v 44 Transfer-Encoding-v 44
transfer-extension 17 transfer-extension 18
Upgrade 44 transfer-parameter 18
Upgrade-v 44 Upgrade 45
Upgrade-v 45
uri-host 10 uri-host 10
URI-reference 10 URI-reference 10
value 17 value 18
VCHAR 7 VCHAR 7
Via 45 Via 46
Via-v 45 Via-v 46
weekday 16
wkday 16
WSP 7 WSP 7
year 17
H H
Headers Headers
Connection 38 Connection 39
Content-Length 39 Content-Length 40
Date 39 Date 40
Host 41 Host 42
TE 42 TE 42
Trailer 43 Trailer 44
Transfer-Encoding 43 Transfer-Encoding 44
Upgrade 44 Upgrade 45
Via 45 Via 46
Host header 41 Host header 42
http URI scheme 11 http URI scheme 11
https URI scheme 11 https URI scheme 11
I I
inbound 62 inbound 62
M M
Media Type Media Type
application/http 48 application/http 49
message/http 47 message/http 48
message 62 message 63
message/http Media Type 47 message/http Media Type 48
O O
origin server 62 origin server 63
outbound 62 outbound 62
P P
proxy 62 proxy 63
R R
representation 63 representation 63
request 62 request 63
resource 62 resource 63
response 62 response 63
S S
server 63 server 64
T T
TE header 42 TE header 42
Trailer header 43 Trailer header 44
Transfer-Encoding header 43 Transfer-Encoding header 44
tunnel 63 tunnel 64
U U
Upgrade header 44 Upgrade header 45
upstream 63 upstream 64
URI scheme URI scheme
http 11 http 11
https 11 https 11
user agent 63 user agent 64
V V
variant 63 variant 64
Via header 45 Via header 46
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
 End of changes. 109 change blocks. 
308 lines changed or deleted 350 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/