rfc2616.txt   p1-messaging.txt 
Network Working Group R. Fielding Network Working Group R. Fielding
Request for Comments: 2616 UC Irvine Internet-Draft UC Irvine
Obsoletes: 2068 J. Gettys Obsoletes: 2068, 2616, 2617 J. Gettys
Category: Standards Track Compaq/W3C (if approved) Compaq/W3C
J. Mogul Intended status: Standards Track J. Mogul
Compaq Expires: March 4, 2008 Compaq
H. Frystyk H. Frystyk
W3C/MIT W3C/MIT
L. Masinter L. Masinter
Xerox Xerox
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Hypertext Transfer Protocol -- HTTP/1.1 September 2007
HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-fielding-http-p1-messaging-00
Status of this Memo Status of this Memo
This document specifies an Internet standards track protocol for the This document is an Internet-Draft and is subject to all provisions
Internet community, and requests discussion and suggestions for of Section 3 of RFC 3667. By submitting this Internet-Draft, each
improvements. Please refer to the current edition of the "Internet author represents that any applicable patent or other IPR claims of
Official Protocol Standards" (STD 1) for the standardization state which he or she is aware have been or will be disclosed, and any of
and status of this protocol. Distribution of this memo is unlimited. which he or she become aware will be disclosed, in accordance with
RFC 3668.
Copyright Notice Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Copyright (C) The Internet Society (1999). Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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. It is a generic, stateless, protocol which can be used for systems. HTTP has been in use by the World Wide Web global
many tasks beyond its use for hypertext, such as name servers and information initiative since 1990. This document is Part 1 of the
distributed object management systems, through extension of its eight-part specification that defines the protocol referred to as
request methods, error codes and headers [47]. A feature of HTTP is "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part
the typing and negotiation of data representation, allowing systems 1 provides an overview of HTTP and its associated terminology,
to be built independently of the data being transferred. defines the "http" and "https" Uniform Resource Identifier (URI)
schemes, defines the generic message syntax and parsing requirements
HTTP has been in use by the World-Wide Web global information for HTTP message frames, and describes general security concerns for
initiative since 1990. This specification defines the protocol implementations.
referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 9 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 13 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 8
2. Notational Conventions and Generic Grammar . . . . . . . . . 16 2. Notational Conventions and Generic Grammar . . . . . . . . . . 10
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 16 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 18 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 12
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 20 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 14
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 20 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 21 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 21 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 15
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 21 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 22 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 16
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 22 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 17
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 22 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 24 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 18
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 24 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 19
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 25 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 25 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 26 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 22
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 27 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 23
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 29 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 24
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 29 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 25
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 30 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 31 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 31 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 32 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 26
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 32 5.2. The Resource Identified by a Request . . . . . . . . . . . 28
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 33 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 29
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 30
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 30
4.5. General Header Fields . . . . . . . . . . . . . . . . . 37 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 30
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 32
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 39 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 32
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 39 7.2. Message Transmission Requirements . . . . . . . . . . . . 33
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 40 7.2.1. Persistent Connections and Flow Control . . . . . . . 33
5.2. The Resource Identified by a Request . . . . . . . . . . 41 7.2.2. Monitoring Connections for Error Status Messages . . . 33
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 42 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 34
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.2.4. Client Behavior if Server Prematurely Closes
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 Connection . . . . . . . . . . . . . . . . . . . . . . 36
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 36
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 46 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 37
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 37
7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 47 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 47 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 39
7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 48 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 48 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Persistent Connections . . . . . . . . . . . . . . . . . 49 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 42
8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 49 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 49 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8.1.4. Practical Considerations . . . . . . . . . . . . . . 51 9.1. Personal Information . . . . . . . . . . . . . . . . . . . 45
8.2. Message Transmission Requirements . . . . . . . . . . . 52 9.2. Abuse of Server Log Information . . . . . . . . . . . . . 45
8.2.1. Persistent Connections and Flow Control . . . . . . 52 9.3. Attacks Based On File and Path Names . . . . . . . . . . . 46
8.2.2. Monitoring Connections for Error Status Messages . . 52 9.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 46
8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 53 9.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 47
8.2.4. Client Behavior if Server Prematurely Closes 9.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 47
Connection . . . . . . . . . . . . . . . . . . . . . 55 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 56 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 56 Appendix A. Internet Media Type message/http and
9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 56 application/http . . . . . . . . . . . . . . . . . . 51
9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 56 Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 52
9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 57 Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 53
9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Appendix D. Compatibility with Previous Versions . . . . . . . . 54
9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 58 D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 54
9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 59 D.1.1. Changes to Simplify Multi-homed Web Servers and
9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Conserve IP Addresses . . . . . . . . . . . . . . . . 54
9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 61 D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 55
9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 61 D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 56
9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 62 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 63 Intellectual Property and Copyright Statements . . . . . . . . . . 62
10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 63
10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 63
10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 64
10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 64
10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 64
10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 64
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 65
10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 65
10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 65
10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 66
10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 66
10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 67
10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 67
10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 68
10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 68
10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 69
10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 69
10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 70
10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 70
10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 70
10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 71
10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 71
10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 71
10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 71
10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 71
10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 72
10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 72
10.4.8. 407 Proxy Authentication Required . . . . . . . . . 72
10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 73
10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 73
10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 73
10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 74
10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 74
10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 74
10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 74
10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 74
10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 74
10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 75
10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 75
10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 75
10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 75
10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 75
10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 76
10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 76
10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 76
11. Access Authentication . . . . . . . . . . . . . . . . . . . . 77
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 78
12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 78
12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 79
12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 80
13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 81
13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 82
13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 83
13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 84
13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 84
13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 85
13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 85
13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 86
13.2.1. Server-Specified Expiration . . . . . . . . . . . . 86
13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 86
13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 87
13.2.4. Expiration Calculations . . . . . . . . . . . . . . 89
13.2.5. Disambiguating Expiration Values . . . . . . . . . . 90
13.2.6. Disambiguating Multiple Responses . . . . . . . . . 91
13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 91
13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 92
13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 92
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 93
13.3.4. Rules for When to Use Entity Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 95
13.3.5. Non-validating Conditionals . . . . . . . . . . . . 97
13.4. Response Cacheability . . . . . . . . . . . . . . . . . 97
13.5. Constructing Responses From Caches . . . . . . . . . . . 98
13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 98
13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 99
13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 100
13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 101
13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 102
13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 103
13.8. Errors or Incomplete Response Cache Behavior . . . . . . 103
13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 104
13.10. Invalidation After Updates or Deletions . . . . . . . . 104
13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 105
13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 105
13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 106
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 107
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 107
14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 109
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 109
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 111
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 112
14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 112
14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 113
14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 113
14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 114
14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 116
14.9.2. What May be Stored by Caches . . . . . . . . . . . . 117
14.9.3. Modifications of the Basic Expiration Mechanism . . 118
14.9.4. Cache Revalidation and Reload Controls . . . . . . . 120
14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 122
14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 123
14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 124
14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 125
14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 125
14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 126
14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 127
14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 128
14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 129
14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 131
14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 131
14.18.1. Clockless Origin Server Operation . . . . . . . . . 132
14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 133
14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 133
14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 134
14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 135
14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 135
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 136
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 137
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 139
14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 140
14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 141
14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 141
14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 142
14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 142
14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 143
14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 144
14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 144
14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 144
14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 144
14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 146
14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 147
14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 147
14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 148
14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 149
14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 150
14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 150
14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 152
14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 152
14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 153
14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 154
14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 157
15. Security Considerations . . . . . . . . . . . . . . . . . . . 158
15.1. Personal Information . . . . . . . . . . . . . . . . . . 158
15.1.1. Abuse of Server Log Information . . . . . . . . . . 158
15.1.2. Transfer of Sensitive Information . . . . . . . . . 158
15.1.3. Encoding Sensitive Information in URI's . . . . . . 159
15.1.4. Privacy Issues Connected to Accept Headers . . . . . 160
15.2. Attacks Based On File and Path Names . . . . . . . . . . 160
15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 161
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 161
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 162
15.6. Authentication Credentials and Idle Clients . . . . . . 162
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 162
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 163
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 164
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 166
Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 170
A.1. Internet Media Type message/http and application/http . 170
A.2. Internet Media Type multipart/byteranges . . . . . . . . 171
A.3. Tolerant Applications . . . . . . . . . . . . . . . . . 172
A.4. Differences Between HTTP Entities and RFC 2045
Entities . . . . . . . . . . . . . . . . . . . . . . . . 173
A.4.1. MIME-Version . . . . . . . . . . . . . . . . . . . . 174
A.4.2. Conversion to Canonical Form . . . . . . . . . . . . 174
A.4.3. Conversion of Date Formats . . . . . . . . . . . . . 174
A.4.4. Introduction of Content-Encoding . . . . . . . . . . 175
A.4.5. No Content-Transfer-Encoding . . . . . . . . . . . . 175
A.4.6. Introduction of Transfer-Encoding . . . . . . . . . 175
A.4.7. MHTML and Line Length Limitations . . . . . . . . . 176
A.5. Additional Features . . . . . . . . . . . . . . . . . . 176
A.5.1. Content-Disposition . . . . . . . . . . . . . . . . 176
A.6. Compatibility with Previous Versions . . . . . . . . . . 177
A.6.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . 178
A.6.2. Compatibility with HTTP/1.0 Persistent Connections . 179
A.6.3. Changes from RFC 2068 . . . . . . . . . . . . . . . 179
Appendix B. Index . . . . . . . . . . . . . . . . . . . . . . . 183
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 196
Intellectual Property and Copyright Statements . . . . . . . . . 198
1. Introduction 1. Introduction
This document will define aspects of HTTP related to overall network
operation, message framing, interaction with transport protocols, and
URI schemes. Right now it only includes the extracted relevant
sections of [30] and [31].
1.1. Purpose 1.1. Purpose
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,
referred to as HTTP/0.9, was a simple protocol for raw data transfer referred to as HTTP/0.9, was a simple protocol for raw data transfer
across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved across the Internet. HTTP/1.0, as defined by RFC 1945 [4], improved
the protocol by allowing messages to be in the format of MIME-like the protocol by allowing messages to be in the format of MIME-like
messages, containing metainformation about the data transferred and messages, containing metainformation about the data transferred and
modifiers on the request/response semantics. However, HTTP/1.0 does modifiers on the request/response semantics. However, HTTP/1.0 does
not sufficiently take into consideration the effects of hierarchical not sufficiently take into consideration the effects of hierarchical
proxies, caching, the need for persistent connections, or virtual proxies, caching, the need for persistent connections, or virtual
hosts. In addition, the proliferation of incompletely-implemented hosts. In addition, the proliferation of incompletely-implemented
applications calling themselves "HTTP/1.0" has necessitated a applications calling themselves "HTTP/1.0" has necessitated a
protocol version change in order for two communicating applications protocol version change in order for two communicating applications
to determine each other's true capabilities. to determine each other's true capabilities.
This specification defines the protocol referred to as "HTTP/1.1". This specification defines the protocol referred to as "HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0 in This protocol includes more stringent requirements than HTTP/1.0 in
order to ensure reliable implementation of its features. order to ensure reliable implementation of its features.
Practical information systems require more functionality than simple Practical information systems require more functionality than simple
retrieval, including search, front-end update, and annotation. HTTP retrieval, including search, front-end update, and annotation. HTTP
allows an open-ended set of methods and headers that indicate the allows an open-ended set of methods and headers that indicate the
purpose of a request [47]. It builds on the discipline of reference purpose of a request [32]. It builds on the discipline of reference
provided by the Uniform Resource Identifier (URI) [3], as a location provided by the Uniform Resource Identifier (URI) [2], as a location
(URL) [4] or name (URN) [20], for indicating the resource to which a (URL) [3] or name (URN) [17], for indicating the resource to which a
method is to be applied. Messages are passed in a format similar to method is to be applied. Messages are passed in a format similar to
that used by Internet mail [9] as defined by the Multipurpose that used by Internet mail [7] as defined by the Multipurpose
Internet Mail Extensions (MIME) [7]. Internet Mail Extensions (MIME) [5].
HTTP is also used as a generic protocol for communication between HTTP is also used as a generic protocol for communication between
user agents and proxies/gateways to other Internet systems, including user agents and proxies/gateways to other Internet systems, including
those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], those supported by the SMTP [13], NNTP [11], FTP [15], Gopher [1],
and WAIS [10] protocols. In this way, HTTP allows basic hypermedia and WAIS [8] protocols. In this way, HTTP allows basic hypermedia
access to resources available from diverse applications. access to resources available from diverse applications.
1.2. Requirements 1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [34]. document are to be interpreted as described in RFC 2119 [26].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the MUST or
REQUIRED level and all the SHOULD level requirements for its REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant."
skipping to change at page 9, line 43 skipping to change at page 6, line 4
An HTTP response message, as defined in Section 6. An HTTP response message, as defined in Section 6.
resource resource
A network data object or service that can be identified by a URI, A network data object or service that can be identified by a URI,
as defined in Section 3.2. Resources may be available in multiple as defined in Section 3.2. Resources may be available in multiple
representations (e.g. multiple languages, data formats, size, and representations (e.g. multiple languages, data formats, size, and
resolutions) or vary in other ways. resolutions) or vary in other ways.
entity entity
The information transferred as the payload of a request or The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of response. An entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, as entity-header fields and content in the form of an entity-body, as
described in Section 7. described in [Part 3].
representation representation
An entity included with a response that is subject to content An entity included with a response that is subject to content
negotiation, as described in Section 12. There may exist multiple negotiation, as described in [Part 3]. There may exist multiple
representations associated with a particular response status. representations associated with a particular response status.
content negotiation content negotiation
The mechanism for selecting the appropriate representation when The mechanism for selecting the appropriate representation when
servicing a request, as described in Section 12. The servicing a request, as described in [Part 3]. The representation
representation of entities in any response can be negotiated of entities in any response can be negotiated (including error
(including error responses). responses).
variant variant
A resource may have one, or more than one, representation(s) A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these associated with it at any given instant. Each of these
representations is termed a `varriant'. Use of the term `variant' representations is termed a `varriant'. Use of the term `variant'
does not necessarily imply that the resource is subject to content does not necessarily imply that the resource is subject to content
negotiation. negotiation.
client client
skipping to change at page 11, line 47 skipping to change at page 8, line 4
cache stores cacheable responses in order to reduce the response cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a requests. Any client or server may include a cache, though a
cache cannot be used by a server that is acting as a tunnel. cache cannot be used by a server that is acting as a tunnel.
cacheable cacheable
A response is cacheable if a cache is allowed to store a copy of A response is cacheable if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. the response message for use in answering subsequent requests.
The rules for determining the cacheability of HTTP responses are The rules for determining the cacheability of HTTP responses are
defined in Section 13. Even if a resource is cacheable, there may defined in [Part 6]. Even if a resource is cacheable, there may
be additional constraints on whether a cache can use the cached be additional constraints on whether a cache can use the cached
copy for a particular request. copy for a particular request.
first-hand
A response is first-hand if it comes directly and without
unnecessary delay from the origin server, perhaps via one or more
proxies. A response is also first-hand if its validity has just
been checked directly with the origin server.
explicit expiration time
The time at which the origin server intends that an entity should
no longer be returned by a cache without further validation.
heuristic expiration time
An expiration time assigned by a cache when no explicit expiration
time is available.
age
The age of a response is the time since it was sent by, or
successfully validated with, the origin server.
freshness lifetime
The length of time between the generation of a response and its
expiration time.
fresh
A response is fresh if its age has not yet exceeded its freshness
lifetime.
stale
A response is stale if its age has passed its freshness lifetime.
semantically transparent
A cache behaves in a "semantically transparent" manner, with
respect to a particular response, when its use affects neither the
requesting client nor the origin server, except to improve
performance. When a cache is semantically transparent, the client
receives exactly the same response (except for hop-by-hop headers)
that it would have received had its request been handled directly
by the origin server.
validator
A protocol element (e.g., an entity tag or a Last-Modified time)
that is used to find out whether a cache entry is an equivalent
copy of an entity.
upstream/downstream upstream/downstream
Upstream and downstream describe the flow of a message: all Upstream and downstream describe the flow of a message: all
messages flow from upstream to downstream. messages flow from upstream to downstream.
inbound/outbound inbound/outbound
Inbound and outbound refer to the request and response paths for Inbound and outbound refer to the request and response paths for
messages: "inbound" means "traveling toward the origin server", messages: "inbound" means "traveling toward the origin server",
and "outbound" means "traveling toward the user agent" and "outbound" means "traveling toward the user agent"
skipping to change at page 13, line 27 skipping to change at page 8, line 29
1.4. Overall Operation 1.4. Overall Operation
The HTTP protocol is a request/response protocol. A client sends a The HTTP protocol is a request/response protocol. A client sends a
request to the server in the form of a request method, URI, and request to the server in the form of a request method, URI, and
protocol version, followed by a MIME-like message containing request protocol version, followed by a MIME-like message containing request
modifiers, client information, and possible body content over a modifiers, client information, and possible body content over a
connection with a server. The server responds with a status line, connection with a server. The server responds with a status line,
including the message's protocol version and a success or error code, including the message's protocol version and a success or error code,
followed by a MIME-like message containing server information, entity followed by a MIME-like message containing server information, entity
metainformation, and possible entity-body content. The relationship metainformation, and possible entity-body content. The relationship
between HTTP and MIME is described in Appendix A.4. between HTTP and MIME is described in [Part 3].
Most HTTP communication is initiated by a user agent and consists of Most HTTP communication is initiated by a user agent and consists of
a request to be applied to a resource on some origin server. In the a request to be applied to a resource on some origin server. In the
simplest case, this may be accomplished via a single connection (v) simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O). between the user agent (UA) and the origin server (O).
request chain ------------------------> request chain ------------------------>
UA -------------------v------------------- O UA -------------------v------------------- O
<----------------------- response chain <----------------------- response chain
skipping to change at page 14, line 36 skipping to change at page 9, line 37
cached copy of an earlier response from O (via C) for a request which cached copy of an earlier response from O (via C) for a request which
has not been cached by UA or A. has not been cached by UA or A.
request chain ----------> request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain <--------- response chain
Not all responses are usefully cacheable, and some requests may Not all responses are usefully cacheable, and some requests may
contain modifiers which place special requirements on cache behavior. contain modifiers which place special requirements on cache behavior.
HTTP requirements for cache behavior and cacheable responses are HTTP requirements for cache behavior and cacheable responses are
defined in Section 13. defined in [Part 6].
In fact, there are a wide variety of architectures and configurations In fact, there are a wide variety of architectures and configurations
of caches and proxies currently being experimented with or deployed of caches and proxies currently being experimented with or deployed
across the World Wide Web. These systems include national hierarchies across the World Wide Web. These systems include national hierarchies
of proxy caches to save transoceanic bandwidth, systems that of proxy caches to save transoceanic bandwidth, systems that
broadcast or multicast cache entries, organizations that distribute broadcast or multicast cache entries, organizations that distribute
subsets of cached data via CD-ROM, and so on. HTTP systems are used subsets of cached data via CD-ROM, and so on. HTTP systems are used
in corporate intranets over high-bandwidth links, and for access via in corporate intranets over high-bandwidth links, and for access via
PDAs with low-power radio links and intermittent connectivity. The PDAs with low-power radio links and intermittent connectivity. The
goal of HTTP/1.1 is to support the wide diversity of configurations goal of HTTP/1.1 is to support the wide diversity of configurations
already deployed while introducing protocol constructs that meet the already deployed while introducing protocol constructs that meet the
needs of those who build web applications that require high needs of those who build web applications that require high
reliability and, failing that, at least reliable indications of reliability and, failing that, at least reliable indications of
failure. failure.
HTTP communication usually takes place over TCP/IP connections. The HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does default port is TCP 80 [16], but other ports can be used. This does
not preclude HTTP from being implemented on top of any other protocol not preclude HTTP from being implemented on top of any other protocol
on the Internet, or on other networks. HTTP only presumes a reliable on the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used; transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the the mapping of the HTTP/1.1 request and response structures onto the
transport data units of the protocol in question is outside the scope transport data units of the protocol in question is outside the scope
of this specification. of this specification.
In HTTP/1.0, most implementations used a new connection for each In HTTP/1.0, most implementations used a new connection for each
request/response exchange. In HTTP/1.1, a connection may be used for request/response exchange. In HTTP/1.1, a connection may be used for
one or more request/response exchanges, although connections may be one or more request/response exchanges, although connections may be
closed for a variety of reasons (see Section 8.1). closed for a variety of reasons (see Section 7.1).
2. Notational Conventions and Generic Grammar 2. Notational Conventions and Generic Grammar
2.1. Augmented BNF 2.1. Augmented BNF
All of the mechanisms specified in this document are described in All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) similar to that both prose and an augmented Backus-Naur Form (BNF) similar to that
used by RFC 822 [9]. Implementors will need to be familiar with the used by RFC 822 [7]. Implementors will need to be familiar with the
notation in order to understand this specification. The augmented notation in order to understand this specification. The augmented
BNF includes the following constructs: BNF includes the following constructs:
name = definition name = definition
The name of a rule is simply the name itself (without any The name of a rule is simply the name itself (without any
enclosing "<" and ">") and is separated from its definition by the enclosing "<" and ">") and is separated from its definition by the
equal "=" character. White space is only significant in that equal "=" character. White space is only significant in that
indentation of continuation lines is used to indicate a rule indentation of continuation lines is used to indicate a rule
definition that spans more than one line. Certain basic rules are definition that spans more than one line. Certain basic rules are
skipping to change at page 18, line 11 skipping to change at page 12, line 24
between adjacent words and separators, without changing the between adjacent words and separators, without changing the
interpretation of a field. At least one delimiter (LWS and/or interpretation of a field. At least one delimiter (LWS and/or
separators) MUST exist between any two tokens (for the definition separators) MUST exist between any two tokens (for the definition
of "token" below), since they would otherwise be interpreted as a of "token" below), since they would otherwise be interpreted as a
single token. single token.
2.2. Basic Rules 2.2. Basic Rules
The following rules are used throughout this specification to The following rules are used throughout this specification to
describe basic parsing constructs. The US-ASCII coded character set describe basic parsing constructs. The US-ASCII coded character set
is defined by ANSI X3.4-1986 [21]. is defined by ANSI X3.4-1986 [18].
OCTET = <any 8-bit sequence of data> OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)> CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z"> LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9"> DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)> (octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)> CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)> LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)> SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)> HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <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 A.3 for protocol elements except the entity-body (see Appendix B for tolerant
tolerant applications). The end-of-line marker within an entity-body applications). The end-of-line marker within an entity-body is
is defined by its associated media type, as described in Section 3.7. defined by its associated media type, as described in [Part 3].
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
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
LWS = [CRLF] 1*( SP | HT ) LWS = [CRLF] 1*( SP | HT )
The TEXT rule is only used for descriptive field contents and values The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO- of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047 8859-1 [19] only when encoded according to the rules of RFC 2047
[14]. [12].
TEXT = <any OCTET except CTLs, TEXT = <any OCTET except CTLs,
but including LWS> 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" HEX = "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.6). Section 3.4).
token = 1*<any CHAR except CTLs or separators> token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@" separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <"> | "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "=" | "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT | "{" | "}" | SP | HT
Comments can be included in some HTTP header fields by surrounding Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition. fields containing "comment" as part of their field value definition.
skipping to change at page 20, line 21 skipping to change at page 14, line 23
the sender to indicate the format of a message and its capacity for the sender to indicate the format of a message and its capacity for
understanding further HTTP communication, rather than the features understanding further HTTP communication, rather than the features
obtained via that communication. No change is made to the version obtained via that communication. No change is made to the version
number for the addition of message components which do not affect number for the addition of message components which do not affect
communication behavior or which only add to extensible field values. communication behavior or which only add to extensible field values.
The <minor> number is incremented when the changes made to the The <minor> number is incremented when the changes made to the
protocol add features which do not change the general message parsing protocol add features which do not change the general message parsing
algorithm, but which may add to the message semantics and imply algorithm, but which may add to the message semantics and imply
additional capabilities of the sender. The <major> number is additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is incremented when the format of a message within the protocol is
changed. See RFC 2145 [36] for a fuller explanation. changed. See RFC 2145 [27] for a fuller explanation.
The version of an HTTP message is indicated by an HTTP-Version field The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message. in the first line of the message. HTTP-Version is case-sensitive.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers MUST be treated as separate Note that the major and minor numbers MUST be treated as separate
integers and that each MAY be incremented higher than a single digit. integers and that each MAY be incremented higher than a single digit.
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
and MUST NOT be sent. and MUST NOT be sent.
An application that sends a request or response message that includes An application that sends a request or response message that includes
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
with this specification. Applications that are at least with this specification. Applications that are at least
conditionally compliant with this specification SHOULD use an HTTP- conditionally compliant with this specification SHOULD use an HTTP-
Version of "HTTP/1.1" in their messages, and MUST do so for any Version of "HTTP/1.1" in their messages, and MUST do so for any
message that is not compatible with HTTP/1.0. For more details on message that is not compatible with HTTP/1.0. For more details on
when to send specific HTTP-Version values, see RFC 2145 [36]. when to send specific HTTP-Version values, see RFC 2145 [27].
The HTTP version of an application is the highest HTTP version for The HTTP version of an application is the highest HTTP version for
which the application is at least conditionally compliant. which the application is at least conditionally compliant.
Proxy and gateway applications need to be careful when forwarding Proxy and gateway applications need to be careful when forwarding
messages in protocol versions different from that of the application. messages in protocol versions different from that of the application.
Since the protocol version indicates the protocol capability of the Since the protocol version indicates the protocol capability of the
sender, a proxy/gateway MUST NOT send a message with a version sender, a proxy/gateway MUST NOT send a message with a version
indicator which is greater than its actual version. If a higher indicator which is greater than its actual version. If a higher
version request is received, the proxy/gateway MUST either downgrade version request is received, the proxy/gateway MUST either downgrade
the request version, or respond with an error, or switch to tunnel the request version, or respond with an error, or switch to tunnel
behavior. behavior.
Due to interoperability problems with HTTP/1.0 proxies discovered Due to interoperability problems with HTTP/1.0 proxies discovered
since the publication of RFC 2068 [33], caching proxies MUST, since the publication of RFC 2068 [25], caching proxies MUST,
gateways MAY, and tunnels MUST NOT upgrade the request to the highest gateways MAY, and tunnels MUST NOT upgrade the request to the highest
version they support. The proxy/gateway's response to that request version they support. The proxy/gateway's response to that request
MUST be in the same major version as the request. MUST be in the same major version as the request.
Note: Converting between versions of HTTP may involve modification Note: Converting between versions of HTTP may involve modification
of header fields required or forbidden by the versions involved. of header fields required or forbidden by the versions involved.
3.2. Uniform Resource Identifiers 3.2. Uniform Resource Identifiers
URIs have been known by many names: WWW addresses, Universal Document URIs have been known by many names: WWW addresses, Universal Document
Identifiers, Universal Resource Identifiers [3], and finally the Identifiers, Universal Resource Identifiers [2], and finally the
combination of Uniform Resource Locators (URL) [4] and Names (URN) combination of Uniform Resource Locators (URL) [3] and Names (URN)
[20]. As far as HTTP is concerned, Uniform Resource Identifiers are [17]. As far as HTTP is concerned, Uniform Resource Identifiers are
simply formatted strings which identify--via name, location, or any simply formatted strings which identify--via name, location, or any
other characteristic--a resource. other characteristic--a resource.
3.2.1. General Syntax 3.2.1. General Syntax
URIs in HTTP can be represented in absolute form or relative to some URIs in HTTP can be represented in absolute form or relative to some
known base URI [11], depending upon the context of their use. The known base URI [9], depending upon the context of their use. The two
two forms are differentiated by the fact that absolute URIs always forms are differentiated by the fact that absolute URIs always begin
begin with a scheme name followed by a colon. For definitive with a scheme name followed by a colon. For definitive information
information on URL syntax and semantics, see "Uniform Resource on URL syntax and semantics, see "Uniform Resource Identifiers (URI):
Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] Generic Syntax and Semantics," RFC 2396 [29] (which replaces RFCs
(which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification 1738 [3] and RFC 1808 [9]). This specification adopts the
adopts the definitions of "URI-reference", "absoluteURI", definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
"relativeURI", "port", "host","abs_path", "rel_path", and "authority" "host","abs_path", "rel_path", and "authority" from that
from that specification. specification.
The HTTP protocol does not place any a priori limit on the length of The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see Section 10.4.15). than the server can handle (see [Part 2]).
Note: Servers ought to be cautious about depending on URI lengths Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy above 255 bytes, because some older client or proxy
implementations might not properly support these lengths. implementations might not properly support these lengths.
3.2.2. http URL 3.2.2. http URL
The "http" scheme is used to locate network resources via the HTTP The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and protocol. This section defines the scheme-specific syntax and
semantics for http URLs. semantics for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The semantics If the port is empty or not given, port 80 is assumed. The semantics
are that the identified resource is located at the server listening are that the identified resource is located at the server listening
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 abs_path (Section 5.1.2). The use of IP for the resource is abs_path (Section 5.1.2). The use of IP
addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 addresses in URLs SHOULD be avoided whenever possible (see RFC 1900
[24]). If the abs_path is not present in the URL, it MUST be given [20]). If the abs_path is not present in the URL, it MUST be given
as "/" when used as a Request-URI for a resource (Section 5.1.2). If 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 fully qualified domain a proxy receives a host name which is not a fully qualified domain
name, it MAY add its domain to the host name it received. If a proxy name, it MAY add its domain to the host name it received. If a proxy
receives a fully qualified domain name, the proxy MUST NOT change the receives a fully qualified domain name, the proxy MUST NOT change the
host name. host name.
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
skipping to change at page 22, line 34 skipping to change at page 16, line 40
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 abs_path is equivalent to an abs_path of "/". o An empty abs_path is equivalent to an abs_path of "/".
Characters other than those in the "reserved" and "unsafe" sets (see Characters other than those in the "reserved" set (see RFC 2396 [29])
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. are equivalent to their ""%" HEX HEX" encoding.
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://abc.com:80/~smith/home.html http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html http://ABC.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 23, line 4 skipping to change at page 17, line 15
3.3. Date/Time Formats 3.3. Date/Time Formats
3.3.1. Full Date 3.3.1. Full Date
HTTP applications have historically allowed three different formats HTTP applications have historically allowed three different formats
for the representation of date/time stamps: for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
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 RFC 1123 [8] (an update to a fixed-length subset of that defined by RFC 1123 [6] (an update to
RFC 822 [9]). The second format is in common use, but is based on RFC 822 [7]). The second format is in common use, but is based on
the obsolete RFC 850 [12] date format and lacks a four-digit year. the obsolete RFC 850 [10] date format and lacks a four-digit year.
HTTP/1.1 clients and servers that parse the date value MUST accept HTTP/1.1 clients and servers that parse the date value MUST accept
all three formats (for compatibility with HTTP/1.0), though they MUST all three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123 format for representing HTTP-date values only generate the RFC 1123 format for representing HTTP-date values
in header fields. See Appendix A.3 for further information. in header fields. See Appendix B 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
skipping to change at page 24, line 5 skipping to change at page 18, line 30
| "Thursday" | "Friday" | "Saturday" | "Sunday" | "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr" month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug" | "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec" | "Sep" | "Oct" | "Nov" | "Dec"
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.3.2. Delta Seconds 3.4. Transfer Codings
Some HTTP header fields allow a time value to be specified as an
integer number of seconds, represented in decimal, after the time
that the message was received.
delta-seconds = 1*DIGIT
3.4. Character Sets
HTTP uses the same definition of the term "character set" as that
described for MIME:
The term "character set" is used in this document to refer to a
method used with one or more tables to convert a sequence of octets
into a sequence of characters. Note that unconditional conversion in
the other direction is not required, in that not all characters may
be available in a given character set and a character set may provide
more than one sequence of octets to represent a particular character.
This definition is intended to allow various kinds of character
encoding, from simple single-table mappings such as US-ASCII to
complex table switching methods such as those that use ISO-2022's
techniques. However, the definition associated with a MIME character
set name MUST fully specify the mapping to be performed from octets
to characters. In particular, use of external profiling information
to determine the exact mapping is not permitted.
Note: This use of the term "character set" is more commonly
referred to as a "character encoding." However, since HTTP and
MIME share the same registry, it is important that the terminology
also be shared.
HTTP character sets are identified by case-insensitive tokens. The
complete set of tokens is defined by the IANA Character Set registry
[19].
charset = token
Although HTTP allows an arbitrary token to be used as a charset
value, any token that has a predefined value within the IANA
Character Set registry [19] MUST represent the character set defined
by that registry. Applications SHOULD limit their use of character
sets to those defined by the IANA registry.
Implementors should be aware of IETF character set requirements [38]
[41].
3.4.1. Missing Charset
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document. See
Section 3.7.1.
3.5. Content Codings
Content coding values indicate an encoding transformation that has
been or can be applied to an entity. Content codings are primarily
used to allow a document to be compressed or otherwise usefully
transformed without losing the identity of its underlying media type
and without loss of information. Frequently, the entity is stored in
coded form, transmitted directly, and only decoded by the recipient.
content-coding = token
All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding values in the Accept-Encoding (Section 14.3) and
Content-Encoding (Section 14.11) header fields. Although the value
describes the content-coding, what is more important is that it
indicates what decoding mechanism will be required to remove the
encoding.
The Internet Assigned Numbers Authority (IANA) acts as a registry for
content-coding value tokens. Initially, the registry contains the
following tokens:
gzip
An encoding format produced by the file compression program "gzip"
(GNU zip) as described in RFC 1952 [25]. This format is a Lempel-
Ziv coding (LZ77) with a 32 bit CRC.
compress
The encoding format produced by the common UNIX file compression
program "compress". This format is an adaptive Lempel-Ziv-Welch
coding (LZW).
Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. Their use
here is representative of historical practice, not good design.
For compatibility with previous implementations of HTTP,
applications SHOULD consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively.
deflate
The "zlib" format defined in RFC 1950 [31] in combination with the
"deflate" compression mechanism described in RFC 1951 [29].
identity
The default (identity) encoding; the use of no transformation
whatsoever. This content-coding is used only in the Accept-
Encoding header, and SHOULD NOT be used in the Content-Encoding
header.
New content-coding value tokens SHOULD be registered; to allow
interoperability between clients and servers, specifications of the
content coding algorithms needed to implement a new value SHOULD be
publicly available and adequate for independent implementation, and
conform to the purpose of content coding defined in this section.
3.6. Transfer Codings
Transfer-coding values are used to indicate an encoding Transfer-coding values are used to indicate an encoding
transformation that has been, can be, or may need to be applied to an transformation that has been, can be, or may need to be applied to an
entity-body in order to ensure "safe transport" through the network. entity-body in order to ensure "safe transport" through the network.
This differs from a content coding in that the transfer-coding is a This differs from a content coding in that the transfer-coding is a
property of the message, not of the original entity. property of the message, not of the original entity.
transfer-coding = "chunked" | transfer-extension transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" 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 14.39) and in transfer-coding values in the TE header field (Section 8.5) and in
the Transfer-Encoding header field (Section 14.41). 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 is
terminated by closing the connection. When the "chunked" transfer- terminated by closing the connection. When the "chunked" transfer-
coding is used, it MUST be the last transfer-coding applied to the coding is used, it MUST be the last transfer-coding applied to the
message-body. The "chunked" transfer-coding MUST NOT be applied more message-body. The "chunked" transfer-coding MUST NOT be applied more
than once to a message-body. These rules allow the recipient to than once to a message-body. These rules allow the recipient to
determine the transfer-length of the message (Section 4.4). 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 [7], which were designed to enable safe transport of values of MIME [5], which were designed to enable safe transport of
binary data over a 7-bit transport service. However, safe transport binary data over a 7-bit transport service. However, safe transport
has a different focus for an 8bit-clean transfer protocol. In HTTP, has a different focus for an 8bit-clean transfer protocol. In HTTP,
the only unsafe characteristic of message-bodies is the difficulty in the only unsafe characteristic of message-bodies is the difficulty in
determining the exact body length (Section 7.2.2), or the desire to determining the exact body length (Section 4.4), or the desire to
encrypt data over a shared transport. 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
transfer-coding value tokens. Initially, the registry contains the transfer-coding value tokens. Initially, the registry contains the
following tokens: "chunked" (Section 3.6.1), "identity" (section following tokens: "chunked" (Section 3.4.1), "identity" (section
3.6.2), "gzip" (Section 3.5), "compress" (Section 3.5), and "deflate" 3.6.2), "gzip" ([Part 3]), "compress" ([Part 3]), and "deflate"
(Section 3.5). ([Part 3]).
New transfer-coding value tokens SHOULD be registered in the same way New transfer-coding value tokens SHOULD be registered in the same way
as new content-coding value tokens (Section 3.5). as new content-coding value tokens ([Part 3]).
A server which receives an entity-body with a transfer-coding it does A server which receives an entity-body with a transfer-coding it does
not understand SHOULD return 501 (Unimplemented), and close the not understand SHOULD return 501 (Unimplemented), and close the
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 connection. A server MUST NOT send transfer-codings to an HTTP/1.0
client. client.
3.6.1. Chunked Transfer Coding 3.4.1. Chunked Transfer Coding
The chunked encoding modifies the body of a message in order to The chunked encoding modifies the body of a message in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing entity-header fields. followed by an OPTIONAL trailer containing entity-header fields.
This allows dynamically produced content to be transferred along with This allows dynamically produced content to be transferred along with
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
skipping to change at page 28, line 22 skipping to change at page 20, line 22
chunk-size = 1*HEX chunk-size = 1*HEX
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 = chunk-size(OCTET) chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF) trailer = *(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. The chunked encoding is ended by any chunk whose size is the chunk-data in octets. The chunked encoding is ended by any chunk
zero, followed by the trailer, which is terminated by an empty line. whose size is zero, followed by the trailer, which is terminated by
an empty line.
The trailer allows the sender to include additional HTTP header The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be fields at the end of the message. The Trailer header field can be
used to indicate which header fields are included in a trailer (see used to indicate which header fields are included in a trailer (see
Section 14.40). Section 8.6).
A server using chunked transfer-coding in a response MUST NOT use the A server using chunked transfer-coding in a response MUST NOT use the
trailer for any header fields unless at least one of the following is trailer for any header fields unless at least one of the following is
true: true:
1. the request included a TE header field that indicates "trailers" 1. the request included a TE header field that indicates "trailers"
is acceptable in the transfer-coding of the response, as is acceptable in the transfer-coding of the response, as
described in Section 14.39; or, described in Section 8.5; or,
2. the server is the origin server for the response, the trailer 2. the server is the origin server for the response, the trailer
fields consist entirely of optional metadata, and the recipient fields consist entirely of optional metadata, and the recipient
could use the message (in a manner acceptable to the origin could use the message (in a manner acceptable to the origin
server) without receiving this metadata. In other words, the server) without receiving this metadata. In other words, the
origin server is willing to accept the possibility that the origin server is willing to accept the possibility that the
trailer fields might be silently discarded along the path to the trailer fields might be silently discarded along the path to the
client. client.
This requirement prevents an interoperability failure when the This requirement prevents an interoperability failure when the
message is being received by an HTTP/1.1 (or later) proxy and message is being received by an HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 recipient. It avoids a situation where forwarded to an HTTP/1.0 recipient. It avoids a situation where
compliance with the protocol would have necessitated a possibly compliance with the protocol would have necessitated a possibly
infinite buffer on the proxy. infinite buffer on the proxy.
An example process for decoding a Chunked-Body is presented in A process for decoding the "chunked" transfer-coding can be
Appendix A.4.6. represented in pseudo-code as:
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
All HTTP/1.1 applications MUST be able to receive and decode the All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding, and MUST ignore chunk-extension extensions "chunked" transfer-coding, and MUST ignore chunk-extension extensions
they do not understand. they do not understand.
3.7. Media Types
HTTP uses Internet Media Types [17] in the Content-Type
(Section 14.17) and Accept (Section 14.1) header fields in order to
provide open and extensible data typing and type negotiation.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Parameters MAY follow the type/subtype in the form of attribute/value
pairs (as defined in Section 3.6).
The type, subtype, and parameter attribute names are case-
insensitive. Parameter values might or might not be case-sensitive,
depending on the semantics of the parameter name. Linear white space
(LWS) MUST NOT be used between the type and subtype, nor between an
attribute and its value. The presence or absence of a parameter
might be significant to the processing of a media-type, depending on
its definition within the media type registry.
Note that some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
implementations SHOULD only use media type parameters when they are
required by that type/subtype definition.
Media-type values are registered with the Internet Assigned Number
Authority (IANA [19]). The media type registration process is
outlined in RFC 1590 [17]. Use of non-registered media types is
discouraged.
3.7.1. Canonicalization and Text Defaults
Internet media types are registered with a canonical form. An
entity-body transferred via HTTP messages MUST be represented in the
appropriate canonical form prior to its transmission except for
"text" types, as defined in the next paragraph.
When in canonical form, media subtypes of the "text" type use CRLF as
the text line break. HTTP relaxes this requirement and allows the
transport of text media with plain CR or LF alone representing a line
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF, bare CR, and bare LF as being
representative of a line break in text media received via HTTP. In
addition, if the text is represented in a character set that does not
use octets 13 and 10 for CR and LF respectively, as is the case for
some multi-byte character sets, HTTP allows the use of whatever octet
sequences are defined by that character set to represent the
equivalent of CR and LF for line breaks. This flexibility regarding
line breaks applies only to text media in the entity-body; a bare CR
or LF MUST NOT be substituted for CRLF within any of the HTTP control
structures (such as header fields and multipart boundaries).
If an entity-body is encoded with a content-coding, the underlying
data MUST be in a form defined above prior to being encoded.
The "charset" parameter is used with some media types to define the
character set (Section 3.4) of the data. When no explicit charset
parameter is provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "ISO-8859-1" or
its subsets MUST be labeled with an appropriate charset value. See
Section 3.4.1 for compatibility problems.
3.7.2. Multipart Types
MIME provides for a number of "multipart" types -- encapsulations of
one or more entities within a single message-body. All multipart
types share a common syntax, as defined in section 5.1.1 of RFC 2046
[40], and MUST include a boundary parameter as part of the media type
value. The message body is itself a protocol element and MUST
therefore use only CRLF to represent line breaks between body-parts.
Unlike in RFC 2046, the epilogue of any multipart message MUST be
empty; HTTP applications MUST NOT transmit the epilogue (even if the
original multipart contains an epilogue). These restrictions exist
in order to preserve the self-delimiting nature of a multipart
message-body, wherein the "end" of the message-body is indicated by
the ending multipart boundary.
In general, HTTP treats a multipart message-body no differently than
any other media type: strictly as payload. The one exception is the
"multipart/byteranges" type (Appendix A.2) when it appears in a 206
(Partial Content) response, which will be interpreted by some HTTP
caching mechanisms as described in sections 13.5.4 and 14.16. In all
other cases, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME user agent would upon receipt of a multipart type.
The MIME header fields within each body-part of a multipart message-
body do not have any significance to HTTP beyond that defined by
their MIME semantics.
In general, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME user agent would upon receipt of a multipart type.
If an application receives an unrecognized multipart subtype, the
application MUST treat it as being equivalent to "multipart/mixed".
Note: The "multipart/form-data" type has been specifically defined
for carrying form data suitable for processing via the POST
request method, as described in RFC 1867 [15].
3.8. Product Tokens
Product tokens are used to allow communicating applications to
identify themselves by software name and version. Most fields using
product tokens also allow sub-products which form a significant part
of the application to be listed, separated by white space. By
convention, the products are listed in order of their significance
for identifying the application.
product = token ["/" product-version]
product-version = token
Examples:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Product tokens SHOULD be short and to the point. They MUST NOT be
used for advertising or other non-essential information. Although
any token character MAY appear in a product-version, this token
SHOULD only be used for a version identifier (i.e., successive
versions of the same product SHOULD only differ in the product-
version portion of the product value).
3.9. Quality Values
HTTP content negotiation (Section 12) uses short "floating point"
numbers to indicate the relative importance ("weight") of various
negotiable parameters. A weight is normalized to a real number in
the range 0 through 1, where 0 is the minimum and 1 the maximum
value. If a parameter has a quality value of 0, then content with
this parameter is `not acceptable' for the client. HTTP/1.1
applications MUST NOT generate more than three digits after the
decimal point. User configuration of these values SHOULD also be
limited in this fashion.
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
"Quality values" is a misnomer, since these values merely represent
relative degradation in desired quality.
3.10. Language Tags
A language tag identifies a natural language spoken, written, or
otherwise conveyed by human beings for communication of information
to other human beings. Computer languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content-
Language fields.
The syntax and registry of HTTP language tags is the same as that
defined by RFC 1766 [1]. In summary, a language tag is composed of 1
or more parts: A primary language tag and a possibly empty series of
subtags:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
White space is not allowed within the tag and all tags are case-
insensitive. The name space of language tags is administered by the
IANA. Example tags include:
en, en-US, en-cockney, i-cherokee, x-pig-latin
where any two-letter primary-tag is an ISO-639 language abbreviation
and any two-letter initial subtag is an ISO-3166 country code. (The
last three tags above are not registered tags; all but the last are
examples of tags which could be registered in future.)
3.11. Entity Tags
Entity tags are used for comparing two or more entities from the same
requested resource. HTTP/1.1 uses entity tags in the ETag
(Section 14.19), If-Match (Section 14.24), If-None-Match
(Section 14.26), and If-Range (Section 14.27) header fields. The
definition of how they are used and compared as cache validators is
in Section 13.3.3. An entity tag consists of an opaque quoted
string, possibly prefixed by a weakness indicator.
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
A "strong entity tag" MAY be shared by two entities of a resource
only if they are equivalent by octet equality.
A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
two entities of a resource only if the entities are equivalent and
could be substituted for each other with no significant change in
semantics. A weak entity tag can only be used for weak comparison.
An entity tag MUST be unique across all versions of all entities
associated with a particular resource. A given entity tag value MAY
be used for entities obtained by requests on different URIs. The use
of the same entity tag value in conjunction with entities obtained by
requests on different URIs does not imply the equivalence of those
entities.
3.12. Range Units
HTTP/1.1 allows a client to request that only part (a range of) the
response entity be included within the response. HTTP/1.1 uses range
units in the Range (Section 14.35) and Content-Range (Section 14.16)
header fields. An entity can be broken down into subranges according
to various structural units.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
implementations MAY ignore ranges specified using other units.
HTTP/1.1 has been designed to allow implementations of applications
that do not depend on knowledge of ranges.
4. HTTP Message 4. HTTP Message
4.1. Message Types 4.1. Message Types
HTTP messages consist of requests from client to server and responses HTTP messages consist of requests from client to server and responses
from server to client. from server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages HTTP-message = Request | Response ; HTTP/1.1 messages
Request (Section 5) and Response (Section 6) messages use the generic Request (Section 5) and Response (Section 6) messages use the generic
message format of RFC 822 [9] for transferring entities (the payload message format of RFC 822 [7] for transferring entities (the payload
of the message). Both types of message consist of a start-line, zero of the message). Both types of message consist of a start-line, zero
or more header fields (also known as "headers"), an empty line (i.e., or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF) indicating the end of the a line with nothing preceding the CRLF) indicating the end of the
header fields, and possibly a message-body. header fields, and possibly a message-body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body ] [ message-body ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
skipping to change at page 34, line 40 skipping to change at page 22, line 15
message and receives a CRLF first, it should ignore the CRLF. message and receives a CRLF first, it should ignore the CRLF.
Certain buggy HTTP/1.0 client implementations generate extra CRLF's Certain buggy HTTP/1.0 client implementations generate extra CRLF's
after a POST request. To restate what is explicitly forbidden by the after a POST request. To restate what is explicitly forbidden by the
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
extra CRLF. extra CRLF.
4.2. Message Headers 4.2. Message Headers
HTTP header fields, which include general-header (Section 4.5), HTTP header fields, which include general-header (Section 4.5),
request-header (Section 5.3), response-header (Section 6.2), and request-header ([Part 2]), response-header ([Part 2]), and entity-
entity-header (Section 7.1) fields, follow the same generic format as header ([Part 3]) fields, follow the same generic format as that
that given in Section 3.1 of RFC 822 [9]. Each header field consists given in Section 3.1 of RFC 822 [7]. Each header field consists of a
of a name followed by a colon (":") and the field value. Field names name followed by a colon (":") and the field value. Field names are
are case-insensitive. The field value MAY be preceded by any amount case-insensitive. The field value MAY be preceded by any amount of
of LWS, though a single SP is preferred. Header fields can be LWS, though a single SP is preferred. Header fields can be extended
extended over multiple lines by preceding each extra line with at over multiple lines by preceding each extra line with at least one SP
least one SP or HT. Applications ought to follow "common form", or HT. Applications ought to follow "common form", where one is
where one is known or indicated, when generating HTTP constructs, known or indicated, when generating HTTP constructs, since there
since there might exist some implementations that fail to accept might exist some implementations that fail to accept anything beyond
anything beyond the common forms. the common forms.
message-header = field-name ":" [ field-value ] message-header = field-name ":" [ field-value ]
field-name = token field-name = token
field-value = *( field-content | LWS ) field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations and consisting of either *TEXT or combinations
of token, separators, and quoted-string> of token, separators, and quoted-string>
The field-content does not include any leading or trailing LWS: The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace linear white space occurring before the first non-whitespace
skipping to change at page 35, line 43 skipping to change at page 23, line 17
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.
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 14.41). (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>
Transfer-Encoding MUST be used to indicate any transfer-codings Transfer-Encoding MUST be used to indicate any transfer-codings
applied by an application to ensure safe and proper transfer of the applied by an application to ensure safe and proper transfer of the
message. Transfer-Encoding is a property of the message, not of the message. Transfer-Encoding is a property of the message, not of the
entity, and thus MAY be added or removed by any application along the entity, and thus MAY be added or removed by any application along the
request/response chain. (However, Section 3.6 places restrictions on request/response chain. (However, Section 3.4 places restrictions on
when certain transfer-codings may be used.) when certain transfer-codings may be used.)
The rules for when a message-body is allowed in a message differ for The rules for when a message-body is allowed in a message differ for
requests and responses. requests and responses.
The presence of a message-body in a request is signaled by the The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included the request's message-headers. A message-body MUST NOT be included
in a request if the specification of the request method in a request if the specification of the request method ([Part 2])
(Section 5.1.1) does not allow sending an entity-body in requests. A does not allow sending an entity-body in requests. A server SHOULD
server SHOULD read and forward a message-body on any request; if the read and forward a message-body on any request; if the request method
request method does not include defined semantics for an entity-body, does not include defined semantics for an entity-body, then the
then the message-body SHOULD be ignored when handling the request. message-body SHOULD be ignored when handling the request.
For response messages, whether or not a message-body is included with For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response a message is dependent on both the request method and the response
status code (Section 6.1.1). All responses to the HEAD request status code (Section 6.1.1). All responses to the HEAD request
method MUST NOT include a message-body, even though the presence of method MUST NOT include a message-body, even though the presence of
entity-header fields might lead one to believe they do. All 1xx entity-header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses (informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body. All other responses do include a MUST NOT include a message-body. All other responses do include a
message-body, although it MAY be of zero length. message-body, although it MAY be of zero length.
skipping to change at page 36, line 41 skipping to change at page 24, line 19
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 14.41) is present 2. If a Transfer-Encoding header field (Section 8.7) is present and
and has any value other than "identity", then the transfer-length has any value other than "identity", then the transfer-length is
is defined by use of the "chunked" transfer-coding (Section 3.6), defined by use of the "chunked" transfer-coding (Section 3.4),
unless the message is terminated by closing the connection. unless the message is terminated by closing the connection.
3. If a Content-Length header field (Section 14.13) 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
the ransfer-length is not otherwise specified, then this self- the transfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length. This media delimiting media type defines the transfer-length. This media
type UST NOT be used unless the sender knows that the recipient type MUST NOT be used unless the sender knows that the recipient
can arse it; the presence in a request of a Range header with can parse it; the presence in a request of a Range header with
ultiple byte-range specifiers from a 1.1 client implies that the multiple byte-range specifiers from a 1.1 client implies that the
lient can parse multipart/byteranges responses. client can parse multipart/byteranges responses.
A range header might be forwarded by a 1.0 proxy that does not A range header might be forwarded by a 1.0 proxy that does not
understand multipart/byteranges; in this case the server MUST understand multipart/byteranges; in this case the server MUST
delimit the message using methods defined in items 1, 3 or 5 delimit the message using methods defined in items 1, 3 or 5
of this section. of this section.
5. By the server closing the connection. (Closing the connection 5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that cannot be used to indicate the end of a request body, since that
would leave no possibility for the server to send back a would leave no possibility for the server to send back a
response.) response.)
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include a valid Content-Length header containing a message-body MUST include a valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body and a Content-Length is not given, request contains a message-body and a Content-Length is not given,
the server SHOULD respond with 400 (bad request) if it cannot the server SHOULD respond with 400 (bad request) if it cannot
determine the length of the message, or with 411 (length required) if determine the length of the message, or with 411 (length required) if
it wishes to insist on receiving a valid Content-Length. it wishes to insist on receiving a valid Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the All HTTP/1.1 applications that receive entities MUST accept the
"chunked" transfer-coding (Section 3.6), thus allowing this mechanism "chunked" transfer-coding (Section 3.4), thus allowing this mechanism
to be used for messages when the message length cannot be determined to be used for messages when the message length cannot be determined
in advance. in advance.
Messages MUST NOT include both a Content-Length header field and a Messages MUST NOT include both a Content-Length header field and a
non-identity transfer-coding. If the message does include a non- non-identity transfer-coding. If the message does include a non-
identity transfer-coding, the Content-Length MUST be ignored. identity transfer-coding, the Content-Length MUST be ignored.
When a Content-Length is given in a message where a message-body is When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected. invalid length is received and detected.
4.5. General Header Fields 4.5. General Header Fields
There are a few header fields which have general applicability for There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the both request and response messages, but which do not apply to the
entity being transferred. These header fields apply only to the entity being transferred. These header fields apply only to the
message being transmitted. message being transmitted.
general-header = Cache-Control ; Section 14.9 general-header = Cache-Control ; [Part 6]
| Connection ; Section 14.10 | Connection ; Section 8.1
| Date ; Section 14.18 | Date ; Section 8.3
| Pragma ; Section 14.32 | Pragma ; [Part 6]
| Trailer ; Section 14.40 | Trailer ; Section 8.6
| Transfer-Encoding ; Section 14.41 | Transfer-Encoding ; Section 8.7
| Upgrade ; Section 14.42 | Upgrade ; Section 8.8
| Via ; Section 14.45 | Via ; Section 8.9
| Warning ; Section 14.46 | Warning ; [Part 6]
General-header field names can be extended reliably only in General-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of general experimental header fields may be given the semantics of general
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as be general-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
5. Request 5. Request
A request message from a client to a server includes, within the A request message from a client to a server includes, within the
first line of that message, the method to be applied to the resource, first line of that message, the method to be applied to the resource,
the identifier of the resource, and the protocol version in use. the identifier of the resource, and the protocol version in use.
Request = Request-Line ; Section 5.1 Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5 *(( general-header ; Section 4.5
| request-header ; Section 5.3 | request-header ; [Part 2]
| entity-header ) CRLF) ; Section 7.1 | entity-header ) CRLF) ; [Part 3]
CRLF CRLF
[ message-body ] ; Section 4.3 [ message-body ] ; Section 4.3
5.1. Request-Line 5.1. Request-Line
The Request-Line begins with a method token, followed by the Request- The Request-Line begins with a method token, followed by the Request-
URI and the protocol version, and ending with CRLF. The elements are URI and the protocol version, and ending with CRLF. The elements are
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF Request-Line = Method SP Request-URI SP HTTP-Version CRLF
5.1.1. Method 5.1.1. Method
The Method token indicates the method to be performed on the resource The Method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive. identified by the Request-URI. The method is case-sensitive.
Method = "OPTIONS" ; Section 9.2 Method = token
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
The list of methods allowed by a resource can be specified in an
Allow header field (Section 14.7). The return code of the response
always notifies the client whether a method is currently allowed on a
resource, since the set of allowed methods can change dynamically.
An origin server SHOULD return the status code 405 (Method Not
Allowed) if the method is known by the origin server but not allowed
for the requested resource, and 501 (Not Implemented) if the method
is unrecognized or not implemented by the origin server. The methods
GET and HEAD MUST be supported by all general-purpose servers. All
other methods are OPTIONAL; however, if the above methods are
implemented, they MUST be implemented with the same semantics as
those specified in Section 9.
5.1.2. Request-URI 5.1.2. Request-URI
The Request-URI is a Uniform Resource Identifier (Section 3.2) and The Request-URI is a Uniform Resource Identifier (Section 3.2) and
identifies the resource upon which to apply the request. identifies the resource upon which to apply the request.
Request-URI = "*" | absoluteURI | abs_path | authority Request-URI = "*"
| absoluteURI
| ( abs_path [ "?" query ] )
| authority
The four options for Request-URI are dependent on the nature of the The four options for Request-URI are dependent on the nature of the
request. The asterisk "*" means that the request does not apply to a request. The asterisk "*" means that the request does not apply to a
particular resource, but to the server itself, and is only allowed particular resource, but to the server itself, and is only allowed
when the method used does not necessarily apply to a resource. One when the method used does not necessarily apply to a resource. One
example would be example would be
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
The absoluteURI form is REQUIRED when the request is being made to a The absoluteURI form is REQUIRED when the request is being made to a
skipping to change at page 40, line 38 skipping to change at page 27, line 15
any aliases, local variations, and the numeric IP address. An any aliases, local variations, and the numeric IP address. An
example Request-Line would be: example Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies. them in requests to proxies.
The authority form is only used by the CONNECT method (Section 9.9). The authority form is only used by the CONNECT method ([Part 2]).
The most common form of Request-URI is that used to identify a The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send create a TCP connection to port 80 of the host "www.w3.org" and send
the lines: the lines:
skipping to change at page 41, line 4 skipping to change at page 27, line 28
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, abs_path) as path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send create a TCP connection to port 80 of the host "www.w3.org" and send
the lines: the lines:
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org Host: www.w3.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 "% HEX HEX"
encoding [42], the origin server MUST decode the Request-URI in order encoding [29], the origin server MUST decode the Request-URI in order
to properly interpret the request. Servers SHOULD respond to invalid to properly interpret the request. Servers SHOULD respond to invalid
Request-URIs with an appropriate status code. Request-URIs with an appropriate status code.
A transparent proxy MUST NOT rewrite the "abs_path" part of the A transparent proxy MUST NOT rewrite the "abs_path" 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 abs_path with "/". except as noted above to replace a null abs_path 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
skipping to change at page 41, line 32 skipping to change at page 28, line 13
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 A.6.1.1 for other requirements on Host support in HTTP/1.1.) Appendix D.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 42, line 8 skipping to change at page 28, line 37
3. If the host as determined by rule 1 or 2 is not a valid host on 3. If the host as determined by rule 1 or 2 is not a valid host on
the server, the response MUST be a 400 (Bad Request) error the server, the response MUST be a 400 (Bad Request) error
message. message.
Recipients of an HTTP/1.0 request that lacks a Host header field MAY Recipients of an HTTP/1.0 request that lacks a Host header field MAY
attempt to use heuristics (e.g., examination of the URI path for attempt to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to determine what something unique to a particular host) in order to determine what
exact resource is being requested. exact resource is being requested.
5.3. Request Header Fields
The request-header fields allow the client to pass additional
information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics
equivalent to the parameters on a programming language method
invocation.
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
| If-Modified-Since ; Section 14.25
| If-None-Match ; Section 14.26
| If-Range ; Section 14.27
| If-Unmodified-Since ; Section 14.28
| Max-Forwards ; Section 14.31
| Proxy-Authorization ; Section 14.34
| Range ; Section 14.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.43
Request-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of request-
header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as
entity-header fields.
6. Response 6. Response
After receiving and interpreting a request message, a server responds After receiving and interpreting a request message, a server responds
with an HTTP response message. with an HTTP response message.
Response = Status-Line ; Section 6.1 Response = Status-Line ; Section 6.1
*(( general-header ; Section 4.5 *(( general-header ; Section 4.5
| response-header ; Section 6.2 | response-header ; [Part 2]
| entity-header ) CRLF) ; Section 7.1 | entity-header ) CRLF) ; [Part 3]
CRLF CRLF
[ message-body ] ; Section 7.2 [ message-body ] ; Section 4.3
6.1. Status-Line 6.1. Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its of the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP associated textual phrase, with each element separated by SP
characters. No CR or LF is allowed except in the final CRLF characters. No CR or LF is allowed except in the final CRLF
sequence. sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1. Status Code and Reason Phrase 6.1.1. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully attempt to understand and satisfy the request. These codes are fully
defined in Section 10. The Reason-Phrase is intended to give a short defined in [Part 2]. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human for use by automata and the Reason-Phrase is intended for the human
user. The client is not required to examine or display the Reason- user. The client is not required to examine or display the Reason-
Phrase. Phrase.
The first digit of the Status-Code defines the class of response. The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. There are 5 The last two digits do not have any categorization role. There are 5
values for the first digit: values for the first digit:
o 1xx: Informational - Request received, continuing process o 1xx: Informational - Request received, continuing process
skipping to change at page 44, line 4 skipping to change at page 29, line 39
o 1xx: Informational - Request received, continuing process o 1xx: Informational - Request received, continuing process
o 2xx: Success - The action was successfully received, understood, o 2xx: Success - The action was successfully received, understood,
and accepted and accepted
o 3xx: Redirection - Further action must be taken in order to o 3xx: Redirection - Further action must be taken in order to
complete the request complete the request
o 4xx: Client Error - The request contains bad syntax or cannot be o 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently o 5xx: Server Error - The server failed to fulfill an apparently
valid request valid request
The individual values of the numeric status codes defined for Status-Code = 3DIGIT
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
Status-Code =
"100" ; Section 10.1.1: Continue
| "101" ; Section 10.1.2: Switching Protocols
| "200" ; Section 10.2.1: OK
| "201" ; Section 10.2.2: Created
| "202" ; Section 10.2.3: Accepted
| "203" ; Section 10.2.4: Non-Authoritative Information
| "204" ; Section 10.2.5: No Content
| "205" ; Section 10.2.6: Reset Content
| "206" ; Section 10.2.7: Partial Content
| "300" ; Section 10.3.1: Multiple Choices
| "301" ; Section 10.3.2: Moved Permanently
| "302" ; Section 10.3.3: Found
| "303" ; Section 10.3.4: See Other
| "304" ; Section 10.3.5: Not Modified
| "305" ; Section 10.3.6: Use Proxy
| "307" ; Section 10.3.8: Temporary Redirect
| "400" ; Section 10.4.1: Bad Request
| "401" ; Section 10.4.2: Unauthorized
| "402" ; Section 10.4.3: Payment Required
| "403" ; Section 10.4.4: Forbidden
| "404" ; Section 10.4.5: Not Found
| "405" ; Section 10.4.6: Method Not Allowed
| "406" ; Section 10.4.7: Not Acceptable
| "407" ; Section 10.4.8: Proxy Authentication Required
| "408" ; Section 10.4.9: Request Time-out
| "409" ; Section 10.4.10: Conflict
| "410" ; Section 10.4.11: Gone
| "411" ; Section 10.4.12: Length Required
| "412" ; Section 10.4.13: Precondition Failed
| "413" ; Section 10.4.14: Request Entity Too Large
| "414" ; Section 10.4.15: Request-URI Too Large
| "415" ; Section 10.4.16: Unsupported Media Type
| "416" ; Section 10.4.17: Requested range not satisfiable
| "417" ; Section 10.4.18: Expectation Failed
| "500" ; Section 10.5.1: Internal Server Error
| "501" ; Section 10.5.2: Not Implemented
| "502" ; Section 10.5.3: Bad Gateway
| "503" ; Section 10.5.4: Service Unavailable
| "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF> Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP status codes are extensible. HTTP applications are not required 7. Connections
to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.
6.2. Response Header Fields
The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and
about further access to the resource identified by the Request-URI.
response-header = Accept-Ranges ; Section 14.5
| Age ; Section 14.6
| ETag ; Section 14.19
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
| Retry-After ; Section 14.37
| Server ; Section 14.38
| Vary ; Section 14.44
| WWW-Authenticate ; Section 14.47
Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity-header fields.
7. Entity
Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers.
In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.
7.1. Entity Header Fields
Entity-header fields define metainformation about the entity-body or,
if no body is present, about the resource identified by the request.
Some of this metainformation is OPTIONAL; some might be REQUIRED by
portions of this specification.
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and MUST be forwarded by
transparent proxies.
7.2. Entity Body
The entity-body (if any) sent with an HTTP request or response is in
a format and encoding defined by the entity-header fields.
entity-body = *OCTET
An entity-body is only present in a message when a message-body is
present, as described in Section 4.3. The entity-body is obtained
from the message-body by decoding any Transfer-Encoding that might
have been applied to ensure safe and proper transfer of the message.
7.2.1. Type
When an entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding. These define a two-layer, ordered encoding model:
entity-body := Content-Encoding( Content-Type( data ) )
Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is
no default encoding.
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
7.2.2. Entity Length
The entity-length of a message is the length of the message-body
before any transfer-codings have been applied. Section 4.4 defines
how the transfer-length of a message-body is determined.
8. Connections
8.1. Persistent Connections 7.1. Persistent Connections
8.1.1. Purpose 7.1.1. Purpose
Prior to persistent connections, a separate TCP connection was Prior to persistent connections, a separate TCP connection was
established to fetch each URL, increasing the load on HTTP servers established to fetch each URL, increasing the load on HTTP servers
and causing congestion on the Internet. The use of inline images and and causing congestion on the Internet. The use of inline images and
other associated data often require a client to make multiple other associated data often require a client to make multiple
requests of the same server in a short amount of time. Analysis of requests of the same server in a short amount of time. Analysis of
these performance problems and results from a prototype these performance problems and results from a prototype
implementation are available [26] [30]. Implementation experience implementation are available [21] [24]. Implementation experience
and measurements of actual HTTP/1.1 (RFC 2068) implementations show and measurements of actual HTTP/1.1 (RFC 2068) implementations show
good results [39]. Alternatives have also been explored, for good results [28]. Alternatives have also been explored, for
example, T/TCP [27]. example, T/TCP [22].
Persistent HTTP connections have a number of advantages: Persistent HTTP connections have a number of advantages:
o By opening and closing fewer TCP connections, CPU time is saved in o By opening and closing fewer TCP connections, CPU time is saved in
routers and hosts (clients, servers, proxies, gateways, tunnels, routers and hosts (clients, servers, proxies, gateways, tunnels,
or caches), and memory used for TCP protocol control blocks can be or caches), and memory used for TCP protocol control blocks can be
saved in hosts. saved in hosts.
o HTTP requests and responses can be pipelined on a connection. o HTTP requests and responses can be pipelined on a connection.
Pipelining allows a client to make multiple requests without Pipelining allows a client to make multiple requests without
skipping to change at page 49, line 49 skipping to change at page 30, line 47
spent in TCP's connection opening handshake. spent in TCP's connection opening handshake.
o HTTP can evolve more gracefully, since errors can be reported o HTTP can evolve more gracefully, since errors can be reported
without the penalty of closing the TCP connection. Clients using without the penalty of closing the TCP connection. Clients using
future versions of HTTP might optimistically try a new feature, future versions of HTTP might optimistically try a new feature,
but if communicating with an older server, retry with old but if communicating with an older server, retry with old
semantics after an error is reported. semantics after an error is reported.
HTTP implementations SHOULD implement persistent connections. HTTP implementations SHOULD implement persistent connections.
8.1.2. Overall Operation 7.1.2. Overall Operation
A significant difference between HTTP/1.1 and earlier versions of A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any HTTP is that persistent connections are the default behavior of any
HTTP connection. That is, unless otherwise indicated, the client HTTP connection. That is, unless otherwise indicated, the client
SHOULD assume that the server will maintain a persistent connection, SHOULD assume that the server will maintain a persistent connection,
even after error responses from the server. even after error responses from the server.
Persistent connections provide a mechanism by which a client and a Persistent connections provide a mechanism by which a client and a
server can signal the close of a TCP connection. This signaling server can signal the close of a TCP connection. This signaling
takes place using the Connection header field (Section 14.10). Once takes place using the Connection header field (Section 8.1). Once a
a close has been signaled, the client MUST NOT send any more requests close has been signaled, the client MUST NOT send any more requests
on that connection. on that connection.
8.1.2.1. Negotiation 7.1.2.1. Negotiation
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header including maintain a persistent connection unless a Connection header including
the connection-token "close" was sent in the request. If the server the connection-token "close" was sent in the request. If the server
chooses to close the connection immediately after sending the chooses to close the connection immediately after sending the
response, it SHOULD send a Connection header including the response, it SHOULD send a Connection header including the
connection-token close. connection-token close.
An HTTP/1.1 client MAY expect a connection to remain open, but would An HTTP/1.1 client MAY expect a connection to remain open, but would
decide to keep it open based on whether the response from a server decide to keep it open based on whether the response from a server
skipping to change at page 50, line 36 skipping to change at page 31, line 34
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 A.6.2 for more information on backward signaled. See Appendix D.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.
8.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
response). A server MUST send its responses to those requests in the response). A server MUST send its responses to those requests in the
same order that the requests were received. same order that the requests were received.
Clients which assume persistent connections and pipeline immediately Clients which assume persistent connections and pipeline immediately
after connection establishment SHOULD be prepared to retry their after connection establishment SHOULD be prepared to retry their
connection if the first pipelined attempt fails. If a client does connection if the first pipelined attempt fails. If a client does
such a retry, it MUST NOT pipeline before it knows the connection is such a retry, it MUST NOT pipeline before it knows the connection is
persistent. Clients MUST also be prepared to resend their requests persistent. Clients MUST also be prepared to resend their requests
if the server closes the connection before sending all of the if the server closes the connection before sending all of the
corresponding responses. corresponding responses.
Clients SHOULD NOT pipeline requests using non-idempotent methods or Clients SHOULD NOT pipeline requests using non-idempotent methods or
non-idempotent sequences of methods (see Section 9.1.2). Otherwise, non-idempotent sequences of methods (see [Part 2]). Otherwise, a
a premature termination of the transport connection could lead to premature termination of the transport connection could lead to
indeterminate results. A client wishing to send a non-idempotent indeterminate results. A client wishing to send a non-idempotent
request SHOULD wait to send that request until it has received the request SHOULD wait to send that request until it has received the
response status for the previous request. response status for the previous request.
8.1.3. Proxy Servers 7.1.3. Proxy Servers
It is especially important that proxies correctly implement the It is especially important that proxies correctly implement the
properties of the Connection header field as specified in properties of the Connection header field as specified in
Section 14.10. Section 8.1.
The proxy server MUST signal persistent connections separately with The proxy server MUST signal persistent connections separately with
its clients and the origin servers (or other proxy servers) that it its clients and the origin servers (or other proxy servers) that it
connects to. Each persistent connection applies to only one connects to. Each persistent connection applies to only one
transport link. transport link.
A proxy server MUST NOT establish a HTTP/1.1 persistent connection A proxy server MUST NOT establish a HTTP/1.1 persistent connection
with an HTTP/1.0 client (but see RFC 2068 [33] for information and with an HTTP/1.0 client (but see RFC 2068 [25] for information and
discussion of the problems with the Keep-Alive header implemented by discussion of the problems with the Keep-Alive header implemented by
many HTTP/1.0 clients). many HTTP/1.0 clients).
8.1.4. Practical Considerations 7.1.4. Practical Considerations
Servers will usually have some time-out value beyond which they will Servers will usually have some time-out value beyond which they will
no longer maintain an inactive connection. Proxy servers might make no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making this a higher value since it is likely that the client will be making
more connections through the same server. The use of persistent more connections through the same server. The use of persistent
connections places no requirements on the length (or existence) of connections places no requirements on the length (or existence) of
this time-out for either the client or the server. this time-out for either the client or the server.
When a client or server wishes to time-out it SHOULD issue a graceful When a client or server wishes to time-out it SHOULD issue a graceful
close on the transport connection. Clients and servers SHOULD both close on the transport connection. Clients and servers SHOULD both
skipping to change at page 52, line 12 skipping to change at page 33, line 10
time. For example, a client might have started to send a new request time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle" at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a closed while it was idle, but from the client's point of view, a
request is in progress. request is in progress.
This means that clients, servers, and proxies MUST be able to recover This means that clients, servers, and proxies MUST be able to recover
from asynchronous close events. Client software SHOULD reopen the from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is without user interaction so long as the request sequence is
idempotent (see Section 9.1.2). Non-idempotent methods or sequences idempotent (see [Part 2]). Non-idempotent methods or sequences MUST
MUST NOT be automatically retried, although user agents MAY offer a NOT be automatically retried, although user agents MAY offer a human
human operator the choice of retrying the request(s). Confirmation operator the choice of retrying the request(s). Confirmation by
by user-agent software with semantic understanding of the application user-agent software with semantic understanding of the application
MAY substitute for user confirmation. The automatic retry SHOULD NOT MAY substitute for user confirmation. The automatic retry SHOULD NOT
be repeated if the second sequence of requests fails. be repeated if the second sequence of requests fails.
Servers SHOULD always respond to at least one request per connection, Servers SHOULD always respond to at least one request per connection,
if at all possible. Servers SHOULD NOT close a connection in the if at all possible. Servers SHOULD NOT close a connection in the
middle of transmitting a response, unless a network or client failure middle of transmitting a response, unless a network or client failure
is suspected. is suspected.
Clients that use persistent connections SHOULD limit the number of Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with single-user client SHOULD NOT maintain more than 2 connections with
any server or proxy. A proxy SHOULD use up to 2*N connections to any server or proxy. A proxy SHOULD use up to 2*N connections to
another server or proxy, where N is the number of simultaneously another server or proxy, where N is the number of simultaneously
active users. These guidelines are intended to improve HTTP response active users. These guidelines are intended to improve HTTP response
times and avoid congestion. times and avoid congestion.
8.2. Message Transmission Requirements 7.2. Message Transmission Requirements
8.2.1. Persistent Connections and Flow Control 7.2.1. Persistent Connections and Flow Control
HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
flow control mechanisms to resolve temporary overloads, rather than flow control mechanisms to resolve temporary overloads, rather than
terminating connections with the expectation that clients will retry. terminating connections with the expectation that clients will retry.
The latter technique can exacerbate network congestion. The latter technique can exacerbate network congestion.
8.2.2. Monitoring Connections for Error Status Messages 7.2.2. Monitoring Connections for Error Status Messages
An HTTP/1.1 (or later) client sending a message-body SHOULD monitor An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
the network connection for an error status while it is transmitting the network connection for an error status while it is transmitting
the request. If the client sees an error status, it SHOULD the request. If the client sees an error status, it SHOULD
immediately cease transmitting the body. If the body is being sent immediately cease transmitting the body. If the body is being sent
using a "chunked" encoding (Section 3.6), a zero length chunk and using a "chunked" encoding (Section 3.4), a zero length chunk and
empty trailer MAY be used to prematurely mark the end of the message. empty trailer MAY be used to prematurely mark the end of the message.
If the body was preceded by a Content-Length header, the client MUST If the body was preceded by a Content-Length header, the client MUST
close the connection. close the connection.
8.2.3. Use of the 100 (Continue) Status 7.2.3. Use of the 100 (Continue) Status
The purpose of the 100 (Continue) status (see Section 10.1.1) is to The purpose of the 100 (Continue) status (see [Part 2]) is to allow a
allow a client that is sending a request message with a request body client that is sending a request message with a request body to
to determine if the origin server is willing to accept the request determine if the origin server is willing to accept the request
(based on the request headers) before the client sends the request (based on the request headers) before the client sends the request
body. In some cases, it might either be inappropriate or highly body. In some cases, it might either be inappropriate or highly
inefficient for the client to send the body if the server will reject inefficient for the client to send the body if the server will reject
the message without looking at the body. the message without looking at the body.