draft-ietf-httpbis-p1-messaging-03.txt | draft-ietf-httpbis-p1-messaging-04.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: December 19, 2008 J. Mogul | Expires: March 2, 2009 J. Mogul | |||
HP | HP | |||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe Systems | Adobe Systems | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
Y. Lafon, Ed. | Y. Lafon, Ed. | |||
W3C | W3C | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
June 17, 2008 | August 29, 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-03 | draft-ietf-httpbis-p1-messaging-04 | |||
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 December 19, 2008. | This Internet-Draft will expire on March 2, 2009. | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document is Part 1 of the | information initiative since 1990. This document is Part 1 of the | |||
seven-part specification that defines the protocol referred to as | seven-part specification that defines the protocol referred to as | |||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides | |||
an overview of HTTP and its associated terminology, defines the | an overview of HTTP and its associated terminology, defines the | |||
skipping to change at page 2, line 26 | 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/>. | |||
The changes in this draft are summarized in Appendix E.4. | The changes in this draft are summarized in Appendix D.4. | |||
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 | |||
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
2.3. ABNF Rules defined in other Parts of the Specification . . 16 | 2.3. ABNF Rules defined in other Parts of the Specification . . 16 | |||
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16 | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16 | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 | |||
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 | |||
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18 | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18 | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 19 | |||
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19 | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19 | |||
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19 | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 20 | 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 21 | |||
3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 21 | 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 22 | |||
3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 23 | 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 24 | |||
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 | |||
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 24 | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 25 | |||
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 26 | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 27 | |||
4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28 | 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28 | |||
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28 | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 29 | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 30 | |||
5.2. The Resource Identified by a Request . . . . . . . . . . . 30 | 5.2. The Resource Identified by a Request . . . . . . . . . . . 31 | |||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 32 | |||
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32 | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 33 | |||
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32 | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 33 | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 34 | |||
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34 | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 35 | |||
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35 | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35 | |||
7.2. Message Transmission Requirements . . . . . . . . . . . . 36 | 7.2. Message Transmission Requirements . . . . . . . . . . . . 36 | |||
7.2.1. Persistent Connections and Flow Control . . . . . . . 36 | 7.2.1. Persistent Connections and Flow Control . . . . . . . 37 | |||
7.2.2. Monitoring Connections for Error Status Messages . . . 36 | 7.2.2. Monitoring Connections for Error Status Messages . . . 37 | |||
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36 | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 37 | |||
7.2.4. Client Behavior if Server Prematurely Closes | 7.2.4. Client Behavior if Server Prematurely Closes | |||
Connection . . . . . . . . . . . . . . . . . . . . . . 38 | Connection . . . . . . . . . . . . . . . . . . . . . . 39 | |||
8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 39 | 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 40 | |||
8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39 | 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 | 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 41 | |||
8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42 | 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 43 | |||
8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 | 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 45 | |||
8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 | 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 | 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | |||
9.1. Message Header Registration . . . . . . . . . . . . . . . 47 | 9.1. Message Header Registration . . . . . . . . . . . . . . . 48 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 | 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 49 | |||
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48 | 9.3. Internet Media Type Registrations . . . . . . . . . . . . 49 | |||
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48 | 9.3.1. Internet Media Type message/http . . . . . . . . . . . 49 | |||
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 49 | 9.3.2. Internet Media Type application/http . . . . . . . . . 50 | |||
10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 | |||
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 50 | 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 52 | |||
10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50 | 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 52 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 | 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 52 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 | 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 52 | 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 53 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 53 | 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 54 | |||
Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 55 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
A.1. Internet Media Type message/http . . . . . . . . . . . . . 55 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
A.2. Internet Media Type application/http . . . . . . . . . . . 56 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 55 | |||
Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 56 | |||
Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58 | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 59 | |||
Appendix D. Compatibility with Previous Versions . . . . . . . . 58 | Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 59 | |||
D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59 | Appendix C. Compatibility with Previous Versions . . . . . . . . 60 | |||
D.1.1. Changes to Simplify Multi-homed Web Servers and | C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 60 | |||
Conserve IP Addresses . . . . . . . . . . . . . . . . 59 | C.1.1. Changes to Simplify Multi-homed Web Servers and | |||
D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 60 | Conserve IP Addresses . . . . . . . . . . . . . . . . 60 | |||
D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 | C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 61 | |||
D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61 | C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 62 | |||
Appendix E. Change Log (to be removed by RFC Editor before | C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 62 | |||
publication) . . . . . . . . . . . . . . . . . . . . 61 | Appendix D. Change Log (to be removed by RFC Editor before | |||
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 | publication) . . . . . . . . . . . . . . . . . . . . 63 | |||
E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 63 | |||
E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 63 | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 63 | |||
E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 64 | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 64 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 65 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 66 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 71 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 73 | ||||
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 14, line 27 | skipping to change at page 14, line 27 | |||
LF = %x0A | LF = %x0A | |||
; US-ASCII LF, linefeed (10) | ; US-ASCII LF, linefeed (10) | |||
SP = %x20 | SP = %x20 | |||
; US-ASCII SP, space (32) | ; US-ASCII SP, space (32) | |||
HTAB = %x09 | HTAB = %x09 | |||
; US-ASCII HT, horizontal-tab (9) | ; US-ASCII HT, horizontal-tab (9) | |||
DQUOTE = %x22 | DQUOTE = %x22 | |||
; US-ASCII double-quote mark (34) | ; US-ASCII double-quote mark (34) | |||
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | |||
protocol elements except the entity-body (see Appendix B for tolerant | protocol elements except the entity-body (see Appendix A for tolerant | |||
applications). The end-of-line marker within an entity-body is | applications). The end-of-line marker within an entity-body is | |||
defined by its associated media type, as described in Section 3.3 of | defined by its associated media type, as described in Section 3.3 of | |||
[Part3]. | [Part3]. | |||
CRLF = CR LF | CRLF = CR LF | |||
HTTP/1.1 header field values can be folded onto multiple lines if the | HTTP/1.1 header field values can be folded onto multiple lines if the | |||
continuation line begins with a space or horizontal tab. All linear | continuation line begins with a space or horizontal tab. All linear | |||
white space, including folding, has the same semantics as SP. A | white space, including folding, has the same semantics as SP. A | |||
recipient MAY replace any linear white space with a single SP before | recipient MAY replace any linear white space with a single SP before | |||
skipping to change at page 15, line 8 | skipping to change at page 15, line 8 | |||
TEXT = %x20-7E | %x80-FF | LWS | TEXT = %x20-7E | %x80-FF | LWS | |||
; any OCTET except CTLs, but including LWS | ; any OCTET except CTLs, but including LWS | |||
A CRLF is allowed in the definition of TEXT only as part of a header | A CRLF is allowed in the definition of TEXT only as part of a header | |||
field continuation. It is expected that the folding LWS will be | field continuation. It is expected that the folding LWS will be | |||
replaced with a single SP before interpretation of the TEXT value. | replaced with a single SP before interpretation of the TEXT value. | |||
Hexadecimal numeric characters are used in several protocol elements. | Hexadecimal numeric characters are used in several protocol elements. | |||
HEX = "A" | "B" | "C" | "D" | "E" | "F" | HEXDIG = "A" | "B" | "C" | "D" | "E" | "F" | |||
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | |||
Many HTTP/1.1 header field values consist of words separated by LWS | Many HTTP/1.1 header field values consist of words separated by LWS | |||
or special characters. These special characters MUST be in a quoted | or special characters. These special characters MUST be in a quoted | |||
string to be used within a parameter value (as defined in | string to be used within a parameter value (as defined in | |||
Section 3.4). | Section 3.4). | |||
separators = "(" | ")" | "<" | ">" | "@" | separators = "(" | ")" | "<" | ">" | "@" | |||
| "," | ";" | ":" | "\" | DQUOTE | | "," | ";" | ":" | "\" | DQUOTE | |||
| "/" | "[" | "]" | "?" | "=" | | "/" | "[" | "]" | "?" | "=" | |||
skipping to change at page 18, line 48 | skipping to change at page 18, line 48 | |||
for TCP connections on that port of that host, and the Request-URI | for TCP connections on that port of that host, and the Request-URI | |||
for the resource is path-absolute (Section 5.1.2). The use of IP | for the resource is path-absolute (Section 5.1.2). The use of IP | |||
addresses in URLs SHOULD be avoided whenever possible (see | addresses in URLs SHOULD be avoided whenever possible (see | |||
[RFC1900]). If the path-absolute is not present in the URL, it MUST | [RFC1900]). If the path-absolute is not present in the URL, it MUST | |||
be given as "/" when used as a Request-URI for a resource | be given as "/" when used as a Request-URI for a resource | |||
(Section 5.1.2). If a proxy receives a host name which is not a | (Section 5.1.2). If a proxy receives a host name which is not a | |||
fully qualified domain name, it MAY add its domain to the host name | fully qualified domain name, it MAY add its domain to the host name | |||
it received. If a proxy receives a fully qualified domain name, the | it received. If a proxy receives a fully qualified domain name, the | |||
proxy MUST NOT change the host name. | proxy MUST NOT change the host name. | |||
Note: the "https" scheme is defined in [RFC2818]. | ||||
3.2.3. URI Comparison | 3.2.3. URI Comparison | |||
When comparing two URIs to decide if they match or not, a client | When comparing two URIs to decide if they match or not, a client | |||
SHOULD use a case-sensitive octet-by-octet comparison of the entire | SHOULD use a case-sensitive octet-by-octet comparison of the entire | |||
URIs, with these exceptions: | URIs, with these exceptions: | |||
o A port that is empty or not given is equivalent to the default | o A port that is empty or not given is equivalent to the default | |||
port for that URI-reference; | port for that URI-reference; | |||
o Comparisons of host names MUST be case-insensitive; | o Comparisons of host names MUST be case-insensitive; | |||
o Comparisons of scheme names MUST be case-insensitive; | o Comparisons of scheme names MUST be case-insensitive; | |||
o An empty path-absolute is equivalent to an path-absolute of "/". | o An empty path-absolute is equivalent to an path-absolute of "/". | |||
Characters other than those in the "reserved" set (see [RFC2396]) are | Characters other than those in the "reserved" set (see [RFC2396], | |||
equivalent to their ""%" HEX HEX" encoding. | Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding. | |||
For example, the following three URIs are equivalent: | For example, the following three URIs are equivalent: | |||
http://example.com:80/~smith/home.html | http://example.com:80/~smith/home.html | |||
http://EXAMPLE.com/%7Esmith/home.html | http://EXAMPLE.com/%7Esmith/home.html | |||
http://EXAMPLE.com:/%7esmith/home.html | http://EXAMPLE.com:/%7esmith/home.html | |||
3.3. Date/Time Formats | 3.3. Date/Time Formats | |||
3.3.1. Full Date | 3.3.1. Full Date | |||
skipping to change at page 19, line 42 | skipping to change at page 19, line 47 | |||
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] (an update to | a fixed-length subset of that defined by [RFC1123] (an update to | |||
[RFC822]). The other formats are described here only for | [RFC822]). The other formats are described here only for | |||
compatibility with obsolete implementations. HTTP/1.1 clients and | compatibility with obsolete implementations. HTTP/1.1 clients and | |||
servers that parse the date value MUST accept all three formats (for | servers that parse the date value MUST accept all three formats (for | |||
compatibility with HTTP/1.0), though they MUST only generate the RFC | compatibility with HTTP/1.0), though they MUST only generate the RFC | |||
1123 format for representing HTTP-date values in header fields. See | 1123 format for representing HTTP-date values in header fields. See | |||
Appendix B for further information. | Appendix A for further information. | |||
Note: Recipients of date values are encouraged to be robust in | Note: Recipients of date values are encouraged to be robust in | |||
accepting date values that may have been sent by non-HTTP | accepting date values that may have been sent by non-HTTP | |||
applications, as is sometimes the case when retrieving or posting | applications, as is sometimes the case when retrieving or posting | |||
messages via proxies/gateways to SMTP or NNTP. | 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 LWS beyond that specifically included as SP in the | additional LWS beyond that specifically included as SP in the | |||
grammar. | grammar. | |||
HTTP-date = rfc1123-date | obsolete-date | HTTP-date = rfc1123-date | obsolete-date | |||
obsolete-date = rfc850-date | asctime-date | obsolete-date = rfc850-date | asctime-date | |||
rfc1123-date = wkday "," SP date1 SP time SP "GMT" | rfc1123-date = wkday "," SP date1 SP time SP GMT | |||
rfc850-date = weekday "," SP date2 SP time SP "GMT" | rfc850-date = weekday "," SP date2 SP time SP GMT | |||
asctime-date = wkday SP date3 SP time SP 4DIGIT | asctime-date = wkday SP date3 SP time SP 4DIGIT | |||
date1 = 2DIGIT SP month SP 4DIGIT | date1 = 2DIGIT SP month SP 4DIGIT | |||
; day month year (e.g., 02 Jun 1982) | ; day month year (e.g., 02 Jun 1982) | |||
date2 = 2DIGIT "-" month "-" 2DIGIT | date2 = 2DIGIT "-" month "-" 2DIGIT | |||
; day-month-year (e.g., 02-Jun-82) | ; day-month-year (e.g., 02-Jun-82) | |||
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) | |||
; month day (e.g., Jun 2) | ; month day (e.g., Jun 2) | |||
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | |||
; 00:00:00 - 23:59:59 | ; 00:00:00 - 23:59:59 | |||
wkday = "Mon" | "Tue" | "Wed" | wkday = s-Mon | s-Tue | s-Wed | |||
| "Thu" | "Fri" | "Sat" | "Sun" | | s-Thu | s-Fri | s-Sat | s-Sun | |||
weekday = "Monday" | "Tuesday" | "Wednesday" | weekday = l-Mon | l-Tue | l-Wed | |||
| "Thursday" | "Friday" | "Saturday" | "Sunday" | | l-Thu | l-Fri | l-Sat | l-Sun | |||
month = "Jan" | "Feb" | "Mar" | "Apr" | month = s-Jan | s-Feb | s-Mar | s-Apr | |||
| "May" | "Jun" | "Jul" | "Aug" | | s-May | s-Jun | s-Jul | s-Aug | |||
| "Sep" | "Oct" | "Nov" | "Dec" | | s-Sep | s-Oct | s-Nov | s-Dec | |||
GMT = %x47.4D.54 ; "GMT", case-sensitive | ||||
s-Mon = %x4D.6F.6E ; "Mon", case-sensitive | ||||
s-Tue = %x54.75.65 ; "Tue", case-sensitive | ||||
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 | ||||
l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive | ||||
l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive | ||||
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 | ||||
s-Feb = %x46.65.62 ; "Feb", case-sensitive | ||||
s-Mar = %x4D.61.72 ; "Mar", case-sensitive | ||||
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 | Note: HTTP requirements for the date/time stamp format apply only to | |||
their usage within the protocol stream. Clients and servers are not | their usage within the protocol stream. Clients and servers are not | |||
required to use these formats for user presentation, request logging, | required to use these formats for user presentation, request logging, | |||
etc. | etc. | |||
3.4. Transfer Codings | 3.4. Transfer Codings | |||
Transfer-coding values are used to indicate an encoding | Transfer-coding values are used to indicate an encoding | |||
transformation that has been, can be, or may need to be applied to an | transformation that has been, can be, or may need to be applied to an | |||
skipping to change at page 21, line 4 | skipping to change at page 21, line 38 | |||
property of the message, not of the original entity. | property of the message, not of the original entity. | |||
transfer-coding = "chunked" | transfer-extension | transfer-coding = "chunked" | transfer-extension | |||
transfer-extension = token *( ";" parameter ) | transfer-extension = token *( ";" parameter ) | |||
Parameters are in the form of attribute/value pairs. | Parameters are in the form of attribute/value pairs. | |||
parameter = attribute "=" value | parameter = attribute "=" 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 is | transfer-codings MUST include "chunked", unless the message indicates | |||
terminated by closing the connection. When the "chunked" transfer- | it is terminated by closing the connection. When the "chunked" | |||
coding is used, it MUST be the last transfer-coding applied to the | transfer-coding is used, it MUST be the last transfer-coding applied | |||
message-body. The "chunked" transfer-coding MUST NOT be applied more | to the message-body. The "chunked" transfer-coding MUST NOT be | |||
than once to a message-body. These rules allow the recipient to | applied more than once to a message-body. These rules allow the | |||
determine the transfer-length of the message (Section 4.4). | recipient to determine the transfer-length of the message | |||
(Section 4.4). | ||||
Transfer-codings are analogous to the Content-Transfer-Encoding | Transfer-codings are analogous to the Content-Transfer-Encoding | |||
values of MIME [RFC2045], which were designed to enable safe | values of MIME [RFC2045], which were designed to enable safe | |||
transport of binary data over a 7-bit transport service. However, | transport of binary data over a 7-bit transport service. However, | |||
safe transport has a different focus for an 8bit-clean transfer | safe transport has a different focus for an 8bit-clean transfer | |||
protocol. In HTTP, the only unsafe characteristic of message-bodies | protocol. In HTTP, the only unsafe characteristic of message-bodies | |||
is the difficulty in determining the exact body length (Section 4.4), | is the difficulty in determining the exact body length (Section 4.4), | |||
or the desire to encrypt data over a shared transport. | or the desire to encrypt data over a shared transport. | |||
The Internet Assigned Numbers Authority (IANA) acts as a registry for | The Internet Assigned Numbers Authority (IANA) acts as a registry for | |||
skipping to change at page 22, line 12 | skipping to change at page 22, line 42 | |||
the information necessary for the recipient to verify that it has | the information necessary for the recipient to verify that it has | |||
received the full message. | received the full message. | |||
Chunked-Body = *chunk | Chunked-Body = *chunk | |||
last-chunk | last-chunk | |||
trailer-part | trailer-part | |||
CRLF | CRLF | |||
chunk = chunk-size [ chunk-extension ] CRLF | chunk = chunk-size [ chunk-extension ] CRLF | |||
chunk-data CRLF | chunk-data CRLF | |||
chunk-size = 1*HEX | chunk-size = 1*HEXDIG | |||
last-chunk = 1*("0") [ chunk-extension ] CRLF | last-chunk = 1*("0") [ chunk-extension ] CRLF | |||
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | |||
chunk-ext-name = token | chunk-ext-name = token | |||
chunk-ext-val = token | quoted-string | chunk-ext-val = token | quoted-string | |||
chunk-data = 1*OCTET ; a sequence of chunk-size octets | chunk-data = 1*OCTET ; a sequence of chunk-size octets | |||
trailer-part = *(entity-header CRLF) | trailer-part = *(entity-header CRLF) | |||
The chunk-size field is a string of hex digits indicating the size of | The chunk-size field is a string of hex digits indicating the size of | |||
the chunk-data in octets. The chunked encoding is ended by any chunk | the chunk-data in octets. The chunked encoding is ended by any chunk | |||
skipping to change at page 25, line 38 | skipping to change at page 26, line 21 | |||
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 | |||
"field-name: field-value" pair, without changing the semantics of the | "field-name: field-value" pair, without changing the semantics of the | |||
message, by appending each subsequent field-value to the first, each | message, by appending each subsequent field-value to the first, each | |||
separated by a comma. The order in which header fields with the same | separated by a comma. The order in which header fields with the same | |||
field-name are received is therefore significant to the | field-name are received is therefore significant to the | |||
interpretation of the combined field value, and thus a proxy MUST NOT | interpretation of the combined field value, and thus a proxy MUST NOT | |||
change the order of these field values when a message is forwarded. | change the order of these field values when a message is forwarded. | |||
Note: the "Set-Cookie" header as implemented in practice (as | ||||
opposed to how it is specified in [RFC2109]) can occur multiple | ||||
times, but does not use the list syntax, and thus cannot be | ||||
combined into a single line. (See Appendix A.2.3 of [Kri2001] for | ||||
details.) Also note that the Set-Cookie2 header specified in | ||||
[RFC2965] does not share this problem. | ||||
4.3. Message Body | 4.3. Message Body | |||
The message-body (if any) of an HTTP message is used to carry the | The message-body (if any) of an HTTP message is used to carry the | |||
entity-body associated with the request or response. The message- | entity-body associated with the request or response. The message- | |||
body differs from the entity-body only when a transfer-coding has | body differs from the entity-body only when a transfer-coding has | |||
been applied, as indicated by the Transfer-Encoding header field | been applied, as indicated by the Transfer-Encoding header field | |||
(Section 8.7). | (Section 8.7). | |||
message-body = entity-body | message-body = entity-body | |||
| <entity-body encoded as per Transfer-Encoding> | | <entity-body encoded as per Transfer-Encoding> | |||
skipping to change at page 26, line 46 | skipping to change at page 27, line 36 | |||
been applied. When a message-body is included with a message, the | been applied. When a message-body is included with a message, the | |||
transfer-length of that body is determined by one of the following | transfer-length of that body is determined by one of the following | |||
(in order of precedence): | (in order of precedence): | |||
1. Any response message which "MUST NOT" include a message-body | 1. Any response message which "MUST NOT" include a message-body | |||
(such as the 1xx, 204, and 304 responses and any response to a | (such as the 1xx, 204, and 304 responses and any response to a | |||
HEAD request) is always terminated by the first empty line after | HEAD request) is always terminated by the first empty line after | |||
the header fields, regardless of the entity-header fields present | the header fields, regardless of the entity-header fields present | |||
in the message. | in the message. | |||
2. If a Transfer-Encoding header field (Section 8.7) is present, | 2. If a Transfer-Encoding header field (Section 8.7) is present and | |||
then the transfer-length is defined by use of the "chunked" | the "chunked" transfer-coding (Section 3.4) is used, the | |||
transfer-coding (Section 3.4), unless the message is terminated | transfer-length is defined by the use of this transfer-coding. | |||
by closing the connection. | If a Transfer-Encoding header field is present and the "chunked" | |||
transfer-coding is not present, the transfer-length is defined by | ||||
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 | decimal 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 | |||
skipping to change at page 30, line 11 | skipping to change at page 31, line 4 | |||
resource on an origin server or gateway. In this case the absolute | resource on an origin server or gateway. In this case the absolute | |||
path of the URI MUST be transmitted (see Section 3.2.1, path- | path of the URI MUST be transmitted (see Section 3.2.1, path- | |||
absolute) as the Request-URI, and the network location of the URI | absolute) as the Request-URI, and the network location of the URI | |||
(authority) MUST be transmitted in a Host header field. For example, | (authority) MUST be transmitted in a Host header field. For example, | |||
a client wishing to retrieve the resource above directly from the | a client wishing to retrieve the resource above directly from the | |||
origin server would create a TCP connection to port 80 of the host | origin server would create a TCP connection to port 80 of the host | |||
"www.example.org" and send the lines: | "www.example.org" and send the lines: | |||
GET /pub/WWW/TheProject.html HTTP/1.1 | GET /pub/WWW/TheProject.html HTTP/1.1 | |||
Host: www.example.org | Host: www.example.org | |||
followed by the remainder of the Request. Note that the absolute | followed by the remainder of the Request. Note that the absolute | |||
path cannot be empty; if none is present in the original URI, it MUST | path cannot be empty; if none is present in the original URI, it MUST | |||
be given as "/" (the server root). | be given as "/" (the server root). | |||
The Request-URI is transmitted in the format specified in | The Request-URI is transmitted in the format specified in | |||
Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" | Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG | |||
encoding [RFC2396], the origin server MUST decode the Request-URI in | HEXDIG" encoding ([RFC2396], Section 2.4.1), the origin server MUST | |||
order to properly interpret the request. Servers SHOULD respond to | decode the Request-URI in order to properly interpret the request. | |||
invalid Request-URIs with an appropriate status code. | Servers SHOULD respond to invalid Request-URIs with an appropriate | |||
status code. | ||||
A transparent proxy MUST NOT rewrite the "path-absolute" part of the | A transparent proxy MUST NOT rewrite the "path-absolute" part of the | |||
received Request-URI when forwarding it to the next inbound server, | received Request-URI when forwarding it to the next inbound server, | |||
except as noted above to replace a null path-absolute with "/". | except as noted above to replace a null path-absolute with "/". | |||
Note: The "no rewrite" rule prevents the proxy from changing the | Note: The "no rewrite" rule prevents the proxy from changing the | |||
meaning of the request when the origin server is improperly using | meaning of the request when the origin server is improperly using | |||
a non-reserved URI character for a reserved purpose. Implementors | a non-reserved URI character for a reserved purpose. Implementors | |||
should be aware that some pre-HTTP/1.1 proxies have been known to | should be aware that some pre-HTTP/1.1 proxies have been known to | |||
rewrite the Request-URI. | rewrite the Request-URI. | |||
5.2. The Resource Identified by a Request | 5.2. The Resource Identified by a Request | |||
The exact resource identified by an Internet request is determined by | The exact resource identified by an Internet request is determined by | |||
examining both the Request-URI and the Host header field. | examining both the Request-URI and the Host header field. | |||
An origin server that does not allow resources to differ by the | An origin server that does not allow resources to differ by the | |||
requested host MAY ignore the Host header field value when | requested host MAY ignore the Host header field value when | |||
determining the resource identified by an HTTP/1.1 request. (But see | determining the resource identified by an HTTP/1.1 request. (But see | |||
Appendix D.1.1 for other requirements on Host support in HTTP/1.1.) | Appendix C.1.1 for other requirements on Host support in HTTP/1.1.) | |||
An origin server that does differentiate resources based on the host | An origin server that does differentiate resources based on the host | |||
requested (sometimes referred to as virtual hosts or vanity host | requested (sometimes referred to as virtual hosts or vanity host | |||
names) MUST use the following rules for determining the requested | names) MUST use the following rules for determining the requested | |||
resource on an HTTP/1.1 request: | resource on an HTTP/1.1 request: | |||
1. If Request-URI is an absoluteURI, the host is part of the | 1. If Request-URI is an absoluteURI, the host is part of the | |||
Request-URI. Any Host header field value in the request MUST be | Request-URI. Any Host header field value in the request MUST be | |||
ignored. | ignored. | |||
skipping to change at page 34, line 9 | skipping to change at page 34, line 52 | |||
case the client does not want to maintain a connection for more than | case the client does not want to maintain a connection for more than | |||
that request, it SHOULD send a Connection header including the | that request, it SHOULD send a Connection header including the | |||
connection-token close. | connection-token close. | |||
If either the client or the server sends the close token in the | If either the client or the server sends the close token in the | |||
Connection header, that request becomes the last one for the | Connection header, that request becomes the last one for the | |||
connection. | connection. | |||
Clients and servers SHOULD NOT assume that a persistent connection is | Clients and servers SHOULD NOT assume that a persistent connection is | |||
maintained for HTTP versions less than 1.1 unless it is explicitly | maintained for HTTP versions less than 1.1 unless it is explicitly | |||
signaled. See Appendix D.2 for more information on backward | signaled. See Appendix C.2 for more information on backward | |||
compatibility with HTTP/1.0 clients. | compatibility with HTTP/1.0 clients. | |||
In order to remain persistent, all messages on the connection MUST | In order to remain persistent, all messages on the connection MUST | |||
have a self-defined message length (i.e., one not defined by closure | have a self-defined message length (i.e., one not defined by closure | |||
of the connection), as described in Section 4.4. | of the connection), as described in Section 4.4. | |||
7.1.2.2. Pipelining | 7.1.2.2. Pipelining | |||
A client that supports persistent connections MAY "pipeline" its | A client that supports persistent connections MAY "pipeline" its | |||
requests (i.e., send multiple requests without waiting for each | requests (i.e., send multiple requests without waiting for each | |||
skipping to change at page 40, line 27 | skipping to change at page 41, line 20 | |||
An HTTP/1.1 server that does not support persistent connections MUST | An HTTP/1.1 server that does not support persistent connections MUST | |||
include the "close" connection option in every response message that | include the "close" connection option in every response message that | |||
does not have a 1xx (informational) status code. | does not have a 1xx (informational) status code. | |||
A system receiving an HTTP/1.0 (or lower-version) message that | A system receiving an HTTP/1.0 (or lower-version) message that | |||
includes a Connection header MUST, for each connection-token in this | includes a Connection header 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 D.2. | See Appendix C.2. | |||
8.2. Content-Length | 8.2. Content-Length | |||
The Content-Length entity-header field indicates the size of the | The Content-Length entity-header field indicates the size of the | |||
entity-body, in decimal number of OCTETs, sent to the recipient or, | entity-body, in decimal number of OCTETs, sent to the recipient or, | |||
in the case of the HEAD method, the size of the entity-body that | in the case of the HEAD method, the size of the entity-body that | |||
would have been sent had the request been a GET. | would have been sent had the request been a GET. | |||
Content-Length = "Content-Length" ":" 1*DIGIT | Content-Length = "Content-Length" ":" 1*DIGIT | |||
skipping to change at page 43, line 5 | skipping to change at page 43, line 50 | |||
A client MUST include a Host header field in all HTTP/1.1 request | A client MUST include a Host header field in all HTTP/1.1 request | |||
messages. If the requested URI does not include an Internet host | messages. If the requested URI does not include an Internet host | |||
name for the service being requested, then the Host header field MUST | name for the service being requested, then the Host header field MUST | |||
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | |||
request message it forwards does contain an appropriate Host header | request message it forwards does contain an appropriate Host header | |||
field that identifies the service being requested by the proxy. All | field that identifies the service being requested by the proxy. All | |||
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | |||
status code to any HTTP/1.1 request message which lacks a Host header | status code to any HTTP/1.1 request message which lacks a Host header | |||
field. | field. | |||
See Sections 5.2 and D.1.1 for other requirements relating to Host. | See Sections 5.2 and C.1.1 for other requirements relating to Host. | |||
8.5. TE | 8.5. TE | |||
The TE request-header field indicates what extension transfer-codings | The TE request-header field indicates what extension transfer-codings | |||
it is willing to accept in the response and whether or not it is | it is willing to accept in the response and whether or not it is | |||
willing to accept trailer fields in a chunked transfer-coding. Its | willing to accept trailer fields in a chunked transfer-coding. Its | |||
value may consist of the keyword "trailers" and/or a comma-separated | value may consist of the keyword "trailers" and/or a comma-separated | |||
list of extension transfer-coding names with optional accept | list of extension transfer-coding names with optional accept | |||
parameters (as described in Section 3.4). | parameters (as described in Section 3.4). | |||
skipping to change at page 48, line 22 | skipping to change at page 49, line 22 | |||
| TE | http | standard | Section 8.5 | | | TE | http | standard | Section 8.5 | | |||
| Trailer | http | standard | Section 8.6 | | | Trailer | http | standard | Section 8.6 | | |||
| Transfer-Encoding | http | standard | Section 8.7 | | | Transfer-Encoding | http | standard | Section 8.7 | | |||
| Upgrade | http | standard | Section 8.8 | | | Upgrade | http | standard | Section 8.8 | | |||
| Via | http | standard | Section 8.9 | | | Via | http | standard | Section 8.9 | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
The change controller is: "IETF (iesg@ietf.org) - Internet | The change controller is: "IETF (iesg@ietf.org) - Internet | |||
Engineering Task Force". | Engineering Task Force". | |||
9.2. URI Scheme Registration | ||||
The entry for the "http" URI Scheme in the registry located at | ||||
<http://www.iana.org/assignments/uri-schemes.html> should be updated | ||||
to point to Section 3.2.2 of this document (see [RFC4395]). | ||||
9.3. Internet Media Type Registrations | ||||
This document serves as the specification for the Internet media | ||||
types "message/http" and "application/http". The following is to be | ||||
registered with IANA (see [RFC4288]). | ||||
9.3.1. Internet Media Type message/http | ||||
The message/http type can be used to enclose a single HTTP request or | ||||
response message, provided that it obeys the MIME restrictions for | ||||
all "message" types regarding line length and encodings. | ||||
Type name: message | ||||
Subtype name: http | ||||
Required parameters: none | ||||
Optional parameters: version, msgtype | ||||
version: The HTTP-Version number of the enclosed message (e.g., | ||||
"1.1"). If not present, the version can be determined from the | ||||
first line of the body. | ||||
msgtype: The message type -- "request" or "response". If not | ||||
present, the type can be determined from the first line of the | ||||
body. | ||||
Encoding considerations: only "7bit", "8bit", or "binary" are | ||||
permitted | ||||
Security considerations: none | ||||
Interoperability considerations: none | ||||
Published specification: This specification (see Section 9.3.1). | ||||
Applications that use this media type: | ||||
Additional information: | ||||
Magic number(s): none | ||||
File extension(s): none | ||||
Macintosh file type code(s): none | ||||
Person and email address to contact for further information: See | ||||
Authors Section. | ||||
Intended usage: COMMON | ||||
Restrictions on usage: none | ||||
Author/Change controller: IESG | ||||
9.3.2. Internet Media Type application/http | ||||
The application/http type can be used to enclose a pipeline of one or | ||||
more HTTP request or response messages (not intermixed). | ||||
Type name: application | ||||
Subtype name: http | ||||
Required parameters: none | ||||
Optional parameters: version, msgtype | ||||
version: The HTTP-Version number of the enclosed messages (e.g., | ||||
"1.1"). If not present, the version can be determined from the | ||||
first line of the body. | ||||
msgtype: The message type -- "request" or "response". If not | ||||
present, the type can be determined from the first line of the | ||||
body. | ||||
Encoding considerations: HTTP messages enclosed by this type are in | ||||
"binary" format; use of an appropriate Content-Transfer-Encoding | ||||
is required when transmitted via E-mail. | ||||
Security considerations: none | ||||
Interoperability considerations: none | ||||
Published specification: This specification (see Section 9.3.2). | ||||
Applications that use this media type: | ||||
Additional information: | ||||
Magic number(s): none | ||||
File extension(s): none | ||||
Macintosh file type code(s): none | ||||
Person and email address to contact for further information: See | ||||
Authors Section. | ||||
Intended usage: COMMON | ||||
Restrictions on usage: none | ||||
Author/Change controller: IESG | ||||
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 52, line 16 | skipping to change at page 55, 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-03 (work in | Semantics", draft-ietf-httpbis-p2-semantics-04 (work in | |||
progress), June 2008. | progress), August 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-03 | and Content Negotiation", draft-ietf-httpbis-p3-payload-04 | |||
(work in progress), June 2008. | (work in progress), August 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-03 (work | Partial Responses", draft-ietf-httpbis-p5-range-04 (work | |||
in progress), June 2008. | in progress), August 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-03 (work in progress), | draft-ietf-httpbis-p6-cache-04 (work in progress), | |||
June 2008. | August 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 53, line 13 | skipping to change at page 56, line 36 | |||
[RFC822ABNF] | [RFC822ABNF] | |||
Crocker, D., "Standard for the format of ARPA Internet | 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. | |||
[USASCII] American National Standards Institute, "Coded Character | [USASCII] American National Standards Institute, "Coded Character | |||
Set -- 7-bit American Standard Code for Information | Set -- 7-bit American Standard Code for Information | |||
Interchange", ANSI X3.4, 1986. | Interchange", ANSI X3.4, 1986. | |||
12.2. Informative References | 12.2. Informative References | |||
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and | ||||
Politics", ACM Transactions on Internet Technology Vol. 1, | ||||
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. | ||||
[Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and | |||
C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, | |||
and PNG", ACM Proceedings of the ACM SIGCOMM '97 | and PNG", ACM Proceedings of the ACM SIGCOMM '97 | |||
conference on Applications, technologies, architectures, | conference on Applications, technologies, architectures, | |||
and protocols for computer communication SIGCOMM '97, | and protocols for computer communication SIGCOMM '97, | |||
September 1997, | September 1997, | |||
<http://doi.acm.org/10.1145/263105.263157>. | <http://doi.acm.org/10.1145/263105.263157>. | |||
[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | |||
Computer Networks and ISDN Systems v. 28, pp. 25-35, | Computer Networks and ISDN Systems v. 28, pp. 25-35, | |||
December 1995. | December 1995, | |||
<http://portal.acm.org/citation.cfm?id=219094>. | ||||
Slightly revised version of paper in Proc. 2nd | ||||
International WWW Conference '94: Mosaic and the Web, Oct. | ||||
1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ | ||||
IT94/Proceedings/DDay/mogul/HTTPLatency.html>. | ||||
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application | |||
and Support", STD 3, RFC 1123, October 1989. | and Support", STD 3, RFC 1123, October 1989. | |||
[RFC1305] Mills, D., "Network Time Protocol (Version 3) | [RFC1305] Mills, D., "Network Time Protocol (Version 3) | |||
Specification, Implementation", RFC 1305, March 1992. | Specification, Implementation", RFC 1305, March 1992. | |||
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., | [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., | |||
Torrey, D., and B. Alberti, "The Internet Gopher Protocol | Torrey, D., and B. Alberti, "The Internet Gopher Protocol | |||
(a distributed document search and retrieval protocol)", | (a distributed document search and retrieval protocol)", | |||
skipping to change at page 54, line 18 | skipping to change at page 57, line 40 | |||
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | |||
RFC 1900, February 1996. | RFC 1900, February 1996. | |||
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | |||
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |||
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | |||
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | |||
RFC 2068, January 1997. | RFC 2068, January 1997. | |||
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management | ||||
Mechanism", RFC 2109, February 1997. | ||||
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use | |||
and Interpretation of HTTP Version Numbers", RFC 2145, | and Interpretation of HTTP Version Numbers", RFC 2145, | |||
May 1997. | May 1997. | |||
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol | [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol | |||
(HTCPCP/1.0)", RFC 2324, April 1998. | (HTCPCP/1.0)", RFC 2324, April 1998. | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | ||||
[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. | |||
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management | ||||
Mechanism", RFC 2965, October 2000. | ||||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
Procedures for Message Header Fields", BCP 90, RFC 3864, | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
September 2004. | September 2004. | |||
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", | [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", | |||
RFC 3977, October 2006. | RFC 3977, October 2006. | |||
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and | |||
Registration Procedures", BCP 13, RFC 4288, December 2005. | Registration Procedures", BCP 13, RFC 4288, December 2005. | |||
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and | ||||
Registration Procedures for New URI Schemes", BCP 115, | ||||
RFC 4395, February 2006. | ||||
[RFC822] Crocker, D., "Standard for the format of ARPA Internet | [RFC822] Crocker, D., "Standard for the format of ARPA Internet | |||
text messages", STD 11, RFC 822, August 1982. | text messages", STD 11, RFC 822, August 1982. | |||
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", | |||
STD 9, RFC 959, October 1985. | STD 9, RFC 959, October 1985. | |||
[Spe] Spero, S., "Analysis of HTTP Performance Problems", | [Spe] Spero, S., "Analysis of HTTP Performance Problems", | |||
<http://sunsite.unc.edu/mdma-release/http-prob.html>. | <http://sunsite.unc.edu/mdma-release/http-prob.html>. | |||
[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of | |||
HTTP Performance", ISI Research Report ISI/RR-98-463, | HTTP Performance", ISI Research Report ISI/RR-98-463, | |||
Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. | |||
(original report dated Aug. 1996) | (original report dated Aug. 1996) | |||
[WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., | [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., | |||
Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface | Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface | |||
Protocol Prototype Functional Specification (v1.5)", | Protocol Prototype Functional Specification (v1.5)", | |||
Thinking Machines Corporation , April 1990. | Thinking Machines Corporation , April 1990. | |||
Appendix A. Internet Media Types | Appendix A. Tolerant Applications | |||
In addition to defining HTTP/1.1, this document serves as the | ||||
specification for the Internet media type "message/http" and | ||||
"application/http". The following is to be registered with IANA | ||||
[RFC4288]. | ||||
A.1. Internet Media Type message/http | ||||
The message/http type can be used to enclose a single HTTP request or | ||||
response message, provided that it obeys the MIME restrictions for | ||||
all "message" types regarding line length and encodings. | ||||
Type name: message | ||||
Subtype name: http | ||||
Required parameters: none | ||||
Optional parameters: version, msgtype | ||||
version: The HTTP-Version number of the enclosed message (e.g., | ||||
"1.1"). If not present, the version can be determined from the | ||||
first line of the body. | ||||
msgtype: The message type -- "request" or "response". If not | ||||
present, the type can be determined from the first line of the | ||||
body. | ||||
Encoding considerations: only "7bit", "8bit", or "binary" are | ||||
permitted | ||||
Security considerations: none | ||||
Interoperability considerations: none | ||||
Published specification: This specification (see Appendix A.1). | ||||
Applications that use this media type: | ||||
Additional information: | ||||
Magic number(s): none | ||||
File extension(s): none | ||||
Macintosh file type code(s): none | ||||
Person and email address to contact for further information: See | ||||
Authors Section. | ||||
Intended usage: COMMON | ||||
Restrictions on usage: none | ||||
Author/Change controller: IESG | ||||
A.2. Internet Media Type application/http | ||||
The application/http type can be used to enclose a pipeline of one or | ||||
more HTTP request or response messages (not intermixed). | ||||
Type name: application | ||||
Subtype name: http | ||||
Required parameters: none | ||||
Optional parameters: version, msgtype | ||||
version: The HTTP-Version number of the enclosed messages (e.g., | ||||
"1.1"). If not present, the version can be determined from the | ||||
first line of the body. | ||||
msgtype: The message type -- "request" or "response". If not | ||||
present, the type can be determined from the first line of the | ||||
body. | ||||
Encoding considerations: HTTP messages enclosed by this type are in | ||||
"binary" format; use of an appropriate Content-Transfer-Encoding | ||||
is required when transmitted via E-mail. | ||||
Security considerations: none | ||||
Interoperability considerations: none | ||||
Published specification: This specification (see Appendix A.2). | ||||
Applications that use this media type: | ||||
Additional information: | ||||
Magic number(s): none | ||||
File extension(s): none | ||||
Macintosh file type code(s): none | ||||
Person and email address to contact for further information: See | ||||
Authors Section. | ||||
Intended usage: COMMON | ||||
Restrictions on usage: none | ||||
Author/Change controller: IESG | ||||
Appendix B. Tolerant Applications | ||||
Although this document specifies the requirements for the generation | Although this document specifies the requirements for the generation | |||
of HTTP/1.1 messages, not all applications will be correct in their | of HTTP/1.1 messages, not all applications will be correct in their | |||
implementation. We therefore recommend that operational applications | implementation. We therefore recommend that operational applications | |||
be tolerant of deviations whenever those deviations can be | be tolerant of deviations whenever those deviations can be | |||
interpreted unambiguously. | interpreted unambiguously. | |||
Clients SHOULD be tolerant in parsing the Status-Line and servers | Clients SHOULD be tolerant in parsing the Status-Line and servers | |||
tolerant when parsing the Request-Line. In particular, they SHOULD | tolerant when parsing the Request-Line. In particular, they SHOULD | |||
accept any amount of SP or HTAB characters between fields, even | accept any amount of SP or HTAB characters between fields, even | |||
skipping to change at page 58, line 28 | skipping to change at page 59, line 47 | |||
proper value. | proper value. | |||
o All expiration-related calculations MUST be done in GMT. The | o All expiration-related calculations MUST be done in GMT. The | |||
local time zone MUST NOT influence the calculation or comparison | local time zone MUST NOT influence the calculation or comparison | |||
of an age or expiration time. | of an age or expiration time. | |||
o If an HTTP header incorrectly carries a date value with a time | o If an HTTP header incorrectly carries a date value with a time | |||
zone other than GMT, it MUST be converted into GMT using the most | zone other than GMT, it MUST be converted into GMT using the most | |||
conservative possible conversion. | conservative possible conversion. | |||
Appendix C. Conversion of Date Formats | Appendix B. Conversion of Date Formats | |||
HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to | HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to | |||
simplify the process of date comparison. Proxies and gateways from | simplify the process of date comparison. Proxies and gateways from | |||
other protocols SHOULD ensure that any Date header field present in a | other protocols SHOULD ensure that any Date header field present in a | |||
message conforms to one of the HTTP/1.1 formats and rewrite the date | message conforms to one of the HTTP/1.1 formats and rewrite the date | |||
if necessary. | if necessary. | |||
Appendix D. Compatibility with Previous Versions | Appendix C. Compatibility with Previous Versions | |||
It is beyond the scope of a protocol specification to mandate | It is beyond the scope of a protocol specification to mandate | |||
compliance with previous versions. HTTP/1.1 was deliberately | compliance with previous versions. HTTP/1.1 was deliberately | |||
designed, however, to make supporting previous versions easy. It is | designed, however, to make supporting previous versions easy. It is | |||
worth noting that, at the time of composing this specification | worth noting that, at the time of composing this specification | |||
(1996), we would expect commercial HTTP/1.1 servers to: | (1996), we would expect commercial HTTP/1.1 servers to: | |||
o recognize the format of the Request-Line for HTTP/0.9, 1.0, and | o recognize the format of the Request-Line for HTTP/0.9, 1.0, and | |||
1.1 requests; | 1.1 requests; | |||
skipping to change at page 59, line 21 | skipping to change at page 60, line 38 | |||
o understand any valid response in the format of HTTP/0.9, 1.0, or | o understand any valid response in the format of HTTP/0.9, 1.0, or | |||
1.1. | 1.1. | |||
For most implementations of HTTP/1.0, each connection is established | For most implementations of HTTP/1.0, each connection is established | |||
by the client prior to the request and closed by the server after | by the client prior to the request and closed by the server after | |||
sending the response. Some implementations implement the Keep-Alive | sending the response. Some implementations implement the Keep-Alive | |||
version of persistent connections described in Section 19.7.1 of | version of persistent connections described in Section 19.7.1 of | |||
[RFC2068]. | [RFC2068]. | |||
D.1. Changes from HTTP/1.0 | C.1. Changes from HTTP/1.0 | |||
This section summarizes major differences between versions HTTP/1.0 | This section summarizes major differences between versions HTTP/1.0 | |||
and HTTP/1.1. | and HTTP/1.1. | |||
D.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP | C.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP | |||
Addresses | Addresses | |||
The requirements that clients and servers support the Host request- | The requirements that clients and servers support the Host request- | |||
header, report an error if the Host request-header (Section 8.4) is | header, report an error if the Host request-header (Section 8.4) is | |||
missing from an HTTP/1.1 request, and accept absolute URIs | missing from an HTTP/1.1 request, and accept absolute URIs | |||
(Section 5.1.2) are among the most important changes defined by this | (Section 5.1.2) are among the most important changes defined by this | |||
specification. | specification. | |||
Older HTTP/1.0 clients assumed a one-to-one relationship of IP | Older HTTP/1.0 clients assumed a one-to-one relationship of IP | |||
addresses and servers; there was no other established mechanism for | addresses and servers; there was no other established mechanism for | |||
skipping to change at page 60, line 14 | skipping to change at page 61, line 30 | |||
o Both clients and servers MUST support the Host request-header. | o Both clients and servers MUST support the Host request-header. | |||
o A client that sends an HTTP/1.1 request MUST send a Host header. | o A client that sends an HTTP/1.1 request MUST send a Host header. | |||
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 | o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 | |||
request does not include a Host request-header. | request does not include a Host request-header. | |||
o Servers MUST accept absolute URIs. | o Servers MUST accept absolute URIs. | |||
D.2. Compatibility with HTTP/1.0 Persistent Connections | C.2. Compatibility with HTTP/1.0 Persistent Connections | |||
Some clients and servers might wish to be compatible with some | Some clients and servers might wish to be compatible with some | |||
previous implementations of persistent connections in HTTP/1.0 | previous implementations of persistent connections in HTTP/1.0 | |||
clients and servers. Persistent connections in HTTP/1.0 are | clients and servers. Persistent connections in HTTP/1.0 are | |||
explicitly negotiated as they are not the default behavior. HTTP/1.0 | explicitly negotiated as they are not the default behavior. HTTP/1.0 | |||
experimental implementations of persistent connections are faulty, | experimental implementations of persistent connections are faulty, | |||
and the new facilities in HTTP/1.1 are designed to rectify these | and the new facilities in HTTP/1.1 are designed to rectify these | |||
problems. The problem was that some existing 1.0 clients may be | problems. The problem was that some existing 1.0 clients may be | |||
sending Keep-Alive to a proxy server that doesn't understand | sending Keep-Alive to a proxy server that doesn't understand | |||
Connection, which would then erroneously forward it to the next | Connection, which would then erroneously forward it to the next | |||
skipping to change at page 60, line 41 | skipping to change at page 62, line 8 | |||
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 [RFC2068]. | |||
D.3. Changes from RFC 2068 | C.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 | |||
to straighten out exactly how message lengths are computed. | to straighten out exactly how message lengths are computed. | |||
(Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) | (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) | |||
skipping to change at page 61, line 20 | skipping to change at page 62, line 36 | |||
interactions with chunked encoding. The solution is that transfer- | interactions with chunked encoding. The solution is that transfer- | |||
codings become as full fledged as content-codings. This involves | codings become as full fledged as content-codings. This involves | |||
adding an IANA registry for transfer-codings (separate from content | adding an IANA registry for transfer-codings (separate from content | |||
codings), a new header field (TE) and enabling trailer headers in the | codings), a new header field (TE) and enabling trailer headers in the | |||
future. Transfer encoding is a major performance benefit, so it was | future. Transfer encoding is a major performance benefit, so it was | |||
worth fixing [Nie1997]. TE also solves another, obscure, downward | worth fixing [Nie1997]. TE also solves another, obscure, downward | |||
interoperability problem that could have occurred due to interactions | interoperability problem that could have occurred due to interactions | |||
between authentication trailers, chunked encoding and HTTP/1.0 | between authentication trailers, chunked encoding and HTTP/1.0 | |||
clients.(Section 3.4, 3.4.1, and 8.5) | clients.(Section 3.4, 3.4.1, and 8.5) | |||
D.4. Changes from RFC 2616 | C.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). Furthermore, the quoted-pair | the comment and quoted-string rules). Furthermore, the quoted-pair | |||
rule does not allow escaping NUL, CR or LF anymore. (Section 2.2) | 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) | |||
skipping to change at page 61, line 36 | skipping to change at page 63, line 4 | |||
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. | |||
(Section 8.1) | (Section 8.1) | |||
Appendix E. Change Log (to be removed by RFC Editor before publication) | Appendix D. Change Log (to be removed by RFC Editor before publication) | |||
E.1. Since RFC2616 | D.1. Since RFC2616 | |||
Extracted relevant partitions from [RFC2616]. | Extracted relevant partitions from [RFC2616]. | |||
E.2. Since draft-ietf-httpbis-p1-messaging-00 | D.2. Since draft-ietf-httpbis-p1-messaging-00 | |||
Closed issues: | Closed issues: | |||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP | |||
Version should be case sensitive" | Version should be case sensitive" | |||
(<http://purl.org/NET/http-errata#verscase>) | (<http://purl.org/NET/http-errata#verscase>) | |||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' | |||
characters" (<http://purl.org/NET/http-errata#unsafe-uri>) | characters" (<http://purl.org/NET/http-errata#unsafe-uri>) | |||
skipping to change at page 63, line 24 | skipping to change at page 64, line 36 | |||
up-to-date references" | up-to-date references" | |||
Other changes: | Other changes: | |||
o Update media type registrations to use RFC4288 template. | o Update media type registrations to use RFC4288 template. | |||
o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF | o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF | |||
for chunk-data (work in progress on | for chunk-data (work in progress on | |||
<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) | <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) | |||
E.3. Since draft-ietf-httpbis-p1-messaging-01 | D.3. Since draft-ietf-httpbis-p1-messaging-01 | |||
Closed issues: | Closed issues: | |||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on | |||
GET (and other) requests" | GET (and other) requests" | |||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating | |||
to RFC4288" | to RFC4288" | |||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status | |||
skipping to change at page 64, line 22 | skipping to change at page 65, line 34 | |||
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 | D.4. Since draft-ietf-httpbis-p1-messaging-02 | |||
Closed issues: | Closed issues: | |||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date | |||
vs. rfc1123-date" | vs. rfc1123-date" | |||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in | |||
quoted-pair" | quoted-pair" | |||
Ongoing work on IANA Message Header Registration | Ongoing work on IANA Message Header Registration | |||
skipping to change at page 64, line 44 | skipping to change at page 66, line 8 | |||
o Reference RFC 3984, and update header registrations for headers | o Reference RFC 3984, and update header registrations for headers | |||
defined in this document. | defined in this document. | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Replace string literals when the string really is case-sensitive | o Replace string literals when the string really is case-sensitive | |||
(HTTP-Version). | (HTTP-Version). | |||
D.5. Since draft-ietf-httpbis-p1-messaging-03 | ||||
Closed issues: | ||||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/28>: | ||||
"Connection closing" | ||||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move | ||||
registrations and registry information to IANA Considerations" | ||||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new | ||||
URL for PAD1995 reference" | ||||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA | ||||
Considerations: update HTTP URI scheme registration" | ||||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite | ||||
HTTPS URI scheme definition" | ||||
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/129>: "List- | ||||
type headers vs Set-Cookie" | ||||
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-Date). | ||||
o Replace HEX by HEXDIG for future consistence with RFC 5234's core | ||||
rules. | ||||
Index | Index | |||
A | A | |||
application/http Media Type 56 | application/http Media Type 50 | |||
C | C | |||
cache 8 | cache 8 | |||
cacheable 9 | cacheable 9 | |||
client 7 | client 7 | |||
connection 6 | connection 6 | |||
Connection header 39 | Connection header 40 | |||
content negotiation 7 | content negotiation 7 | |||
Content-Length header 40 | Content-Length header 41 | |||
D | D | |||
Date header 41 | Date header 42 | |||
downstream 9 | downstream 9 | |||
E | E | |||
entity 7 | entity 7 | |||
G | G | |||
gateway 8 | gateway 8 | |||
Grammar | Grammar | |||
absoluteURI 18 | absoluteURI 18 | |||
ALPHA 14 | ALPHA 14 | |||
asctime-date 20 | asctime-date 20 | |||
attribute 20 | attribute 21 | |||
authority 18 | authority 18 | |||
CHAR 14 | CHAR 14 | |||
chunk 22 | chunk 22 | |||
chunk-data 22 | chunk-data 22 | |||
chunk-ext-name 22 | chunk-ext-name 22 | |||
chunk-ext-val 22 | chunk-ext-val 22 | |||
chunk-extension 22 | chunk-extension 22 | |||
chunk-size 22 | chunk-size 22 | |||
Chunked-Body 22 | Chunked-Body 22 | |||
comment 15 | comment 15 | |||
Connection 39 | Connection 40 | |||
connection-token 39 | connection-token 40 | |||
Content-Length 40 | Content-Length 41 | |||
CR 14 | CR 14 | |||
CRLF 14 | CRLF 14 | |||
ctext 15 | ctext 15 | |||
CTL 14 | CTL 14 | |||
Date 41 | Date 42 | |||
date1 20 | date1 20 | |||
date2 20 | date2 20 | |||
date3 20 | date3 20 | |||
DIGIT 14 | DIGIT 14 | |||
DQUOTE 14 | DQUOTE 14 | |||
extension-code 32 | extension-code 33 | |||
extension-method 29 | extension-method 29 | |||
field-content 25 | field-content 25 | |||
field-name 25 | field-name 25 | |||
field-value 25 | field-value 25 | |||
general-header 28 | general-header 29 | |||
generic-message 24 | generic-message 25 | |||
HEX 15 | HEXDIG 15 | |||
Host 42 | Host 43 | |||
HTAB 14 | HTAB 14 | |||
HTTP-date 20 | HTTP-date 20 | |||
HTTP-message 24 | HTTP-message 24 | |||
HTTP-Prot-Name 16 | 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 26 | |||
message-header 25 | message-header 25 | |||
Method 29 | Method 29 | |||
month 20 | month 20 | |||
obsolete-date 20 | obsolete-date 20 | |||
OCTET 14 | OCTET 14 | |||
parameter 20 | parameter 21 | |||
path-absolute 18 | path-absolute 18 | |||
port 18 | port 18 | |||
product 23 | product 24 | |||
product-version 23 | product-version 24 | |||
protocol-name 46 | protocol-name 47 | |||
protocol-version 46 | protocol-version 47 | |||
pseudonym 46 | pseudonym 47 | |||
qdtext 15 | qdtext 15 | |||
query 18 | query 18 | |||
quoted-pair 15 | quoted-pair 15 | |||
quoted-string 15 | quoted-string 15 | |||
quoted-text 15 | quoted-text 15 | |||
Reason-Phrase 32 | Reason-Phrase 33 | |||
received-by 46 | received-by 47 | |||
received-protocol 46 | received-protocol 47 | |||
relativeURI 18 | relativeURI 18 | |||
Request 28 | Request 29 | |||
Request-Line 28 | Request-Line 29 | |||
Request-URI 29 | Request-URI 30 | |||
Response 31 | Response 32 | |||
rfc850-date 20 | rfc850-date 20 | |||
rfc1123-date 20 | rfc1123-date 20 | |||
separators 15 | separators 15 | |||
SP 14 | SP 14 | |||
start-line 24 | start-line 25 | |||
Status-Code 32 | Status-Code 33 | |||
Status-Line 31 | Status-Line 32 | |||
t-codings 43 | t-codings 44 | |||
tchar 15 | tchar 15 | |||
TE 43 | TE 44 | |||
TEXT 14 | TEXT 14 | |||
time 20 | time 20 | |||
token 15 | token 15 | |||
Trailer 44 | Trailer 45 | |||
trailer-part 22 | trailer-part 22 | |||
transfer-coding 20 | transfer-coding 21 | |||
Transfer-Encoding 44 | Transfer-Encoding 45 | |||
transfer-extension 20 | transfer-extension 21 | |||
Upgrade 45 | Upgrade 46 | |||
uri-host 18 | uri-host 18 | |||
value 20 | value 21 | |||
Via 46 | Via 47 | |||
weekday 20 | weekday 20 | |||
wkday 20 | wkday 20 | |||
H | H | |||
Headers | Headers | |||
Connection 39 | Connection 40 | |||
Content-Length 40 | Content-Length 41 | |||
Date 41 | Date 42 | |||
Host 42 | Host 43 | |||
TE 43 | TE 44 | |||
Trailer 44 | Trailer 45 | |||
Transfer-Encoding 44 | Transfer-Encoding 45 | |||
Upgrade 45 | Upgrade 46 | |||
Via 46 | Via 47 | |||
Host header 42 | Host header 43 | |||
http URI scheme 18 | ||||
https URI scheme 18 | ||||
I | I | |||
implied *LWS 13 | implied *LWS 13 | |||
inbound 9 | inbound 9 | |||
M | M | |||
Media Type | Media Type | |||
application/http 56 | application/http 50 | |||
message/http 55 | message/http 49 | |||
message 6 | message 6 | |||
message/http Media Type 55 | message/http Media Type 49 | |||
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 68, line 14 | skipping to change at page 70, line 10 | |||
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 | |||
TE header 43 | TE header 44 | |||
Trailer header 44 | Trailer header 45 | |||
Transfer-Encoding header 44 | Transfer-Encoding header 45 | |||
tunnel 8 | tunnel 8 | |||
U | U | |||
Upgrade header 45 | Upgrade header 46 | |||
upstream 9 | upstream 9 | |||
URI scheme | ||||
http 18 | ||||
https 18 | ||||
user agent 7 | user agent 7 | |||
V | V | |||
variant 7 | variant 7 | |||
Via header 46 | Via header 47 | |||
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. 83 change blocks. | ||||
300 lines changed or deleted | 397 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/ |