[559] | 1 | |
---|
| 2 | |
---|
| 3 | |
---|
| 4 | Network Working Group R. Fielding, Ed. |
---|
| 5 | Internet-Draft Day Software |
---|
| 6 | Obsoletes: 2616 (if approved) J. Gettys |
---|
| 7 | Intended status: Standards Track One Laptop per Child |
---|
| 8 | Expires: May 20, 2009 J. Mogul |
---|
| 9 | HP |
---|
| 10 | H. Frystyk |
---|
| 11 | Microsoft |
---|
| 12 | L. Masinter |
---|
| 13 | Adobe Systems |
---|
| 14 | P. Leach |
---|
| 15 | Microsoft |
---|
| 16 | T. Berners-Lee |
---|
| 17 | W3C/MIT |
---|
| 18 | Y. Lafon, Ed. |
---|
| 19 | W3C |
---|
| 20 | J. Reschke, Ed. |
---|
| 21 | greenbytes |
---|
| 22 | November 16, 2008 |
---|
| 23 | |
---|
| 24 | |
---|
| 25 | HTTP/1.1, part 1: URIs, Connections, and Message Parsing |
---|
| 26 | draft-ietf-httpbis-p1-messaging-05 |
---|
| 27 | |
---|
| 28 | Status of this Memo |
---|
| 29 | |
---|
| 30 | By submitting this Internet-Draft, each author represents that any |
---|
| 31 | applicable patent or other IPR claims of which he or she is aware |
---|
| 32 | have been or will be disclosed, and any of which he or she becomes |
---|
| 33 | aware will be disclosed, in accordance with Section 6 of BCP 79. |
---|
| 34 | |
---|
| 35 | Internet-Drafts are working documents of the Internet Engineering |
---|
| 36 | Task Force (IETF), its areas, and its working groups. Note that |
---|
| 37 | other groups may also distribute working documents as Internet- |
---|
| 38 | Drafts. |
---|
| 39 | |
---|
| 40 | Internet-Drafts are draft documents valid for a maximum of six months |
---|
| 41 | and may be updated, replaced, or obsoleted by other documents at any |
---|
| 42 | time. It is inappropriate to use Internet-Drafts as reference |
---|
| 43 | material or to cite them other than as "work in progress." |
---|
| 44 | |
---|
| 45 | The list of current Internet-Drafts can be accessed at |
---|
| 46 | http://www.ietf.org/ietf/1id-abstracts.txt. |
---|
| 47 | |
---|
| 48 | The list of Internet-Draft Shadow Directories can be accessed at |
---|
| 49 | http://www.ietf.org/shadow.html. |
---|
| 50 | |
---|
| 51 | This Internet-Draft will expire on May 20, 2009. |
---|
| 52 | |
---|
| 53 | |
---|
| 54 | |
---|
| 55 | Fielding, et al. Expires May 20, 2009 [Page 1] |
---|
| 56 | |
---|
| 57 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 58 | |
---|
| 59 | |
---|
| 60 | Abstract |
---|
| 61 | |
---|
| 62 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
| 63 | protocol for distributed, collaborative, hypermedia information |
---|
| 64 | systems. HTTP has been in use by the World Wide Web global |
---|
| 65 | information initiative since 1990. This document is Part 1 of the |
---|
| 66 | seven-part specification that defines the protocol referred to as |
---|
| 67 | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |
---|
| 68 | an overview of HTTP and its associated terminology, defines the |
---|
| 69 | "http" and "https" Uniform Resource Identifier (URI) schemes, defines |
---|
| 70 | the generic message syntax and parsing requirements for HTTP message |
---|
| 71 | frames, and describes general security concerns for implementations. |
---|
| 72 | |
---|
| 73 | Editorial Note (To be removed by RFC Editor) |
---|
| 74 | |
---|
| 75 | Discussion of this draft should take place on the HTTPBIS working |
---|
| 76 | group mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
| 77 | at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related |
---|
| 78 | documents (including fancy diffs) can be found at |
---|
| 79 | <http://tools.ietf.org/wg/httpbis/>. |
---|
| 80 | |
---|
| 81 | The changes in this draft are summarized in Appendix E.6. |
---|
| 82 | |
---|
| 83 | |
---|
| 84 | |
---|
| 85 | |
---|
| 86 | |
---|
| 87 | |
---|
| 88 | |
---|
| 89 | |
---|
| 90 | |
---|
| 91 | |
---|
| 92 | |
---|
| 93 | |
---|
| 94 | |
---|
| 95 | |
---|
| 96 | |
---|
| 97 | |
---|
| 98 | |
---|
| 99 | |
---|
| 100 | |
---|
| 101 | |
---|
| 102 | |
---|
| 103 | |
---|
| 104 | |
---|
| 105 | |
---|
| 106 | |
---|
| 107 | |
---|
| 108 | |
---|
| 109 | |
---|
| 110 | |
---|
| 111 | Fielding, et al. Expires May 20, 2009 [Page 2] |
---|
| 112 | |
---|
| 113 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 114 | |
---|
| 115 | |
---|
| 116 | Table of Contents |
---|
| 117 | |
---|
| 118 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
| 119 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
| 120 | 1.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 6 |
---|
| 121 | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 8 |
---|
| 122 | 2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . . . 8 |
---|
| 123 | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 8 |
---|
| 124 | 2.3. ABNF Rules defined in other Parts of the Specification . . 10 |
---|
| 125 | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 |
---|
| 126 | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 11 |
---|
| 127 | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 12 |
---|
| 128 | 3.2.1. http URI scheme . . . . . . . . . . . . . . . . . . . 13 |
---|
| 129 | 3.2.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 13 |
---|
| 130 | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 14 |
---|
| 131 | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 14 |
---|
| 132 | 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 16 |
---|
| 133 | 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 17 |
---|
| 134 | 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 18 |
---|
| 135 | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
---|
| 136 | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 19 |
---|
| 137 | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 20 |
---|
| 138 | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21 |
---|
| 139 | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22 |
---|
| 140 | 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 23 |
---|
| 141 | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
| 142 | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
| 143 | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
| 144 | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 24 |
---|
| 145 | 5.2. The Resource Identified by a Request . . . . . . . . . . . 26 |
---|
| 146 | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
---|
| 147 | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27 |
---|
| 148 | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 27 |
---|
| 149 | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27 |
---|
| 150 | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 28 |
---|
| 151 | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 28 |
---|
| 152 | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 28 |
---|
| 153 | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 30 |
---|
| 154 | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 30 |
---|
| 155 | 7.2. Message Transmission Requirements . . . . . . . . . . . . 31 |
---|
| 156 | 7.2.1. Persistent Connections and Flow Control . . . . . . . 31 |
---|
| 157 | 7.2.2. Monitoring Connections for Error Status Messages . . . 31 |
---|
| 158 | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 32 |
---|
| 159 | 7.2.4. Client Behavior if Server Prematurely Closes |
---|
| 160 | Connection . . . . . . . . . . . . . . . . . . . . . . 34 |
---|
| 161 | 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 34 |
---|
| 162 | 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 35 |
---|
| 163 | 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 36 |
---|
| 164 | |
---|
| 165 | |
---|
| 166 | |
---|
| 167 | Fielding, et al. Expires May 20, 2009 [Page 3] |
---|
| 168 | |
---|
| 169 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 170 | |
---|
| 171 | |
---|
| 172 | 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
---|
| 173 | 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 37 |
---|
| 174 | 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
| 175 | 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
| 176 | 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
---|
| 177 | 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 40 |
---|
| 178 | 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
---|
| 179 | 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
---|
| 180 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 |
---|
| 181 | 9.1. Message Header Registration . . . . . . . . . . . . . . . 43 |
---|
| 182 | 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 44 |
---|
| 183 | 9.3. Internet Media Type Registrations . . . . . . . . . . . . 44 |
---|
| 184 | 9.3.1. Internet Media Type message/http . . . . . . . . . . . 44 |
---|
| 185 | 9.3.2. Internet Media Type application/http . . . . . . . . . 45 |
---|
| 186 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 |
---|
| 187 | 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 47 |
---|
| 188 | 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 47 |
---|
| 189 | 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47 |
---|
| 190 | 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47 |
---|
| 191 | 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 48 |
---|
| 192 | 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 49 |
---|
| 193 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 |
---|
| 194 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 |
---|
| 195 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 50 |
---|
| 196 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 |
---|
| 197 | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 53 |
---|
| 198 | Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 54 |
---|
| 199 | Appendix C. Compatibility with Previous Versions . . . . . . . . 54 |
---|
| 200 | C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 55 |
---|
| 201 | C.1.1. Changes to Simplify Multi-homed Web Servers and |
---|
| 202 | Conserve IP Addresses . . . . . . . . . . . . . . . . 55 |
---|
| 203 | C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 56 |
---|
| 204 | C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 57 |
---|
| 205 | C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 57 |
---|
| 206 | Appendix D. Terminology . . . . . . . . . . . . . . . . . . . . . 58 |
---|
| 207 | Appendix E. Change Log (to be removed by RFC Editor before |
---|
| 208 | publication) . . . . . . . . . . . . . . . . . . . . 61 |
---|
| 209 | E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 |
---|
| 210 | E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 |
---|
| 211 | E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62 |
---|
| 212 | E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 63 |
---|
| 213 | E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 64 |
---|
| 214 | E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 64 |
---|
| 215 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 |
---|
| 216 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 |
---|
| 217 | Intellectual Property and Copyright Statements . . . . . . . . . . 72 |
---|
| 218 | |
---|
| 219 | |
---|
| 220 | |
---|
| 221 | |
---|
| 222 | |
---|
| 223 | Fielding, et al. Expires May 20, 2009 [Page 4] |
---|
| 224 | |
---|
| 225 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 226 | |
---|
| 227 | |
---|
| 228 | 1. Introduction |
---|
| 229 | |
---|
| 230 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
| 231 | request/response protocol that uses extensible semantics and MIME- |
---|
| 232 | like message payloads for flexible interaction with network-based |
---|
| 233 | hypermedia information systems. HTTP relies upon the Uniform |
---|
| 234 | Resource Identifier (URI) standard [RFC3986] to indicate resource |
---|
| 235 | targets for interaction and to identify other resources. Messages |
---|
| 236 | are passed in a format similar to that used by Internet mail |
---|
| 237 | [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) |
---|
| 238 | [RFC2045] (see Appendix A of [Part3] for the differences between HTTP |
---|
| 239 | and MIME messages). |
---|
| 240 | |
---|
| 241 | HTTP is also designed for use as a generic protocol for translating |
---|
| 242 | communication to and from other Internet information systems, such as |
---|
| 243 | USENET news services via NNTP [RFC3977], file services via FTP |
---|
| 244 | [RFC959], Gopher [RFC1436], and WAIS [WAIS]. HTTP proxies and |
---|
| 245 | gateways provide access to alternative information services by |
---|
| 246 | translating their diverse protocols into a hypermedia format that can |
---|
| 247 | be viewed and manipulated by clients in the same way as HTTP |
---|
| 248 | services. |
---|
| 249 | |
---|
| 250 | This document is Part 1 of the seven-part specification of HTTP, |
---|
| 251 | defining the protocol referred to as "HTTP/1.1" and obsoleting |
---|
| 252 | [RFC2616]. Part 1 defines how clients determine when to use HTTP, |
---|
| 253 | the URI schemes specific to HTTP-based resources, overall network |
---|
| 254 | operation with transport protocol connection management, and HTTP |
---|
| 255 | message framing. Our goal is to define all of the mechanisms |
---|
| 256 | necessary for HTTP message handling that are independent of message |
---|
| 257 | semantics, thereby defining the complete set of requirements for an |
---|
| 258 | HTTP message relay or generic message parser. |
---|
| 259 | |
---|
| 260 | 1.1. Requirements |
---|
| 261 | |
---|
| 262 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
| 263 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
| 264 | document are to be interpreted as described in [RFC2119]. |
---|
| 265 | |
---|
| 266 | An implementation is not compliant if it fails to satisfy one or more |
---|
| 267 | of the MUST or REQUIRED level requirements for the protocols it |
---|
| 268 | implements. An implementation that satisfies all the MUST or |
---|
| 269 | REQUIRED level and all the SHOULD level requirements for its |
---|
| 270 | protocols is said to be "unconditionally compliant"; one that |
---|
| 271 | satisfies all the MUST level requirements but not all the SHOULD |
---|
| 272 | level requirements for its protocols is said to be "conditionally |
---|
| 273 | compliant." |
---|
| 274 | |
---|
| 275 | |
---|
| 276 | |
---|
| 277 | |
---|
| 278 | |
---|
| 279 | Fielding, et al. Expires May 20, 2009 [Page 5] |
---|
| 280 | |
---|
| 281 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 282 | |
---|
| 283 | |
---|
| 284 | 1.2. Overall Operation |
---|
| 285 | |
---|
| 286 | HTTP is a request/response protocol. A client sends a request to the |
---|
| 287 | server in the form of a request method, URI, and protocol version, |
---|
| 288 | followed by a MIME-like message containing request modifiers, client |
---|
| 289 | information, and possible body content over a connection with a |
---|
| 290 | server. The server responds with a status line, including the |
---|
| 291 | message's protocol version and a success or error code, followed by a |
---|
| 292 | MIME-like message containing server information, entity |
---|
| 293 | metainformation, and possible entity-body content. The relationship |
---|
| 294 | between HTTP and MIME is described in Appendix A of [Part3]. |
---|
| 295 | |
---|
| 296 | Most HTTP communication is initiated by a user agent and consists of |
---|
| 297 | a request to be applied to a resource on some origin server. In the |
---|
| 298 | simplest case, this may be accomplished via a single connection (v) |
---|
| 299 | between the user agent (UA) and the origin server (O). |
---|
| 300 | |
---|
| 301 | request chain ------------------------> |
---|
| 302 | UA -------------------v------------------- O |
---|
| 303 | <----------------------- response chain |
---|
| 304 | |
---|
| 305 | A more complicated situation occurs when one or more intermediaries |
---|
| 306 | are present in the request/response chain. There are three common |
---|
| 307 | forms of intermediary: proxy, gateway, and tunnel. A proxy is a |
---|
| 308 | forwarding agent, receiving requests for a URI in its absolute form, |
---|
| 309 | rewriting all or part of the message, and forwarding the reformatted |
---|
| 310 | request toward the server identified by the URI. A gateway is a |
---|
| 311 | receiving agent, acting as a layer above some other server(s) and, if |
---|
| 312 | necessary, translating the requests to the underlying server's |
---|
| 313 | protocol. A tunnel acts as a relay point between two connections |
---|
| 314 | without changing the messages; tunnels are used when the |
---|
| 315 | communication needs to pass through an intermediary (such as a |
---|
| 316 | firewall) even when the intermediary cannot understand the contents |
---|
| 317 | of the messages. |
---|
| 318 | |
---|
| 319 | request chain --------------------------------------> |
---|
| 320 | UA -----v----- A -----v----- B -----v----- C -----v----- O |
---|
| 321 | <------------------------------------- response chain |
---|
| 322 | |
---|
| 323 | The figure above shows three intermediaries (A, B, and C) between the |
---|
| 324 | user agent and origin server. A request or response message that |
---|
| 325 | travels the whole chain will pass through four separate connections. |
---|
| 326 | This distinction is important because some HTTP communication options |
---|
| 327 | may apply only to the connection with the nearest, non-tunnel |
---|
| 328 | neighbor, only to the end-points of the chain, or to all connections |
---|
| 329 | along the chain. Although the diagram is linear, each participant |
---|
| 330 | may be engaged in multiple, simultaneous communications. For |
---|
| 331 | example, B may be receiving requests from many clients other than A, |
---|
| 332 | |
---|
| 333 | |
---|
| 334 | |
---|
| 335 | Fielding, et al. Expires May 20, 2009 [Page 6] |
---|
| 336 | |
---|
| 337 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 338 | |
---|
| 339 | |
---|
| 340 | and/or forwarding requests to servers other than C, at the same time |
---|
| 341 | that it is handling A's request. |
---|
| 342 | |
---|
| 343 | Any party to the communication which is not acting as a tunnel may |
---|
| 344 | employ an internal cache for handling requests. The effect of a |
---|
| 345 | cache is that the request/response chain is shortened if one of the |
---|
| 346 | participants along the chain has a cached response applicable to that |
---|
| 347 | request. The following illustrates the resulting chain if B has a |
---|
| 348 | cached copy of an earlier response from O (via C) for a request which |
---|
| 349 | has not been cached by UA or A. |
---|
| 350 | |
---|
| 351 | request chain ----------> |
---|
| 352 | UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
---|
| 353 | <--------- response chain |
---|
| 354 | |
---|
| 355 | Not all responses are usefully cacheable, and some requests may |
---|
| 356 | contain modifiers which place special requirements on cache behavior. |
---|
| 357 | HTTP requirements for cache behavior and cacheable responses are |
---|
| 358 | defined in Section 1 of [Part6]. |
---|
| 359 | |
---|
| 360 | In fact, there are a wide variety of architectures and configurations |
---|
| 361 | of caches and proxies currently being experimented with or deployed |
---|
| 362 | across the World Wide Web. These systems include national hierarchies |
---|
| 363 | of proxy caches to save transoceanic bandwidth, systems that |
---|
| 364 | broadcast or multicast cache entries, organizations that distribute |
---|
| 365 | subsets of cached data via CD-ROM, and so on. HTTP systems are used |
---|
| 366 | in corporate intranets over high-bandwidth links, and for access via |
---|
| 367 | PDAs with low-power radio links and intermittent connectivity. The |
---|
| 368 | goal of HTTP/1.1 is to support the wide diversity of configurations |
---|
| 369 | already deployed while introducing protocol constructs that meet the |
---|
| 370 | needs of those who build web applications that require high |
---|
| 371 | reliability and, failing that, at least reliable indications of |
---|
| 372 | failure. |
---|
| 373 | |
---|
| 374 | HTTP communication usually takes place over TCP/IP connections. The |
---|
| 375 | default port is TCP 80 |
---|
| 376 | (<http://www.iana.org/assignments/port-numbers>), but other ports can |
---|
| 377 | be used. This does not preclude HTTP from being implemented on top |
---|
| 378 | of any other protocol on the Internet, or on other networks. HTTP |
---|
| 379 | only presumes a reliable transport; any protocol that provides such |
---|
| 380 | guarantees can be used; the mapping of the HTTP/1.1 request and |
---|
| 381 | response structures onto the transport data units of the protocol in |
---|
| 382 | question is outside the scope of this specification. |
---|
| 383 | |
---|
| 384 | In HTTP/1.0, most implementations used a new connection for each |
---|
| 385 | request/response exchange. In HTTP/1.1, a connection may be used for |
---|
| 386 | one or more request/response exchanges, although connections may be |
---|
| 387 | closed for a variety of reasons (see Section 7.1). |
---|
| 388 | |
---|
| 389 | |
---|
| 390 | |
---|
| 391 | Fielding, et al. Expires May 20, 2009 [Page 7] |
---|
| 392 | |
---|
| 393 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 394 | |
---|
| 395 | |
---|
| 396 | 2. Notational Conventions and Generic Grammar |
---|
| 397 | |
---|
| 398 | 2.1. ABNF Extension: #rule |
---|
| 399 | |
---|
| 400 | One extension to the ABNF rules of [RFC5234] is used to improve |
---|
| 401 | readability. |
---|
| 402 | |
---|
| 403 | A construct "#" is defined, similar to "*", for defining lists of |
---|
| 404 | elements. The full form is "<n>#<m>element" indicating at least <n> |
---|
| 405 | and at most <m> elements, each separated by one or more commas (",") |
---|
| 406 | and OPTIONAL linear white space (OWS). This makes the usual form of |
---|
| 407 | lists very easy; a rule such as |
---|
| 408 | |
---|
| 409 | ( *OWS element *( *OWS "," *OWS element )) |
---|
| 410 | |
---|
| 411 | can be shown as |
---|
| 412 | |
---|
| 413 | 1#element |
---|
| 414 | |
---|
| 415 | Wherever this construct is used, null elements are allowed, but do |
---|
| 416 | not contribute to the count of elements present. That is, |
---|
| 417 | "(element), , (element) " is permitted, but counts as only two |
---|
| 418 | elements. Therefore, where at least one element is required, at |
---|
| 419 | least one non-null element MUST be present. Default values are 0 and |
---|
| 420 | infinity so that "#element" allows any number, including zero; |
---|
| 421 | "1#element" requires at least one; and "1#2element" allows one or |
---|
| 422 | two. |
---|
| 423 | |
---|
| 424 | [[abnf.list: At a later point of time, we may want to add an appendix |
---|
| 425 | containing the whole ABNF, with the list rules expanded to strict RFC |
---|
| 426 | 5234 notation.]] |
---|
| 427 | |
---|
| 428 | 2.2. Basic Rules |
---|
| 429 | |
---|
| 430 | This specification uses the Augmented Backus-Naur Form (ABNF) |
---|
| 431 | notation of [RFC5234]. The following core rules are included by |
---|
| 432 | reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), |
---|
| 433 | CHAR (any [USASCII] character, excluding NUL), CR (carriage return), |
---|
| 434 | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |
---|
| 435 | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF |
---|
| 436 | (line feed), OCTET (any 8-bit sequence of data), SP (space) and WSP |
---|
| 437 | (white space). |
---|
| 438 | |
---|
| 439 | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |
---|
| 440 | protocol elements except the entity-body (see Appendix A for tolerant |
---|
| 441 | applications). The end-of-line marker within an entity-body is |
---|
| 442 | defined by its associated media type, as described in Section 3.3 of |
---|
| 443 | [Part3]. |
---|
| 444 | |
---|
| 445 | |
---|
| 446 | |
---|
| 447 | Fielding, et al. Expires May 20, 2009 [Page 8] |
---|
| 448 | |
---|
| 449 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 450 | |
---|
| 451 | |
---|
| 452 | All linear white space (LWS) in header field-values has the same |
---|
| 453 | semantics as SP. A recipient MAY replace any such linear white space |
---|
| 454 | with a single SP before interpreting the field value or forwarding |
---|
| 455 | the message downstream. |
---|
| 456 | |
---|
| 457 | Historically, HTTP/1.1 header field values allow linear white space |
---|
| 458 | folding across multiple lines. However, this specification |
---|
| 459 | deprecates its use; senders MUST NOT produce messages that include |
---|
| 460 | LWS folding (i.e., use the obs-fold rule), except within the message/ |
---|
| 461 | http media type (Section 9.3.1). Receivers SHOULD still parse folded |
---|
| 462 | linear white space. |
---|
| 463 | |
---|
| 464 | This specification uses three rules to denote the use of linear white |
---|
| 465 | space; BWS ("Bad" White Space), OWS (Optional White Space), and RWS |
---|
| 466 | (Required White Space). |
---|
| 467 | |
---|
| 468 | "Bad" white space is allowed by the BNF, but senders SHOULD NOT |
---|
| 469 | produce it in messages. Receivers MUST accept it in incoming |
---|
| 470 | messages. |
---|
| 471 | |
---|
| 472 | Required white space is used when at least one linear white space |
---|
| 473 | character is required to separate field tokens. In all such cases, a |
---|
| 474 | single SP character SHOULD be used. |
---|
| 475 | |
---|
| 476 | |
---|
| 477 | OWS = *( [ obs-fold ] WSP ) |
---|
| 478 | ; "optional" white space |
---|
| 479 | RWS = 1*( [ obs-fold ] WSP ) |
---|
| 480 | ; "required" white space |
---|
| 481 | BWS = OWS |
---|
| 482 | ; "bad" white space |
---|
| 483 | obs-fold = CRLF |
---|
| 484 | |
---|
| 485 | The TEXT rule is only used for descriptive field contents and values |
---|
| 486 | that are not intended to be interpreted by the message parser. Words |
---|
| 487 | of *TEXT MAY contain characters from character sets other than ISO- |
---|
| 488 | 8859-1 [ISO-8859-1] only when encoded according to the rules of |
---|
| 489 | [RFC2047]. |
---|
| 490 | |
---|
| 491 | TEXT = %x20-7E / %x80-FF / OWS |
---|
| 492 | ; any OCTET except CTLs, but including OWS |
---|
| 493 | |
---|
| 494 | A CRLF is allowed in the definition of TEXT only as part of a header |
---|
| 495 | field continuation. It is expected that the folding LWS will be |
---|
| 496 | replaced with a single SP before interpretation of the TEXT value. |
---|
| 497 | |
---|
| 498 | Many HTTP/1.1 header field values consist of words separated by LWS |
---|
| 499 | or special characters. These special characters MUST be in a quoted |
---|
| 500 | |
---|
| 501 | |
---|
| 502 | |
---|
| 503 | Fielding, et al. Expires May 20, 2009 [Page 9] |
---|
| 504 | |
---|
| 505 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 506 | |
---|
| 507 | |
---|
| 508 | string to be used within a parameter value (as defined in |
---|
| 509 | Section 3.4). |
---|
| 510 | |
---|
| 511 | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |
---|
| 512 | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |
---|
| 513 | / DIGIT / ALPHA |
---|
| 514 | |
---|
| 515 | token = 1*tchar |
---|
| 516 | |
---|
| 517 | Comments can be included in some HTTP header fields by surrounding |
---|
| 518 | the comment text with parentheses. Comments are only allowed in |
---|
| 519 | fields containing "comment" as part of their field value definition. |
---|
| 520 | In all other fields, parentheses are considered part of the field |
---|
| 521 | value. |
---|
| 522 | |
---|
| 523 | comment = "(" *( ctext / quoted-pair / comment ) ")" |
---|
| 524 | ctext = <any TEXT excluding "(" and ")"> |
---|
| 525 | |
---|
| 526 | A string of text is parsed as a single word if it is quoted using |
---|
| 527 | double-quote marks. |
---|
| 528 | |
---|
| 529 | quoted-string = DQUOTE *(qdtext / quoted-pair ) DQUOTE |
---|
| 530 | qdtext = <any TEXT excluding DQUOTE and "\"> |
---|
| 531 | |
---|
| 532 | The backslash character ("\") MAY be used as a single-character |
---|
| 533 | quoting mechanism only within quoted-string and comment constructs. |
---|
| 534 | |
---|
| 535 | quoted-text = %x01-09 / |
---|
| 536 | %x0B-0C / |
---|
| 537 | %x0E-FF ; Characters excluding NUL, CR and LF |
---|
| 538 | quoted-pair = "\" quoted-text |
---|
| 539 | |
---|
| 540 | 2.3. ABNF Rules defined in other Parts of the Specification |
---|
| 541 | |
---|
| 542 | The ABNF rules below are defined in other parts: |
---|
| 543 | |
---|
| 544 | request-header = <request-header, defined in [Part2], Section 4> |
---|
| 545 | response-header = <response-header, defined in [Part2], Section 6> |
---|
| 546 | |
---|
| 547 | |
---|
| 548 | accept-params = <accept-params, defined in [Part3], Section 6.1> |
---|
| 549 | entity-body = <entity-body, defined in [Part3], Section 4.2> |
---|
| 550 | entity-header = <entity-header, defined in [Part3], Section 4.1> |
---|
| 551 | |
---|
| 552 | |
---|
| 553 | Cache-Control = <Cache-Control, defined in [Part6], Section 16.4> |
---|
| 554 | Pragma = <Pragma, defined in [Part6], Section 16.4> |
---|
| 555 | Warning = <Warning, defined in [Part6], Section 16.6> |
---|
| 556 | |
---|
| 557 | |
---|
| 558 | |
---|
| 559 | Fielding, et al. Expires May 20, 2009 [Page 10] |
---|
| 560 | |
---|
| 561 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 562 | |
---|
| 563 | |
---|
| 564 | 3. Protocol Parameters |
---|
| 565 | |
---|
| 566 | 3.1. HTTP Version |
---|
| 567 | |
---|
| 568 | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
---|
| 569 | of the protocol. The protocol versioning policy is intended to allow |
---|
| 570 | the sender to indicate the format of a message and its capacity for |
---|
| 571 | understanding further HTTP communication, rather than the features |
---|
| 572 | obtained via that communication. No change is made to the version |
---|
| 573 | number for the addition of message components which do not affect |
---|
| 574 | communication behavior or which only add to extensible field values. |
---|
| 575 | The <minor> number is incremented when the changes made to the |
---|
| 576 | protocol add features which do not change the general message parsing |
---|
| 577 | algorithm, but which may add to the message semantics and imply |
---|
| 578 | additional capabilities of the sender. The <major> number is |
---|
| 579 | incremented when the format of a message within the protocol is |
---|
| 580 | changed. See [RFC2145] for a fuller explanation. |
---|
| 581 | |
---|
| 582 | The version of an HTTP message is indicated by an HTTP-Version field |
---|
| 583 | in the first line of the message. HTTP-Version is case-sensitive. |
---|
| 584 | |
---|
| 585 | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |
---|
| 586 | HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive |
---|
| 587 | |
---|
| 588 | Note that the major and minor numbers MUST be treated as separate |
---|
| 589 | integers and that each MAY be incremented higher than a single digit. |
---|
| 590 | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
---|
| 591 | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients |
---|
| 592 | and MUST NOT be sent. |
---|
| 593 | |
---|
| 594 | An application that sends a request or response message that includes |
---|
| 595 | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant |
---|
| 596 | with this specification. Applications that are at least |
---|
| 597 | conditionally compliant with this specification SHOULD use an HTTP- |
---|
| 598 | Version of "HTTP/1.1" in their messages, and MUST do so for any |
---|
| 599 | message that is not compatible with HTTP/1.0. For more details on |
---|
| 600 | when to send specific HTTP-Version values, see [RFC2145]. |
---|
| 601 | |
---|
| 602 | The HTTP version of an application is the highest HTTP version for |
---|
| 603 | which the application is at least conditionally compliant. |
---|
| 604 | |
---|
| 605 | Proxy and gateway applications need to be careful when forwarding |
---|
| 606 | messages in protocol versions different from that of the application. |
---|
| 607 | Since the protocol version indicates the protocol capability of the |
---|
| 608 | sender, a proxy/gateway MUST NOT send a message with a version |
---|
| 609 | indicator which is greater than its actual version. If a higher |
---|
| 610 | version request is received, the proxy/gateway MUST either downgrade |
---|
| 611 | the request version, or respond with an error, or switch to tunnel |
---|
| 612 | |
---|
| 613 | |
---|
| 614 | |
---|
| 615 | Fielding, et al. Expires May 20, 2009 [Page 11] |
---|
| 616 | |
---|
| 617 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 618 | |
---|
| 619 | |
---|
| 620 | behavior. |
---|
| 621 | |
---|
| 622 | Due to interoperability problems with HTTP/1.0 proxies discovered |
---|
| 623 | since the publication of [RFC2068], caching proxies MUST, gateways |
---|
| 624 | MAY, and tunnels MUST NOT upgrade the request to the highest version |
---|
| 625 | they support. The proxy/gateway's response to that request MUST be |
---|
| 626 | in the same major version as the request. |
---|
| 627 | |
---|
| 628 | Note: Converting between versions of HTTP may involve modification |
---|
| 629 | of header fields required or forbidden by the versions involved. |
---|
| 630 | |
---|
| 631 | 3.2. Uniform Resource Identifiers |
---|
| 632 | |
---|
| 633 | Uniform Resource Identifiers (URIs) [RFC3986] are used in HTTP to |
---|
| 634 | indicate the target of a request and to identify additional resources |
---|
| 635 | related to that resource, the request, or the response. Each |
---|
| 636 | protocol element in HTTP that allows a URI reference will indicate in |
---|
| 637 | its ABNF whether the element allows only a URI in absolute form, any |
---|
| 638 | relative reference, or some limited subset of the URI-reference |
---|
| 639 | grammar. Unless otherwise indicated, relative URI references are to |
---|
| 640 | be parsed relative to the URI corresponding to the request target |
---|
| 641 | (the base URI). |
---|
| 642 | |
---|
| 643 | This specification adopts the definitions of "URI-reference", |
---|
| 644 | "absolute-URI", "fragment", "port", "host", "path-abempty", "path- |
---|
| 645 | absolute", "query", and "authority" from [RFC3986]: |
---|
| 646 | |
---|
| 647 | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
---|
| 648 | authority = <authority, defined in [RFC3986], Section 3.2> |
---|
| 649 | fragment = <fragment, defined in [RFC3986], Section 3.5> |
---|
| 650 | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
---|
| 651 | path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |
---|
| 652 | port = <port, defined in [RFC3986], Section 3.2.3> |
---|
| 653 | query = <query, defined in [RFC3986], Section 3.4> |
---|
| 654 | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
---|
| 655 | |
---|
| 656 | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
---|
| 657 | relativeURI = relative-part [ "?" query ] |
---|
| 658 | |
---|
| 659 | HTTP does not place an a priori limit on the length of a URI. |
---|
| 660 | Servers MUST be able to handle the URI of any resource they serve, |
---|
| 661 | and SHOULD be able to handle URIs of unbounded length if they provide |
---|
| 662 | GET-based forms that could generate such URIs. A server SHOULD |
---|
| 663 | return 414 (Request-URI Too Long) status if a URI is longer than the |
---|
| 664 | server can handle (see Section 9.4.15 of [Part2]). |
---|
| 665 | |
---|
| 666 | |
---|
| 667 | |
---|
| 668 | |
---|
| 669 | |
---|
| 670 | |
---|
| 671 | Fielding, et al. Expires May 20, 2009 [Page 12] |
---|
| 672 | |
---|
| 673 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 674 | |
---|
| 675 | |
---|
| 676 | Note: Servers ought to be cautious about depending on URI lengths |
---|
| 677 | above 255 bytes, because some older client or proxy |
---|
| 678 | implementations might not properly support these lengths. |
---|
| 679 | |
---|
| 680 | 3.2.1. http URI scheme |
---|
| 681 | |
---|
| 682 | The "http" scheme is used to locate network resources via the HTTP |
---|
| 683 | protocol. This section defines the syntax and semantics for |
---|
| 684 | identifiers using the http or https URI schemes. |
---|
| 685 | |
---|
| 686 | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
---|
| 687 | |
---|
| 688 | If the port is empty or not given, port 80 is assumed. The semantics |
---|
| 689 | are that the identified resource is located at the server listening |
---|
| 690 | for TCP connections on that port of that host, and the Request-URI |
---|
| 691 | for the resource is path-absolute (Section 5.1.2). The use of IP |
---|
| 692 | addresses in URLs SHOULD be avoided whenever possible (see |
---|
| 693 | [RFC1900]). If the path-absolute is not present in the URL, it MUST |
---|
| 694 | be given as "/" when used as a Request-URI for a resource |
---|
| 695 | (Section 5.1.2). If a proxy receives a host name which is not a |
---|
| 696 | fully qualified domain name, it MAY add its domain to the host name |
---|
| 697 | it received. If a proxy receives a fully qualified domain name, the |
---|
| 698 | proxy MUST NOT change the host name. |
---|
| 699 | |
---|
| 700 | Note: the "https" scheme is defined in [RFC2818]. |
---|
| 701 | |
---|
| 702 | 3.2.2. URI Comparison |
---|
| 703 | |
---|
| 704 | When comparing two URIs to decide if they match or not, a client |
---|
| 705 | SHOULD use a case-sensitive octet-by-octet comparison of the entire |
---|
| 706 | URIs, with these exceptions: |
---|
| 707 | |
---|
| 708 | o A port that is empty or not given is equivalent to the default |
---|
| 709 | port for that URI-reference; |
---|
| 710 | |
---|
| 711 | o Comparisons of host names MUST be case-insensitive; |
---|
| 712 | |
---|
| 713 | o Comparisons of scheme names MUST be case-insensitive; |
---|
| 714 | |
---|
| 715 | o An empty path-absolute is equivalent to an path-absolute of "/". |
---|
| 716 | |
---|
| 717 | Characters other than those in the "reserved" set (see [RFC3986], |
---|
| 718 | Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding. |
---|
| 719 | |
---|
| 720 | For example, the following three URIs are equivalent: |
---|
| 721 | |
---|
| 722 | http://example.com:80/~smith/home.html |
---|
| 723 | http://EXAMPLE.com/%7Esmith/home.html |
---|
| 724 | |
---|
| 725 | |
---|
| 726 | |
---|
| 727 | Fielding, et al. Expires May 20, 2009 [Page 13] |
---|
| 728 | |
---|
| 729 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 730 | |
---|
| 731 | |
---|
| 732 | http://EXAMPLE.com:/%7esmith/home.html |
---|
| 733 | |
---|
| 734 | 3.3. Date/Time Formats |
---|
| 735 | |
---|
| 736 | 3.3.1. Full Date |
---|
| 737 | |
---|
| 738 | HTTP applications have historically allowed three different formats |
---|
| 739 | for the representation of date/time stamps: |
---|
| 740 | |
---|
| 741 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |
---|
| 742 | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
---|
| 743 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
---|
| 744 | |
---|
| 745 | The first format is preferred as an Internet standard and represents |
---|
| 746 | a fixed-length subset of that defined by [RFC1123] (an update to |
---|
| 747 | [RFC822]). The other formats are described here only for |
---|
| 748 | compatibility with obsolete implementations. HTTP/1.1 clients and |
---|
| 749 | servers that parse the date value MUST accept all three formats (for |
---|
| 750 | compatibility with HTTP/1.0), though they MUST only generate the RFC |
---|
| 751 | 1123 format for representing HTTP-date values in header fields. See |
---|
| 752 | Appendix A for further information. |
---|
| 753 | |
---|
| 754 | Note: Recipients of date values are encouraged to be robust in |
---|
| 755 | accepting date values that may have been sent by non-HTTP |
---|
| 756 | applications, as is sometimes the case when retrieving or posting |
---|
| 757 | messages via proxies/gateways to SMTP or NNTP. |
---|
| 758 | |
---|
| 759 | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
---|
| 760 | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
---|
| 761 | equal to UTC (Coordinated Universal Time). This is indicated in the |
---|
| 762 | first two formats by the inclusion of "GMT" as the three-letter |
---|
| 763 | abbreviation for time zone, and MUST be assumed when reading the |
---|
| 764 | asctime format. HTTP-date is case sensitive and MUST NOT include |
---|
| 765 | additional LWS beyond that specifically included as SP in the |
---|
| 766 | grammar. |
---|
| 767 | |
---|
| 768 | HTTP-date = rfc1123-date / obsolete-date |
---|
| 769 | obsolete-date = rfc850-date / asctime-date |
---|
| 770 | rfc1123-date = wkday "," SP date1 SP time SP GMT |
---|
| 771 | rfc850-date = weekday "," SP date2 SP time SP GMT |
---|
| 772 | asctime-date = wkday SP date3 SP time SP 4DIGIT |
---|
| 773 | date1 = 2DIGIT SP month SP 4DIGIT |
---|
| 774 | ; day month year (e.g., 02 Jun 1982) |
---|
| 775 | date2 = 2DIGIT "-" month "-" 2DIGIT |
---|
| 776 | ; day-month-year (e.g., 02-Jun-82) |
---|
| 777 | date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |
---|
| 778 | ; month day (e.g., Jun 2) |
---|
| 779 | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
---|
| 780 | |
---|
| 781 | |
---|
| 782 | |
---|
| 783 | Fielding, et al. Expires May 20, 2009 [Page 14] |
---|
| 784 | |
---|
| 785 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 786 | |
---|
| 787 | |
---|
| 788 | ; 00:00:00 - 23:59:59 |
---|
| 789 | wkday = s-Mon / s-Tue / s-Wed |
---|
| 790 | / s-Thu / s-Fri / s-Sat / s-Sun |
---|
| 791 | weekday = l-Mon / l-Tue / l-Wed |
---|
| 792 | / l-Thu / l-Fri / l-Sat / l-Sun |
---|
| 793 | month = s-Jan / s-Feb / s-Mar / s-Apr |
---|
| 794 | / s-May / s-Jun / s-Jul / s-Aug |
---|
| 795 | / s-Sep / s-Oct / s-Nov / s-Dec |
---|
| 796 | |
---|
| 797 | GMT = %x47.4D.54 ; "GMT", case-sensitive |
---|
| 798 | |
---|
| 799 | s-Mon = %x4D.6F.6E ; "Mon", case-sensitive |
---|
| 800 | s-Tue = %x54.75.65 ; "Tue", case-sensitive |
---|
| 801 | s-Wed = %x57.65.64 ; "Wed", case-sensitive |
---|
| 802 | s-Thu = %x54.68.75 ; "Thu", case-sensitive |
---|
| 803 | s-Fri = %x46.72.69 ; "Fri", case-sensitive |
---|
| 804 | s-Sat = %x53.61.74 ; "Sat", case-sensitive |
---|
| 805 | s-Sun = %x53.75.6E ; "Sun", case-sensitive |
---|
| 806 | |
---|
| 807 | l-Mon = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |
---|
| 808 | l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |
---|
| 809 | l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |
---|
| 810 | l-Thu = %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |
---|
| 811 | l-Fri = %x46.72.69.64.61.79 ; "Friday", case-sensitive |
---|
| 812 | l-Sat = %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |
---|
| 813 | l-Sun = %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |
---|
| 814 | |
---|
| 815 | s-Jan = %x4A.61.6E ; "Jan", case-sensitive |
---|
| 816 | s-Feb = %x46.65.62 ; "Feb", case-sensitive |
---|
| 817 | s-Mar = %x4D.61.72 ; "Mar", case-sensitive |
---|
| 818 | s-Apr = %x41.70.72 ; "Apr", case-sensitive |
---|
| 819 | s-May = %x4D.61.79 ; "May", case-sensitive |
---|
| 820 | s-Jun = %x4A.75.6E ; "Jun", case-sensitive |
---|
| 821 | s-Jul = %x4A.75.6C ; "Jul", case-sensitive |
---|
| 822 | s-Aug = %x41.75.67 ; "Aug", case-sensitive |
---|
| 823 | s-Sep = %x53.65.70 ; "Sep", case-sensitive |
---|
| 824 | s-Oct = %x4F.63.74 ; "Oct", case-sensitive |
---|
| 825 | s-Nov = %x4E.6F.76 ; "Nov", case-sensitive |
---|
| 826 | s-Dec = %x44.65.63 ; "Dec", case-sensitive |
---|
| 827 | |
---|
| 828 | Note: HTTP requirements for the date/time stamp format apply only to |
---|
| 829 | their usage within the protocol stream. Clients and servers are not |
---|
| 830 | required to use these formats for user presentation, request logging, |
---|
| 831 | etc. |
---|
| 832 | |
---|
| 833 | |
---|
| 834 | |
---|
| 835 | |
---|
| 836 | |
---|
| 837 | |
---|
| 838 | |
---|
| 839 | Fielding, et al. Expires May 20, 2009 [Page 15] |
---|
| 840 | |
---|
| 841 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 842 | |
---|
| 843 | |
---|
| 844 | 3.4. Transfer Codings |
---|
| 845 | |
---|
| 846 | Transfer-coding values are used to indicate an encoding |
---|
| 847 | transformation that has been, can be, or may need to be applied to an |
---|
| 848 | entity-body in order to ensure "safe transport" through the network. |
---|
| 849 | This differs from a content coding in that the transfer-coding is a |
---|
| 850 | property of the message, not of the original entity. |
---|
| 851 | |
---|
| 852 | transfer-coding = "chunked" / transfer-extension |
---|
| 853 | transfer-extension = token *( OWS ";" OWS parameter ) |
---|
| 854 | |
---|
| 855 | Parameters are in the form of attribute/value pairs. |
---|
| 856 | |
---|
| 857 | parameter = attribute BWS "=" BWS value |
---|
| 858 | attribute = token |
---|
| 859 | value = token / quoted-string |
---|
| 860 | |
---|
| 861 | All transfer-coding values are case-insensitive. HTTP/1.1 uses |
---|
| 862 | transfer-coding values in the TE header field (Section 8.5) and in |
---|
| 863 | the Transfer-Encoding header field (Section 8.7). |
---|
| 864 | |
---|
| 865 | Whenever a transfer-coding is applied to a message-body, the set of |
---|
| 866 | transfer-codings MUST include "chunked", unless the message indicates |
---|
| 867 | it is terminated by closing the connection. When the "chunked" |
---|
| 868 | transfer-coding is used, it MUST be the last transfer-coding applied |
---|
| 869 | to the message-body. The "chunked" transfer-coding MUST NOT be |
---|
| 870 | applied more than once to a message-body. These rules allow the |
---|
| 871 | recipient to determine the transfer-length of the message |
---|
| 872 | (Section 4.4). |
---|
| 873 | |
---|
| 874 | Transfer-codings are analogous to the Content-Transfer-Encoding |
---|
| 875 | values of MIME [RFC2045], which were designed to enable safe |
---|
| 876 | transport of binary data over a 7-bit transport service. However, |
---|
| 877 | safe transport has a different focus for an 8bit-clean transfer |
---|
| 878 | protocol. In HTTP, the only unsafe characteristic of message-bodies |
---|
| 879 | is the difficulty in determining the exact body length (Section 4.4), |
---|
| 880 | or the desire to encrypt data over a shared transport. |
---|
| 881 | |
---|
| 882 | The Internet Assigned Numbers Authority (IANA) acts as a registry for |
---|
| 883 | transfer-coding value tokens. Initially, the registry contains the |
---|
| 884 | following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and |
---|
| 885 | "deflate" (Section 3.2 of [Part3]). |
---|
| 886 | |
---|
| 887 | New transfer-coding value tokens SHOULD be registered in the same way |
---|
| 888 | as new content-coding value tokens (Section 3.2 of [Part3]). |
---|
| 889 | |
---|
| 890 | A server which receives an entity-body with a transfer-coding it does |
---|
| 891 | not understand SHOULD return 501 (Not Implemented), and close the |
---|
| 892 | |
---|
| 893 | |
---|
| 894 | |
---|
| 895 | Fielding, et al. Expires May 20, 2009 [Page 16] |
---|
| 896 | |
---|
| 897 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 898 | |
---|
| 899 | |
---|
| 900 | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |
---|
| 901 | client. |
---|
| 902 | |
---|
| 903 | 3.4.1. Chunked Transfer Coding |
---|
| 904 | |
---|
| 905 | The chunked encoding modifies the body of a message in order to |
---|
| 906 | transfer it as a series of chunks, each with its own size indicator, |
---|
| 907 | followed by an OPTIONAL trailer containing entity-header fields. |
---|
| 908 | This allows dynamically produced content to be transferred along with |
---|
| 909 | the information necessary for the recipient to verify that it has |
---|
| 910 | received the full message. |
---|
| 911 | |
---|
| 912 | Chunked-Body = *chunk |
---|
| 913 | last-chunk |
---|
| 914 | trailer-part |
---|
| 915 | CRLF |
---|
| 916 | |
---|
| 917 | chunk = chunk-size *WSP [ chunk-ext ] CRLF |
---|
| 918 | chunk-data CRLF |
---|
| 919 | chunk-size = 1*HEXDIG |
---|
| 920 | last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF |
---|
| 921 | |
---|
| 922 | chunk-ext = *( ";" *WSP chunk-ext-name |
---|
| 923 | [ "=" chunk-ext-val ] *WSP ) |
---|
| 924 | chunk-ext-name = token |
---|
| 925 | chunk-ext-val = token / quoted-string |
---|
| 926 | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
---|
| 927 | trailer-part = *(entity-header CRLF) |
---|
| 928 | |
---|
| 929 | The chunk-size field is a string of hex digits indicating the size of |
---|
| 930 | the chunk-data in octets. The chunked encoding is ended by any chunk |
---|
| 931 | whose size is zero, followed by the trailer, which is terminated by |
---|
| 932 | an empty line. |
---|
| 933 | |
---|
| 934 | The trailer allows the sender to include additional HTTP header |
---|
| 935 | fields at the end of the message. The Trailer header field can be |
---|
| 936 | used to indicate which header fields are included in a trailer (see |
---|
| 937 | Section 8.6). |
---|
| 938 | |
---|
| 939 | A server using chunked transfer-coding in a response MUST NOT use the |
---|
| 940 | trailer for any header fields unless at least one of the following is |
---|
| 941 | true: |
---|
| 942 | |
---|
| 943 | 1. the request included a TE header field that indicates "trailers" |
---|
| 944 | is acceptable in the transfer-coding of the response, as |
---|
| 945 | described in Section 8.5; or, |
---|
| 946 | |
---|
| 947 | |
---|
| 948 | |
---|
| 949 | |
---|
| 950 | |
---|
| 951 | Fielding, et al. Expires May 20, 2009 [Page 17] |
---|
| 952 | |
---|
| 953 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 954 | |
---|
| 955 | |
---|
| 956 | 2. the server is the origin server for the response, the trailer |
---|
| 957 | fields consist entirely of optional metadata, and the recipient |
---|
| 958 | could use the message (in a manner acceptable to the origin |
---|
| 959 | server) without receiving this metadata. In other words, the |
---|
| 960 | origin server is willing to accept the possibility that the |
---|
| 961 | trailer fields might be silently discarded along the path to the |
---|
| 962 | client. |
---|
| 963 | |
---|
| 964 | This requirement prevents an interoperability failure when the |
---|
| 965 | message is being received by an HTTP/1.1 (or later) proxy and |
---|
| 966 | forwarded to an HTTP/1.0 recipient. It avoids a situation where |
---|
| 967 | compliance with the protocol would have necessitated a possibly |
---|
| 968 | infinite buffer on the proxy. |
---|
| 969 | |
---|
| 970 | A process for decoding the "chunked" transfer-coding can be |
---|
| 971 | represented in pseudo-code as: |
---|
| 972 | |
---|
| 973 | length := 0 |
---|
| 974 | read chunk-size, chunk-ext (if any) and CRLF |
---|
| 975 | while (chunk-size > 0) { |
---|
| 976 | read chunk-data and CRLF |
---|
| 977 | append chunk-data to entity-body |
---|
| 978 | length := length + chunk-size |
---|
| 979 | read chunk-size and CRLF |
---|
| 980 | } |
---|
| 981 | read entity-header |
---|
| 982 | while (entity-header not empty) { |
---|
| 983 | append entity-header to existing header fields |
---|
| 984 | read entity-header |
---|
| 985 | } |
---|
| 986 | Content-Length := length |
---|
| 987 | Remove "chunked" from Transfer-Encoding |
---|
| 988 | |
---|
| 989 | All HTTP/1.1 applications MUST be able to receive and decode the |
---|
| 990 | "chunked" transfer-coding, and MUST ignore chunk-ext extensions they |
---|
| 991 | do not understand. |
---|
| 992 | |
---|
| 993 | 3.5. Product Tokens |
---|
| 994 | |
---|
| 995 | Product tokens are used to allow communicating applications to |
---|
| 996 | identify themselves by software name and version. Most fields using |
---|
| 997 | product tokens also allow sub-products which form a significant part |
---|
| 998 | of the application to be listed, separated by white space. By |
---|
| 999 | convention, the products are listed in order of their significance |
---|
| 1000 | for identifying the application. |
---|
| 1001 | |
---|
| 1002 | product = token ["/" product-version] |
---|
| 1003 | product-version = token |
---|
| 1004 | |
---|
| 1005 | |
---|
| 1006 | |
---|
| 1007 | Fielding, et al. Expires May 20, 2009 [Page 18] |
---|
| 1008 | |
---|
| 1009 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1010 | |
---|
| 1011 | |
---|
| 1012 | Examples: |
---|
| 1013 | |
---|
| 1014 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
| 1015 | Server: Apache/0.8.4 |
---|
| 1016 | |
---|
| 1017 | Product tokens SHOULD be short and to the point. They MUST NOT be |
---|
| 1018 | used for advertising or other non-essential information. Although |
---|
| 1019 | any token character MAY appear in a product-version, this token |
---|
| 1020 | SHOULD only be used for a version identifier (i.e., successive |
---|
| 1021 | versions of the same product SHOULD only differ in the product- |
---|
| 1022 | version portion of the product value). |
---|
| 1023 | |
---|
| 1024 | |
---|
| 1025 | 4. HTTP Message |
---|
| 1026 | |
---|
| 1027 | 4.1. Message Types |
---|
| 1028 | |
---|
| 1029 | HTTP messages consist of requests from client to server and responses |
---|
| 1030 | from server to client. |
---|
| 1031 | |
---|
| 1032 | HTTP-message = Request / Response ; HTTP/1.1 messages |
---|
| 1033 | |
---|
| 1034 | Request (Section 5) and Response (Section 6) messages use the generic |
---|
| 1035 | message format of [RFC5322] for transferring entities (the payload of |
---|
| 1036 | the message). Both types of message consist of a start-line, zero or |
---|
| 1037 | more header fields (also known as "headers"), an empty line (i.e., a |
---|
| 1038 | line with nothing preceding the CRLF) indicating the end of the |
---|
| 1039 | header fields, and possibly a message-body. |
---|
| 1040 | |
---|
| 1041 | generic-message = start-line |
---|
| 1042 | *(message-header CRLF) |
---|
| 1043 | CRLF |
---|
| 1044 | [ message-body ] |
---|
| 1045 | start-line = Request-Line / Status-Line |
---|
| 1046 | |
---|
| 1047 | In the interest of robustness, servers SHOULD ignore any empty |
---|
| 1048 | line(s) received where a Request-Line is expected. In other words, |
---|
| 1049 | if the server is reading the protocol stream at the beginning of a |
---|
| 1050 | message and receives a CRLF first, it should ignore the CRLF. |
---|
| 1051 | |
---|
| 1052 | Certain buggy HTTP/1.0 client implementations generate extra CRLF's |
---|
| 1053 | after a POST request. To restate what is explicitly forbidden by the |
---|
| 1054 | BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an |
---|
| 1055 | extra CRLF. |
---|
| 1056 | |
---|
| 1057 | |
---|
| 1058 | |
---|
| 1059 | |
---|
| 1060 | |
---|
| 1061 | |
---|
| 1062 | |
---|
| 1063 | Fielding, et al. Expires May 20, 2009 [Page 19] |
---|
| 1064 | |
---|
| 1065 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1066 | |
---|
| 1067 | |
---|
| 1068 | 4.2. Message Headers |
---|
| 1069 | |
---|
| 1070 | HTTP header fields, which include general-header (Section 4.5), |
---|
| 1071 | request-header (Section 4 of [Part2]), response-header (Section 6 of |
---|
| 1072 | [Part2]), and entity-header (Section 4.1 of [Part3]) fields, follow |
---|
| 1073 | the same generic format as that given in Section 2.1 of [RFC5322]. |
---|
| 1074 | Each header field consists of a name followed by a colon (":") and |
---|
| 1075 | the field value. Field names are case-insensitive. The field value |
---|
| 1076 | MAY be preceded by any amount of LWS, though a single SP is |
---|
| 1077 | preferred. Header fields can be extended over multiple lines by |
---|
| 1078 | preceding each extra line with at least one SP or HTAB. Applications |
---|
| 1079 | ought to follow "common form", where one is known or indicated, when |
---|
| 1080 | generating HTTP constructs, since there might exist some |
---|
| 1081 | implementations that fail to accept anything beyond the common forms. |
---|
| 1082 | |
---|
| 1083 | message-header = field-name ":" [ field-value ] |
---|
| 1084 | field-name = token |
---|
| 1085 | field-value = *( field-content / OWS ) |
---|
| 1086 | field-content = <field content> |
---|
| 1087 | |
---|
| 1088 | [[anchor1: whitespace between field-name and colon is an error and |
---|
| 1089 | MUST NOT be accepted]] |
---|
| 1090 | |
---|
| 1091 | The field-content does not include any leading or trailing LWS: |
---|
| 1092 | linear white space occurring before the first non-whitespace |
---|
| 1093 | character of the field-value or after the last non-whitespace |
---|
| 1094 | character of the field-value. Such leading or trailing LWS MAY be |
---|
| 1095 | removed without changing the semantics of the field value. Any LWS |
---|
| 1096 | that occurs between field-content MAY be replaced with a single SP |
---|
| 1097 | before interpreting the field value or forwarding the message |
---|
| 1098 | downstream. |
---|
| 1099 | |
---|
| 1100 | The order in which header fields with differing field names are |
---|
| 1101 | received is not significant. However, it is "good practice" to send |
---|
| 1102 | general-header fields first, followed by request-header or response- |
---|
| 1103 | header fields, and ending with the entity-header fields. |
---|
| 1104 | |
---|
| 1105 | Multiple message-header fields with the same field-name MAY be |
---|
| 1106 | present in a message if and only if the entire field-value for that |
---|
| 1107 | header field is defined as a comma-separated list [i.e., #(values)]. |
---|
| 1108 | It MUST be possible to combine the multiple header fields into one |
---|
| 1109 | "field-name: field-value" pair, without changing the semantics of the |
---|
| 1110 | message, by appending each subsequent field-value to the first, each |
---|
| 1111 | separated by a comma. The order in which header fields with the same |
---|
| 1112 | field-name are received is therefore significant to the |
---|
| 1113 | interpretation of the combined field value, and thus a proxy MUST NOT |
---|
| 1114 | change the order of these field values when a message is forwarded. |
---|
| 1115 | |
---|
| 1116 | |
---|
| 1117 | |
---|
| 1118 | |
---|
| 1119 | Fielding, et al. Expires May 20, 2009 [Page 20] |
---|
| 1120 | |
---|
| 1121 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1122 | |
---|
| 1123 | |
---|
| 1124 | Note: the "Set-Cookie" header as implemented in practice (as |
---|
| 1125 | opposed to how it is specified in [RFC2109]) can occur multiple |
---|
| 1126 | times, but does not use the list syntax, and thus cannot be |
---|
| 1127 | combined into a single line. (See Appendix A.2.3 of [Kri2001] for |
---|
| 1128 | details.) Also note that the Set-Cookie2 header specified in |
---|
| 1129 | [RFC2965] does not share this problem. |
---|
| 1130 | |
---|
| 1131 | 4.3. Message Body |
---|
| 1132 | |
---|
| 1133 | The message-body (if any) of an HTTP message is used to carry the |
---|
| 1134 | entity-body associated with the request or response. The message- |
---|
| 1135 | body differs from the entity-body only when a transfer-coding has |
---|
| 1136 | been applied, as indicated by the Transfer-Encoding header field |
---|
| 1137 | (Section 8.7). |
---|
| 1138 | |
---|
| 1139 | message-body = entity-body |
---|
| 1140 | / <entity-body encoded as per Transfer-Encoding> |
---|
| 1141 | |
---|
| 1142 | Transfer-Encoding MUST be used to indicate any transfer-codings |
---|
| 1143 | applied by an application to ensure safe and proper transfer of the |
---|
| 1144 | message. Transfer-Encoding is a property of the message, not of the |
---|
| 1145 | entity, and thus MAY be added or removed by any application along the |
---|
| 1146 | request/response chain. (However, Section 3.4 places restrictions on |
---|
| 1147 | when certain transfer-codings may be used.) |
---|
| 1148 | |
---|
| 1149 | The rules for when a message-body is allowed in a message differ for |
---|
| 1150 | requests and responses. |
---|
| 1151 | |
---|
| 1152 | The presence of a message-body in a request is signaled by the |
---|
| 1153 | inclusion of a Content-Length or Transfer-Encoding header field in |
---|
| 1154 | the request's message-headers. A message-body MUST NOT be included |
---|
| 1155 | in a request if the specification of the request method (Section 3 of |
---|
| 1156 | [Part2]) explicitly disallows an entity-body in requests. When a |
---|
| 1157 | request message contains both a message-body of non-zero length and a |
---|
| 1158 | method that does not define any semantics for that request message- |
---|
| 1159 | body, then an origin server SHOULD either ignore the message-body or |
---|
| 1160 | respond with an appropriate error message (e.g., 413). A proxy or |
---|
| 1161 | gateway, when presented the same request, SHOULD either forward the |
---|
| 1162 | request inbound with the message-body or ignore the message-body when |
---|
| 1163 | determining a response. |
---|
| 1164 | |
---|
| 1165 | For response messages, whether or not a message-body is included with |
---|
| 1166 | a message is dependent on both the request method and the response |
---|
| 1167 | status code (Section 6.1.1). All responses to the HEAD request |
---|
| 1168 | method MUST NOT include a message-body, even though the presence of |
---|
| 1169 | entity-header fields might lead one to believe they do. All 1xx |
---|
| 1170 | (informational), 204 (No Content), and 304 (Not Modified) responses |
---|
| 1171 | MUST NOT include a message-body. All other responses do include a |
---|
| 1172 | |
---|
| 1173 | |
---|
| 1174 | |
---|
| 1175 | Fielding, et al. Expires May 20, 2009 [Page 21] |
---|
| 1176 | |
---|
| 1177 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1178 | |
---|
| 1179 | |
---|
| 1180 | message-body, although it MAY be of zero length. |
---|
| 1181 | |
---|
| 1182 | 4.4. Message Length |
---|
| 1183 | |
---|
| 1184 | The transfer-length of a message is the length of the message-body as |
---|
| 1185 | it appears in the message; that is, after any transfer-codings have |
---|
| 1186 | been applied. When a message-body is included with a message, the |
---|
| 1187 | transfer-length of that body is determined by one of the following |
---|
| 1188 | (in order of precedence): |
---|
| 1189 | |
---|
| 1190 | 1. Any response message which "MUST NOT" include a message-body |
---|
| 1191 | (such as the 1xx, 204, and 304 responses and any response to a |
---|
| 1192 | HEAD request) is always terminated by the first empty line after |
---|
| 1193 | the header fields, regardless of the entity-header fields present |
---|
| 1194 | in the message. |
---|
| 1195 | |
---|
| 1196 | 2. If a Transfer-Encoding header field (Section 8.7) is present and |
---|
| 1197 | the "chunked" transfer-coding (Section 3.4) is used, the |
---|
| 1198 | transfer-length is defined by the use of this transfer-coding. |
---|
| 1199 | If a Transfer-Encoding header field is present and the "chunked" |
---|
| 1200 | transfer-coding is not present, the transfer-length is defined by |
---|
| 1201 | the sender closing the connection. |
---|
| 1202 | |
---|
| 1203 | 3. If a Content-Length header field (Section 8.2) is present, its |
---|
| 1204 | decimal value in OCTETs represents both the entity-length and the |
---|
| 1205 | transfer-length. The Content-Length header field MUST NOT be |
---|
| 1206 | sent if these two lengths are different (i.e., if a Transfer- |
---|
| 1207 | Encoding header field is present). If a message is received with |
---|
| 1208 | both a Transfer-Encoding header field and a Content-Length header |
---|
| 1209 | field, the latter MUST be ignored. |
---|
| 1210 | |
---|
| 1211 | 4. If the message uses the media type "multipart/byteranges", and |
---|
| 1212 | the transfer-length is not otherwise specified, then this self- |
---|
| 1213 | delimiting media type defines the transfer-length. This media |
---|
| 1214 | type MUST NOT be used unless the sender knows that the recipient |
---|
| 1215 | can parse it; the presence in a request of a Range header with |
---|
| 1216 | multiple byte-range specifiers from a 1.1 client implies that the |
---|
| 1217 | client can parse multipart/byteranges responses. |
---|
| 1218 | |
---|
| 1219 | A range header might be forwarded by a 1.0 proxy that does not |
---|
| 1220 | understand multipart/byteranges; in this case the server MUST |
---|
| 1221 | delimit the message using methods defined in items 1, 3 or 5 |
---|
| 1222 | of this section. |
---|
| 1223 | |
---|
| 1224 | 5. By the server closing the connection. (Closing the connection |
---|
| 1225 | cannot be used to indicate the end of a request body, since that |
---|
| 1226 | would leave no possibility for the server to send back a |
---|
| 1227 | response.) |
---|
| 1228 | |
---|
| 1229 | |
---|
| 1230 | |
---|
| 1231 | Fielding, et al. Expires May 20, 2009 [Page 22] |
---|
| 1232 | |
---|
| 1233 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1234 | |
---|
| 1235 | |
---|
| 1236 | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |
---|
| 1237 | containing a message-body MUST include a valid Content-Length header |
---|
| 1238 | field unless the server is known to be HTTP/1.1 compliant. If a |
---|
| 1239 | request contains a message-body and a Content-Length is not given, |
---|
| 1240 | the server SHOULD respond with 400 (Bad Request) if it cannot |
---|
| 1241 | determine the length of the message, or with 411 (Length Required) if |
---|
| 1242 | it wishes to insist on receiving a valid Content-Length. |
---|
| 1243 | |
---|
| 1244 | All HTTP/1.1 applications that receive entities MUST accept the |
---|
| 1245 | "chunked" transfer-coding (Section 3.4), thus allowing this mechanism |
---|
| 1246 | to be used for messages when the message length cannot be determined |
---|
| 1247 | in advance. |
---|
| 1248 | |
---|
| 1249 | Messages MUST NOT include both a Content-Length header field and a |
---|
| 1250 | transfer-coding. If the message does include a transfer-coding, the |
---|
| 1251 | Content-Length MUST be ignored. |
---|
| 1252 | |
---|
| 1253 | When a Content-Length is given in a message where a message-body is |
---|
| 1254 | allowed, its field value MUST exactly match the number of OCTETs in |
---|
| 1255 | the message-body. HTTP/1.1 user agents MUST notify the user when an |
---|
| 1256 | invalid length is received and detected. |
---|
| 1257 | |
---|
| 1258 | 4.5. General Header Fields |
---|
| 1259 | |
---|
| 1260 | There are a few header fields which have general applicability for |
---|
| 1261 | both request and response messages, but which do not apply to the |
---|
| 1262 | entity being transferred. These header fields apply only to the |
---|
| 1263 | message being transmitted. |
---|
| 1264 | |
---|
| 1265 | general-header = Cache-Control ; [Part6], Section 16.2 |
---|
| 1266 | / Connection ; Section 8.1 |
---|
| 1267 | / Date ; Section 8.3 |
---|
| 1268 | / Pragma ; [Part6], Section 16.4 |
---|
| 1269 | / Trailer ; Section 8.6 |
---|
| 1270 | / Transfer-Encoding ; Section 8.7 |
---|
| 1271 | / Upgrade ; Section 8.8 |
---|
| 1272 | / Via ; Section 8.9 |
---|
| 1273 | / Warning ; [Part6], Section 16.6 |
---|
| 1274 | |
---|
| 1275 | General-header field names can be extended reliably only in |
---|
| 1276 | combination with a change in the protocol version. However, new or |
---|
| 1277 | experimental header fields may be given the semantics of general |
---|
| 1278 | header fields if all parties in the communication recognize them to |
---|
| 1279 | be general-header fields. Unrecognized header fields are treated as |
---|
| 1280 | entity-header fields. |
---|
| 1281 | |
---|
| 1282 | |
---|
| 1283 | |
---|
| 1284 | |
---|
| 1285 | |
---|
| 1286 | |
---|
| 1287 | Fielding, et al. Expires May 20, 2009 [Page 23] |
---|
| 1288 | |
---|
| 1289 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1290 | |
---|
| 1291 | |
---|
| 1292 | 5. Request |
---|
| 1293 | |
---|
| 1294 | A request message from a client to a server includes, within the |
---|
| 1295 | first line of that message, the method to be applied to the resource, |
---|
| 1296 | the identifier of the resource, and the protocol version in use. |
---|
| 1297 | |
---|
| 1298 | Request = Request-Line ; Section 5.1 |
---|
| 1299 | *(( general-header ; Section 4.5 |
---|
| 1300 | / request-header ; [Part2], Section 4 |
---|
| 1301 | / entity-header ) CRLF) ; [Part3], Section 4.1 |
---|
| 1302 | CRLF |
---|
| 1303 | [ message-body ] ; Section 4.3 |
---|
| 1304 | |
---|
| 1305 | 5.1. Request-Line |
---|
| 1306 | |
---|
| 1307 | The Request-Line begins with a method token, followed by the Request- |
---|
| 1308 | URI and the protocol version, and ending with CRLF. The elements are |
---|
| 1309 | separated by SP characters. No CR or LF is allowed except in the |
---|
| 1310 | final CRLF sequence. |
---|
| 1311 | |
---|
| 1312 | Request-Line = Method SP Request-URI SP HTTP-Version CRLF |
---|
| 1313 | |
---|
| 1314 | 5.1.1. Method |
---|
| 1315 | |
---|
| 1316 | The Method token indicates the method to be performed on the resource |
---|
| 1317 | identified by the Request-URI. The method is case-sensitive. |
---|
| 1318 | |
---|
| 1319 | Method = token |
---|
| 1320 | |
---|
| 1321 | 5.1.2. Request-URI |
---|
| 1322 | |
---|
| 1323 | The Request-URI is a Uniform Resource Identifier (Section 3.2) and |
---|
| 1324 | identifies the resource upon which to apply the request. |
---|
| 1325 | |
---|
| 1326 | Request-URI = "*" |
---|
| 1327 | / absolute-URI |
---|
| 1328 | / ( path-absolute [ "?" query ] ) |
---|
| 1329 | / authority |
---|
| 1330 | |
---|
| 1331 | The four options for Request-URI are dependent on the nature of the |
---|
| 1332 | request. The asterisk "*" means that the request does not apply to a |
---|
| 1333 | particular resource, but to the server itself, and is only allowed |
---|
| 1334 | when the method used does not necessarily apply to a resource. One |
---|
| 1335 | example would be |
---|
| 1336 | |
---|
| 1337 | OPTIONS * HTTP/1.1 |
---|
| 1338 | |
---|
| 1339 | The absolute-URI form is REQUIRED when the request is being made to a |
---|
| 1340 | |
---|
| 1341 | |
---|
| 1342 | |
---|
| 1343 | Fielding, et al. Expires May 20, 2009 [Page 24] |
---|
| 1344 | |
---|
| 1345 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1346 | |
---|
| 1347 | |
---|
| 1348 | proxy. The proxy is requested to forward the request or service it |
---|
| 1349 | from a valid cache, and return the response. Note that the proxy MAY |
---|
| 1350 | forward the request on to another proxy or directly to the server |
---|
| 1351 | specified by the absolute-URI. In order to avoid request loops, a |
---|
| 1352 | proxy MUST be able to recognize all of its server names, including |
---|
| 1353 | any aliases, local variations, and the numeric IP address. An |
---|
| 1354 | example Request-Line would be: |
---|
| 1355 | |
---|
| 1356 | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |
---|
| 1357 | |
---|
| 1358 | To allow for transition to absolute-URIs in all requests in future |
---|
| 1359 | versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI |
---|
| 1360 | form in requests, even though HTTP/1.1 clients will only generate |
---|
| 1361 | them in requests to proxies. |
---|
| 1362 | |
---|
| 1363 | The authority form is only used by the CONNECT method (Section 8.9 of |
---|
| 1364 | [Part2]). |
---|
| 1365 | |
---|
| 1366 | The most common form of Request-URI is that used to identify a |
---|
| 1367 | resource on an origin server or gateway. In this case the absolute |
---|
| 1368 | path of the URI MUST be transmitted (see Section 3.2.1, path- |
---|
| 1369 | absolute) as the Request-URI, and the network location of the URI |
---|
| 1370 | (authority) MUST be transmitted in a Host header field. For example, |
---|
| 1371 | a client wishing to retrieve the resource above directly from the |
---|
| 1372 | origin server would create a TCP connection to port 80 of the host |
---|
| 1373 | "www.example.org" and send the lines: |
---|
| 1374 | |
---|
| 1375 | GET /pub/WWW/TheProject.html HTTP/1.1 |
---|
| 1376 | Host: www.example.org |
---|
| 1377 | |
---|
| 1378 | followed by the remainder of the Request. Note that the absolute |
---|
| 1379 | path cannot be empty; if none is present in the original URI, it MUST |
---|
| 1380 | be given as "/" (the server root). |
---|
| 1381 | |
---|
| 1382 | The Request-URI is transmitted in the format specified in |
---|
| 1383 | Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG |
---|
| 1384 | HEXDIG" encoding ([RFC3986], Section 2.4), the origin server MUST |
---|
| 1385 | decode the Request-URI in order to properly interpret the request. |
---|
| 1386 | Servers SHOULD respond to invalid Request-URIs with an appropriate |
---|
| 1387 | status code. |
---|
| 1388 | |
---|
| 1389 | A transparent proxy MUST NOT rewrite the "path-absolute" part of the |
---|
| 1390 | received Request-URI when forwarding it to the next inbound server, |
---|
| 1391 | except as noted above to replace a null path-absolute with "/". |
---|
| 1392 | |
---|
| 1393 | Note: The "no rewrite" rule prevents the proxy from changing the |
---|
| 1394 | meaning of the request when the origin server is improperly using |
---|
| 1395 | a non-reserved URI character for a reserved purpose. Implementors |
---|
| 1396 | |
---|
| 1397 | |
---|
| 1398 | |
---|
| 1399 | Fielding, et al. Expires May 20, 2009 [Page 25] |
---|
| 1400 | |
---|
| 1401 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1402 | |
---|
| 1403 | |
---|
| 1404 | should be aware that some pre-HTTP/1.1 proxies have been known to |
---|
| 1405 | rewrite the Request-URI. |
---|
| 1406 | |
---|
| 1407 | 5.2. The Resource Identified by a Request |
---|
| 1408 | |
---|
| 1409 | The exact resource identified by an Internet request is determined by |
---|
| 1410 | examining both the Request-URI and the Host header field. |
---|
| 1411 | |
---|
| 1412 | An origin server that does not allow resources to differ by the |
---|
| 1413 | requested host MAY ignore the Host header field value when |
---|
| 1414 | determining the resource identified by an HTTP/1.1 request. (But see |
---|
| 1415 | Appendix C.1.1 for other requirements on Host support in HTTP/1.1.) |
---|
| 1416 | |
---|
| 1417 | An origin server that does differentiate resources based on the host |
---|
| 1418 | requested (sometimes referred to as virtual hosts or vanity host |
---|
| 1419 | names) MUST use the following rules for determining the requested |
---|
| 1420 | resource on an HTTP/1.1 request: |
---|
| 1421 | |
---|
| 1422 | 1. If Request-URI is an absolute-URI, the host is part of the |
---|
| 1423 | Request-URI. Any Host header field value in the request MUST be |
---|
| 1424 | ignored. |
---|
| 1425 | |
---|
| 1426 | 2. If the Request-URI is not an absolute-URI, and the request |
---|
| 1427 | includes a Host header field, the host is determined by the Host |
---|
| 1428 | header field value. |
---|
| 1429 | |
---|
| 1430 | 3. If the host as determined by rule 1 or 2 is not a valid host on |
---|
| 1431 | the server, the response MUST be a 400 (Bad Request) error |
---|
| 1432 | message. |
---|
| 1433 | |
---|
| 1434 | Recipients of an HTTP/1.0 request that lacks a Host header field MAY |
---|
| 1435 | attempt to use heuristics (e.g., examination of the URI path for |
---|
| 1436 | something unique to a particular host) in order to determine what |
---|
| 1437 | exact resource is being requested. |
---|
| 1438 | |
---|
| 1439 | |
---|
| 1440 | 6. Response |
---|
| 1441 | |
---|
| 1442 | After receiving and interpreting a request message, a server responds |
---|
| 1443 | with an HTTP response message. |
---|
| 1444 | |
---|
| 1445 | Response = Status-Line ; Section 6.1 |
---|
| 1446 | *(( general-header ; Section 4.5 |
---|
| 1447 | / response-header ; [Part2], Section 6 |
---|
| 1448 | / entity-header ) CRLF) ; [Part3], Section 4.1 |
---|
| 1449 | CRLF |
---|
| 1450 | [ message-body ] ; Section 4.3 |
---|
| 1451 | |
---|
| 1452 | |
---|
| 1453 | |
---|
| 1454 | |
---|
| 1455 | Fielding, et al. Expires May 20, 2009 [Page 26] |
---|
| 1456 | |
---|
| 1457 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1458 | |
---|
| 1459 | |
---|
| 1460 | 6.1. Status-Line |
---|
| 1461 | |
---|
| 1462 | The first line of a Response message is the Status-Line, consisting |
---|
| 1463 | of the protocol version followed by a numeric status code and its |
---|
| 1464 | associated textual phrase, with each element separated by SP |
---|
| 1465 | characters. No CR or LF is allowed except in the final CRLF |
---|
| 1466 | sequence. |
---|
| 1467 | |
---|
| 1468 | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
---|
| 1469 | |
---|
| 1470 | 6.1.1. Status Code and Reason Phrase |
---|
| 1471 | |
---|
| 1472 | The Status-Code element is a 3-digit integer result code of the |
---|
| 1473 | attempt to understand and satisfy the request. These codes are fully |
---|
| 1474 | defined in Section 9 of [Part2]. The Reason Phrase exists for the |
---|
| 1475 | sole purpose of providing a textual description associated with the |
---|
| 1476 | numeric status code, out of deference to earlier Internet application |
---|
| 1477 | protocols that were more frequently used with interactive text |
---|
| 1478 | clients. A client SHOULD ignore the content of the Reason Phrase. |
---|
| 1479 | |
---|
| 1480 | The first digit of the Status-Code defines the class of response. |
---|
| 1481 | The last two digits do not have any categorization role. There are 5 |
---|
| 1482 | values for the first digit: |
---|
| 1483 | |
---|
| 1484 | o 1xx: Informational - Request received, continuing process |
---|
| 1485 | |
---|
| 1486 | o 2xx: Success - The action was successfully received, understood, |
---|
| 1487 | and accepted |
---|
| 1488 | |
---|
| 1489 | o 3xx: Redirection - Further action must be taken in order to |
---|
| 1490 | complete the request |
---|
| 1491 | |
---|
| 1492 | o 4xx: Client Error - The request contains bad syntax or cannot be |
---|
| 1493 | fulfilled |
---|
| 1494 | |
---|
| 1495 | o 5xx: Server Error - The server failed to fulfill an apparently |
---|
| 1496 | valid request |
---|
| 1497 | |
---|
| 1498 | |
---|
| 1499 | Status-Code = 3DIGIT |
---|
| 1500 | Reason-Phrase = *<TEXT, excluding CR, LF> |
---|
| 1501 | |
---|
| 1502 | |
---|
| 1503 | 7. Connections |
---|
| 1504 | |
---|
| 1505 | |
---|
| 1506 | |
---|
| 1507 | |
---|
| 1508 | |
---|
| 1509 | |
---|
| 1510 | |
---|
| 1511 | Fielding, et al. Expires May 20, 2009 [Page 27] |
---|
| 1512 | |
---|
| 1513 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1514 | |
---|
| 1515 | |
---|
| 1516 | 7.1. Persistent Connections |
---|
| 1517 | |
---|
| 1518 | 7.1.1. Purpose |
---|
| 1519 | |
---|
| 1520 | Prior to persistent connections, a separate TCP connection was |
---|
| 1521 | established to fetch each URL, increasing the load on HTTP servers |
---|
| 1522 | and causing congestion on the Internet. The use of inline images and |
---|
| 1523 | other associated data often require a client to make multiple |
---|
| 1524 | requests of the same server in a short amount of time. Analysis of |
---|
| 1525 | these performance problems and results from a prototype |
---|
| 1526 | implementation are available [Pad1995] [Spe]. Implementation |
---|
| 1527 | experience and measurements of actual HTTP/1.1 (RFC 2068) |
---|
| 1528 | implementations show good results [Nie1997]. Alternatives have also |
---|
| 1529 | been explored, for example, T/TCP [Tou1998]. |
---|
| 1530 | |
---|
| 1531 | Persistent HTTP connections have a number of advantages: |
---|
| 1532 | |
---|
| 1533 | o By opening and closing fewer TCP connections, CPU time is saved in |
---|
| 1534 | routers and hosts (clients, servers, proxies, gateways, tunnels, |
---|
| 1535 | or caches), and memory used for TCP protocol control blocks can be |
---|
| 1536 | saved in hosts. |
---|
| 1537 | |
---|
| 1538 | o HTTP requests and responses can be pipelined on a connection. |
---|
| 1539 | Pipelining allows a client to make multiple requests without |
---|
| 1540 | waiting for each response, allowing a single TCP connection to be |
---|
| 1541 | used much more efficiently, with much lower elapsed time. |
---|
| 1542 | |
---|
| 1543 | o Network congestion is reduced by reducing the number of packets |
---|
| 1544 | caused by TCP opens, and by allowing TCP sufficient time to |
---|
| 1545 | determine the congestion state of the network. |
---|
| 1546 | |
---|
| 1547 | o Latency on subsequent requests is reduced since there is no time |
---|
| 1548 | spent in TCP's connection opening handshake. |
---|
| 1549 | |
---|
| 1550 | o HTTP can evolve more gracefully, since errors can be reported |
---|
| 1551 | without the penalty of closing the TCP connection. Clients using |
---|
| 1552 | future versions of HTTP might optimistically try a new feature, |
---|
| 1553 | but if communicating with an older server, retry with old |
---|
| 1554 | semantics after an error is reported. |
---|
| 1555 | |
---|
| 1556 | HTTP implementations SHOULD implement persistent connections. |
---|
| 1557 | |
---|
| 1558 | 7.1.2. Overall Operation |
---|
| 1559 | |
---|
| 1560 | A significant difference between HTTP/1.1 and earlier versions of |
---|
| 1561 | HTTP is that persistent connections are the default behavior of any |
---|
| 1562 | HTTP connection. That is, unless otherwise indicated, the client |
---|
| 1563 | SHOULD assume that the server will maintain a persistent connection, |
---|
| 1564 | |
---|
| 1565 | |
---|
| 1566 | |
---|
| 1567 | Fielding, et al. Expires May 20, 2009 [Page 28] |
---|
| 1568 | |
---|
| 1569 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1570 | |
---|
| 1571 | |
---|
| 1572 | even after error responses from the server. |
---|
| 1573 | |
---|
| 1574 | Persistent connections provide a mechanism by which a client and a |
---|
| 1575 | server can signal the close of a TCP connection. This signaling |
---|
| 1576 | takes place using the Connection header field (Section 8.1). Once a |
---|
| 1577 | close has been signaled, the client MUST NOT send any more requests |
---|
| 1578 | on that connection. |
---|
| 1579 | |
---|
| 1580 | 7.1.2.1. Negotiation |
---|
| 1581 | |
---|
| 1582 | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |
---|
| 1583 | maintain a persistent connection unless a Connection header including |
---|
| 1584 | the connection-token "close" was sent in the request. If the server |
---|
| 1585 | chooses to close the connection immediately after sending the |
---|
| 1586 | response, it SHOULD send a Connection header including the |
---|
| 1587 | connection-token close. |
---|
| 1588 | |
---|
| 1589 | An HTTP/1.1 client MAY expect a connection to remain open, but would |
---|
| 1590 | decide to keep it open based on whether the response from a server |
---|
| 1591 | contains a Connection header with the connection-token close. In |
---|
| 1592 | case the client does not want to maintain a connection for more than |
---|
| 1593 | that request, it SHOULD send a Connection header including the |
---|
| 1594 | connection-token close. |
---|
| 1595 | |
---|
| 1596 | If either the client or the server sends the close token in the |
---|
| 1597 | Connection header, that request becomes the last one for the |
---|
| 1598 | connection. |
---|
| 1599 | |
---|
| 1600 | Clients and servers SHOULD NOT assume that a persistent connection is |
---|
| 1601 | maintained for HTTP versions less than 1.1 unless it is explicitly |
---|
| 1602 | signaled. See Appendix C.2 for more information on backward |
---|
| 1603 | compatibility with HTTP/1.0 clients. |
---|
| 1604 | |
---|
| 1605 | In order to remain persistent, all messages on the connection MUST |
---|
| 1606 | have a self-defined message length (i.e., one not defined by closure |
---|
| 1607 | of the connection), as described in Section 4.4. |
---|
| 1608 | |
---|
| 1609 | 7.1.2.2. Pipelining |
---|
| 1610 | |
---|
| 1611 | A client that supports persistent connections MAY "pipeline" its |
---|
| 1612 | requests (i.e., send multiple requests without waiting for each |
---|
| 1613 | response). A server MUST send its responses to those requests in the |
---|
| 1614 | same order that the requests were received. |
---|
| 1615 | |
---|
| 1616 | Clients which assume persistent connections and pipeline immediately |
---|
| 1617 | after connection establishment SHOULD be prepared to retry their |
---|
| 1618 | connection if the first pipelined attempt fails. If a client does |
---|
| 1619 | such a retry, it MUST NOT pipeline before it knows the connection is |
---|
| 1620 | |
---|
| 1621 | |
---|
| 1622 | |
---|
| 1623 | Fielding, et al. Expires May 20, 2009 [Page 29] |
---|
| 1624 | |
---|
| 1625 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1626 | |
---|
| 1627 | |
---|
| 1628 | persistent. Clients MUST also be prepared to resend their requests |
---|
| 1629 | if the server closes the connection before sending all of the |
---|
| 1630 | corresponding responses. |
---|
| 1631 | |
---|
| 1632 | Clients SHOULD NOT pipeline requests using non-idempotent methods or |
---|
| 1633 | non-idempotent sequences of methods (see Section 8.1.2 of [Part2]). |
---|
| 1634 | Otherwise, a premature termination of the transport connection could |
---|
| 1635 | lead to indeterminate results. A client wishing to send a non- |
---|
| 1636 | idempotent request SHOULD wait to send that request until it has |
---|
| 1637 | received the response status for the previous request. |
---|
| 1638 | |
---|
| 1639 | 7.1.3. Proxy Servers |
---|
| 1640 | |
---|
| 1641 | It is especially important that proxies correctly implement the |
---|
| 1642 | properties of the Connection header field as specified in |
---|
| 1643 | Section 8.1. |
---|
| 1644 | |
---|
| 1645 | The proxy server MUST signal persistent connections separately with |
---|
| 1646 | its clients and the origin servers (or other proxy servers) that it |
---|
| 1647 | connects to. Each persistent connection applies to only one |
---|
| 1648 | transport link. |
---|
| 1649 | |
---|
| 1650 | A proxy server MUST NOT establish a HTTP/1.1 persistent connection |
---|
| 1651 | with an HTTP/1.0 client (but see [RFC2068] for information and |
---|
| 1652 | discussion of the problems with the Keep-Alive header implemented by |
---|
| 1653 | many HTTP/1.0 clients). |
---|
| 1654 | |
---|
| 1655 | 7.1.4. Practical Considerations |
---|
| 1656 | |
---|
| 1657 | Servers will usually have some time-out value beyond which they will |
---|
| 1658 | no longer maintain an inactive connection. Proxy servers might make |
---|
| 1659 | this a higher value since it is likely that the client will be making |
---|
| 1660 | more connections through the same server. The use of persistent |
---|
| 1661 | connections places no requirements on the length (or existence) of |
---|
| 1662 | this time-out for either the client or the server. |
---|
| 1663 | |
---|
| 1664 | When a client or server wishes to time-out it SHOULD issue a graceful |
---|
| 1665 | close on the transport connection. Clients and servers SHOULD both |
---|
| 1666 | constantly watch for the other side of the transport close, and |
---|
| 1667 | respond to it as appropriate. If a client or server does not detect |
---|
| 1668 | the other side's close promptly it could cause unnecessary resource |
---|
| 1669 | drain on the network. |
---|
| 1670 | |
---|
| 1671 | A client, server, or proxy MAY close the transport connection at any |
---|
| 1672 | time. For example, a client might have started to send a new request |
---|
| 1673 | at the same time that the server has decided to close the "idle" |
---|
| 1674 | connection. From the server's point of view, the connection is being |
---|
| 1675 | closed while it was idle, but from the client's point of view, a |
---|
| 1676 | |
---|
| 1677 | |
---|
| 1678 | |
---|
| 1679 | Fielding, et al. Expires May 20, 2009 [Page 30] |
---|
| 1680 | |
---|
| 1681 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1682 | |
---|
| 1683 | |
---|
| 1684 | request is in progress. |
---|
| 1685 | |
---|
| 1686 | This means that clients, servers, and proxies MUST be able to recover |
---|
| 1687 | from asynchronous close events. Client software SHOULD reopen the |
---|
| 1688 | transport connection and retransmit the aborted sequence of requests |
---|
| 1689 | without user interaction so long as the request sequence is |
---|
| 1690 | idempotent (see Section 8.1.2 of [Part2]). Non-idempotent methods or |
---|
| 1691 | sequences MUST NOT be automatically retried, although user agents MAY |
---|
| 1692 | offer a human operator the choice of retrying the request(s). |
---|
| 1693 | Confirmation by user-agent software with semantic understanding of |
---|
| 1694 | the application MAY substitute for user confirmation. The automatic |
---|
| 1695 | retry SHOULD NOT be repeated if the second sequence of requests |
---|
| 1696 | fails. |
---|
| 1697 | |
---|
| 1698 | Servers SHOULD always respond to at least one request per connection, |
---|
| 1699 | if at all possible. Servers SHOULD NOT close a connection in the |
---|
| 1700 | middle of transmitting a response, unless a network or client failure |
---|
| 1701 | is suspected. |
---|
| 1702 | |
---|
| 1703 | Clients that use persistent connections SHOULD limit the number of |
---|
| 1704 | simultaneous connections that they maintain to a given server. A |
---|
| 1705 | single-user client SHOULD NOT maintain more than 2 connections with |
---|
| 1706 | any server or proxy. A proxy SHOULD use up to 2*N connections to |
---|
| 1707 | another server or proxy, where N is the number of simultaneously |
---|
| 1708 | active users. These guidelines are intended to improve HTTP response |
---|
| 1709 | times and avoid congestion. |
---|
| 1710 | |
---|
| 1711 | 7.2. Message Transmission Requirements |
---|
| 1712 | |
---|
| 1713 | 7.2.1. Persistent Connections and Flow Control |
---|
| 1714 | |
---|
| 1715 | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |
---|
| 1716 | flow control mechanisms to resolve temporary overloads, rather than |
---|
| 1717 | terminating connections with the expectation that clients will retry. |
---|
| 1718 | The latter technique can exacerbate network congestion. |
---|
| 1719 | |
---|
| 1720 | 7.2.2. Monitoring Connections for Error Status Messages |
---|
| 1721 | |
---|
| 1722 | An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |
---|
| 1723 | the network connection for an error status while it is transmitting |
---|
| 1724 | the request. If the client sees an error status, it SHOULD |
---|
| 1725 | immediately cease transmitting the body. If the body is being sent |
---|
| 1726 | using a "chunked" encoding (Section 3.4), a zero length chunk and |
---|
| 1727 | empty trailer MAY be used to prematurely mark the end of the message. |
---|
| 1728 | If the body was preceded by a Content-Length header, the client MUST |
---|
| 1729 | close the connection. |
---|
| 1730 | |
---|
| 1731 | |
---|
| 1732 | |
---|
| 1733 | |
---|
| 1734 | |
---|
| 1735 | Fielding, et al. Expires May 20, 2009 [Page 31] |
---|
| 1736 | |
---|
| 1737 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1738 | |
---|
| 1739 | |
---|
| 1740 | 7.2.3. Use of the 100 (Continue) Status |
---|
| 1741 | |
---|
| 1742 | The purpose of the 100 (Continue) status (see Section 9.1.1 of |
---|
| 1743 | [Part2]) is to allow a client that is sending a request message with |
---|
| 1744 | a request body to determine if the origin server is willing to accept |
---|
| 1745 | the request (based on the request headers) before the client sends |
---|
| 1746 | the request body. In some cases, it might either be inappropriate or |
---|
| 1747 | highly inefficient for the client to send the body if the server will |
---|
| 1748 | reject the message without looking at the body. |
---|
| 1749 | |
---|
| 1750 | Requirements for HTTP/1.1 clients: |
---|
| 1751 | |
---|
| 1752 | o If a client will wait for a 100 (Continue) response before sending |
---|
| 1753 | the request body, it MUST send an Expect request-header field |
---|
| 1754 | (Section 10.2 of [Part2]) with the "100-continue" expectation. |
---|
| 1755 | |
---|
| 1756 | o A client MUST NOT send an Expect request-header field (Section |
---|
| 1757 | 10.2 of [Part2]) with the "100-continue" expectation if it does |
---|
| 1758 | not intend to send a request body. |
---|
| 1759 | |
---|
| 1760 | Because of the presence of older implementations, the protocol allows |
---|
| 1761 | ambiguous situations in which a client may send "Expect: 100- |
---|
| 1762 | continue" without receiving either a 417 (Expectation Failed) status |
---|
| 1763 | or a 100 (Continue) status. Therefore, when a client sends this |
---|
| 1764 | header field to an origin server (possibly via a proxy) from which it |
---|
| 1765 | has never seen a 100 (Continue) status, the client SHOULD NOT wait |
---|
| 1766 | for an indefinite period before sending the request body. |
---|
| 1767 | |
---|
| 1768 | Requirements for HTTP/1.1 origin servers: |
---|
| 1769 | |
---|
| 1770 | o Upon receiving a request which includes an Expect request-header |
---|
| 1771 | field with the "100-continue" expectation, an origin server MUST |
---|
| 1772 | either respond with 100 (Continue) status and continue to read |
---|
| 1773 | from the input stream, or respond with a final status code. The |
---|
| 1774 | origin server MUST NOT wait for the request body before sending |
---|
| 1775 | the 100 (Continue) response. If it responds with a final status |
---|
| 1776 | code, it MAY close the transport connection or it MAY continue to |
---|
| 1777 | read and discard the rest of the request. It MUST NOT perform the |
---|
| 1778 | requested method if it returns a final status code. |
---|
| 1779 | |
---|
| 1780 | o An origin server SHOULD NOT send a 100 (Continue) response if the |
---|
| 1781 | request message does not include an Expect request-header field |
---|
| 1782 | with the "100-continue" expectation, and MUST NOT send a 100 |
---|
| 1783 | (Continue) response if such a request comes from an HTTP/1.0 (or |
---|
| 1784 | earlier) client. There is an exception to this rule: for |
---|
| 1785 | compatibility with [RFC2068], a server MAY send a 100 (Continue) |
---|
| 1786 | status in response to an HTTP/1.1 PUT or POST request that does |
---|
| 1787 | not include an Expect request-header field with the "100-continue" |
---|
| 1788 | |
---|
| 1789 | |
---|
| 1790 | |
---|
| 1791 | Fielding, et al. Expires May 20, 2009 [Page 32] |
---|
| 1792 | |
---|
| 1793 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1794 | |
---|
| 1795 | |
---|
| 1796 | expectation. This exception, the purpose of which is to minimize |
---|
| 1797 | any client processing delays associated with an undeclared wait |
---|
| 1798 | for 100 (Continue) status, applies only to HTTP/1.1 requests, and |
---|
| 1799 | not to requests with any other HTTP-version value. |
---|
| 1800 | |
---|
| 1801 | o An origin server MAY omit a 100 (Continue) response if it has |
---|
| 1802 | already received some or all of the request body for the |
---|
| 1803 | corresponding request. |
---|
| 1804 | |
---|
| 1805 | o An origin server that sends a 100 (Continue) response MUST |
---|
| 1806 | ultimately send a final status code, once the request body is |
---|
| 1807 | received and processed, unless it terminates the transport |
---|
| 1808 | connection prematurely. |
---|
| 1809 | |
---|
| 1810 | o If an origin server receives a request that does not include an |
---|
| 1811 | Expect request-header field with the "100-continue" expectation, |
---|
| 1812 | the request includes a request body, and the server responds with |
---|
| 1813 | a final status code before reading the entire request body from |
---|
| 1814 | the transport connection, then the server SHOULD NOT close the |
---|
| 1815 | transport connection until it has read the entire request, or |
---|
| 1816 | until the client closes the connection. Otherwise, the client |
---|
| 1817 | might not reliably receive the response message. However, this |
---|
| 1818 | requirement is not be construed as preventing a server from |
---|
| 1819 | defending itself against denial-of-service attacks, or from badly |
---|
| 1820 | broken client implementations. |
---|
| 1821 | |
---|
| 1822 | Requirements for HTTP/1.1 proxies: |
---|
| 1823 | |
---|
| 1824 | o If a proxy receives a request that includes an Expect request- |
---|
| 1825 | header field with the "100-continue" expectation, and the proxy |
---|
| 1826 | either knows that the next-hop server complies with HTTP/1.1 or |
---|
| 1827 | higher, or does not know the HTTP version of the next-hop server, |
---|
| 1828 | it MUST forward the request, including the Expect header field. |
---|
| 1829 | |
---|
| 1830 | o If the proxy knows that the version of the next-hop server is |
---|
| 1831 | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |
---|
| 1832 | respond with a 417 (Expectation Failed) status. |
---|
| 1833 | |
---|
| 1834 | o Proxies SHOULD maintain a cache recording the HTTP version numbers |
---|
| 1835 | received from recently-referenced next-hop servers. |
---|
| 1836 | |
---|
| 1837 | o A proxy MUST NOT forward a 100 (Continue) response if the request |
---|
| 1838 | message was received from an HTTP/1.0 (or earlier) client and did |
---|
| 1839 | not include an Expect request-header field with the "100-continue" |
---|
| 1840 | expectation. This requirement overrides the general rule for |
---|
| 1841 | forwarding of 1xx responses (see Section 9.1 of [Part2]). |
---|
| 1842 | |
---|
| 1843 | |
---|
| 1844 | |
---|
| 1845 | |
---|
| 1846 | |
---|
| 1847 | Fielding, et al. Expires May 20, 2009 [Page 33] |
---|
| 1848 | |
---|
| 1849 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1850 | |
---|
| 1851 | |
---|
| 1852 | 7.2.4. Client Behavior if Server Prematurely Closes Connection |
---|
| 1853 | |
---|
| 1854 | If an HTTP/1.1 client sends a request which includes a request body, |
---|
| 1855 | but which does not include an Expect request-header field with the |
---|
| 1856 | "100-continue" expectation, and if the client is not directly |
---|
| 1857 | connected to an HTTP/1.1 origin server, and if the client sees the |
---|
| 1858 | connection close before receiving any status from the server, the |
---|
| 1859 | client SHOULD retry the request. If the client does retry this |
---|
| 1860 | request, it MAY use the following "binary exponential backoff" |
---|
| 1861 | algorithm to be assured of obtaining a reliable response: |
---|
| 1862 | |
---|
| 1863 | 1. Initiate a new connection to the server |
---|
| 1864 | |
---|
| 1865 | 2. Transmit the request-headers |
---|
| 1866 | |
---|
| 1867 | 3. Initialize a variable R to the estimated round-trip time to the |
---|
| 1868 | server (e.g., based on the time it took to establish the |
---|
| 1869 | connection), or to a constant value of 5 seconds if the round- |
---|
| 1870 | trip time is not available. |
---|
| 1871 | |
---|
| 1872 | 4. Compute T = R * (2**N), where N is the number of previous retries |
---|
| 1873 | of this request. |
---|
| 1874 | |
---|
| 1875 | 5. Wait either for an error response from the server, or for T |
---|
| 1876 | seconds (whichever comes first) |
---|
| 1877 | |
---|
| 1878 | 6. If no error response is received, after T seconds transmit the |
---|
| 1879 | body of the request. |
---|
| 1880 | |
---|
| 1881 | 7. If client sees that the connection is closed prematurely, repeat |
---|
| 1882 | from step 1 until the request is accepted, an error response is |
---|
| 1883 | received, or the user becomes impatient and terminates the retry |
---|
| 1884 | process. |
---|
| 1885 | |
---|
| 1886 | If at any point an error status is received, the client |
---|
| 1887 | |
---|
| 1888 | o SHOULD NOT continue and |
---|
| 1889 | |
---|
| 1890 | o SHOULD close the connection if it has not completed sending the |
---|
| 1891 | request message. |
---|
| 1892 | |
---|
| 1893 | |
---|
| 1894 | 8. Header Field Definitions |
---|
| 1895 | |
---|
| 1896 | This section defines the syntax and semantics of HTTP/1.1 header |
---|
| 1897 | fields related to message framing and transport protocols. |
---|
| 1898 | |
---|
| 1899 | For entity-header fields, both sender and recipient refer to either |
---|
| 1900 | |
---|
| 1901 | |
---|
| 1902 | |
---|
| 1903 | Fielding, et al. Expires May 20, 2009 [Page 34] |
---|
| 1904 | |
---|
| 1905 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1906 | |
---|
| 1907 | |
---|
| 1908 | the client or the server, depending on who sends and who receives the |
---|
| 1909 | entity. |
---|
| 1910 | |
---|
| 1911 | 8.1. Connection |
---|
| 1912 | |
---|
| 1913 | The general-header field "Connection" allows the sender to specify |
---|
| 1914 | options that are desired for that particular connection and MUST NOT |
---|
| 1915 | be communicated by proxies over further connections. |
---|
| 1916 | |
---|
| 1917 | The Connection header's value has the following grammar: |
---|
| 1918 | |
---|
| 1919 | Connection = "Connection" ":" OWS Connection-v |
---|
| 1920 | Connection-v = 1#connection-token |
---|
| 1921 | connection-token = token |
---|
| 1922 | |
---|
| 1923 | HTTP/1.1 proxies MUST parse the Connection header field before a |
---|
| 1924 | message is forwarded and, for each connection-token in this field, |
---|
| 1925 | remove any header field(s) from the message with the same name as the |
---|
| 1926 | connection-token. Connection options are signaled by the presence of |
---|
| 1927 | a connection-token in the Connection header field, not by any |
---|
| 1928 | corresponding additional header field(s), since the additional header |
---|
| 1929 | field may not be sent if there are no parameters associated with that |
---|
| 1930 | connection option. |
---|
| 1931 | |
---|
| 1932 | Message headers listed in the Connection header MUST NOT include end- |
---|
| 1933 | to-end headers, such as Cache-Control. |
---|
| 1934 | |
---|
| 1935 | HTTP/1.1 defines the "close" connection option for the sender to |
---|
| 1936 | signal that the connection will be closed after completion of the |
---|
| 1937 | response. For example, |
---|
| 1938 | |
---|
| 1939 | Connection: close |
---|
| 1940 | |
---|
| 1941 | in either the request or the response header fields indicates that |
---|
| 1942 | the connection SHOULD NOT be considered `persistent' (Section 7.1) |
---|
| 1943 | after the current request/response is complete. |
---|
| 1944 | |
---|
| 1945 | An HTTP/1.1 client that does not support persistent connections MUST |
---|
| 1946 | include the "close" connection option in every request message. |
---|
| 1947 | |
---|
| 1948 | An HTTP/1.1 server that does not support persistent connections MUST |
---|
| 1949 | include the "close" connection option in every response message that |
---|
| 1950 | does not have a 1xx (informational) status code. |
---|
| 1951 | |
---|
| 1952 | A system receiving an HTTP/1.0 (or lower-version) message that |
---|
| 1953 | includes a Connection header MUST, for each connection-token in this |
---|
| 1954 | field, remove and ignore any header field(s) from the message with |
---|
| 1955 | the same name as the connection-token. This protects against |
---|
| 1956 | |
---|
| 1957 | |
---|
| 1958 | |
---|
| 1959 | Fielding, et al. Expires May 20, 2009 [Page 35] |
---|
| 1960 | |
---|
| 1961 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 1962 | |
---|
| 1963 | |
---|
| 1964 | mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |
---|
| 1965 | See Appendix C.2. |
---|
| 1966 | |
---|
| 1967 | 8.2. Content-Length |
---|
| 1968 | |
---|
| 1969 | The entity-header field "Content-Length" indicates the size of the |
---|
| 1970 | entity-body, in decimal number of OCTETs, sent to the recipient or, |
---|
| 1971 | in the case of the HEAD method, the size of the entity-body that |
---|
| 1972 | would have been sent had the request been a GET. |
---|
| 1973 | |
---|
| 1974 | Content-Length = "Content-Length" ":" OWS 1*Content-Length-v |
---|
| 1975 | Content-Length-v = 1*DIGIT |
---|
| 1976 | |
---|
| 1977 | An example is |
---|
| 1978 | |
---|
| 1979 | Content-Length: 3495 |
---|
| 1980 | |
---|
| 1981 | Applications SHOULD use this field to indicate the transfer-length of |
---|
| 1982 | the message-body, unless this is prohibited by the rules in |
---|
| 1983 | Section 4.4. |
---|
| 1984 | |
---|
| 1985 | Any Content-Length greater than or equal to zero is a valid value. |
---|
| 1986 | Section 4.4 describes how to determine the length of a message-body |
---|
| 1987 | if a Content-Length is not given. |
---|
| 1988 | |
---|
| 1989 | Note that the meaning of this field is significantly different from |
---|
| 1990 | the corresponding definition in MIME, where it is an optional field |
---|
| 1991 | used within the "message/external-body" content-type. In HTTP, it |
---|
| 1992 | SHOULD be sent whenever the message's length can be determined prior |
---|
| 1993 | to being transferred, unless this is prohibited by the rules in |
---|
| 1994 | Section 4.4. |
---|
| 1995 | |
---|
| 1996 | 8.3. Date |
---|
| 1997 | |
---|
| 1998 | The general-header field "Date" represents the date and time at which |
---|
| 1999 | the message was originated, having the same semantics as orig-date in |
---|
| 2000 | Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as |
---|
| 2001 | described in Section 3.3.1; it MUST be sent in rfc1123-date format. |
---|
| 2002 | |
---|
| 2003 | Date = "Date" ":" OWS Date-v |
---|
| 2004 | Date-v = HTTP-date |
---|
| 2005 | |
---|
| 2006 | An example is |
---|
| 2007 | |
---|
| 2008 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
---|
| 2009 | |
---|
| 2010 | Origin servers MUST include a Date header field in all responses, |
---|
| 2011 | except in these cases: |
---|
| 2012 | |
---|
| 2013 | |
---|
| 2014 | |
---|
| 2015 | Fielding, et al. Expires May 20, 2009 [Page 36] |
---|
| 2016 | |
---|
| 2017 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2018 | |
---|
| 2019 | |
---|
| 2020 | 1. If the response status code is 100 (Continue) or 101 (Switching |
---|
| 2021 | Protocols), the response MAY include a Date header field, at the |
---|
| 2022 | server's option. |
---|
| 2023 | |
---|
| 2024 | 2. If the response status code conveys a server error, e.g. 500 |
---|
| 2025 | (Internal Server Error) or 503 (Service Unavailable), and it is |
---|
| 2026 | inconvenient or impossible to generate a valid Date. |
---|
| 2027 | |
---|
| 2028 | 3. If the server does not have a clock that can provide a reasonable |
---|
| 2029 | approximation of the current time, its responses MUST NOT include |
---|
| 2030 | a Date header field. In this case, the rules in Section 8.3.1 |
---|
| 2031 | MUST be followed. |
---|
| 2032 | |
---|
| 2033 | A received message that does not have a Date header field MUST be |
---|
| 2034 | assigned one by the recipient if the message will be cached by that |
---|
| 2035 | recipient or gatewayed via a protocol which requires a Date. An HTTP |
---|
| 2036 | implementation without a clock MUST NOT cache responses without |
---|
| 2037 | revalidating them on every use. An HTTP cache, especially a shared |
---|
| 2038 | cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize |
---|
| 2039 | its clock with a reliable external standard. |
---|
| 2040 | |
---|
| 2041 | Clients SHOULD only send a Date header field in messages that include |
---|
| 2042 | an entity-body, as in the case of the PUT and POST requests, and even |
---|
| 2043 | then it is optional. A client without a clock MUST NOT send a Date |
---|
| 2044 | header field in a request. |
---|
| 2045 | |
---|
| 2046 | The HTTP-date sent in a Date header SHOULD NOT represent a date and |
---|
| 2047 | time subsequent to the generation of the message. It SHOULD |
---|
| 2048 | represent the best available approximation of the date and time of |
---|
| 2049 | message generation, unless the implementation has no means of |
---|
| 2050 | generating a reasonably accurate date and time. In theory, the date |
---|
| 2051 | ought to represent the moment just before the entity is generated. |
---|
| 2052 | In practice, the date can be generated at any time during the message |
---|
| 2053 | origination without affecting its semantic value. |
---|
| 2054 | |
---|
| 2055 | 8.3.1. Clockless Origin Server Operation |
---|
| 2056 | |
---|
| 2057 | Some origin server implementations might not have a clock available. |
---|
| 2058 | An origin server without a clock MUST NOT assign Expires or Last- |
---|
| 2059 | Modified values to a response, unless these values were associated |
---|
| 2060 | with the resource by a system or user with a reliable clock. It MAY |
---|
| 2061 | assign an Expires value that is known, at or before server |
---|
| 2062 | configuration time, to be in the past (this allows "pre-expiration" |
---|
| 2063 | of responses without storing separate Expires values for each |
---|
| 2064 | resource). |
---|
| 2065 | |
---|
| 2066 | |
---|
| 2067 | |
---|
| 2068 | |
---|
| 2069 | |
---|
| 2070 | |
---|
| 2071 | Fielding, et al. Expires May 20, 2009 [Page 37] |
---|
| 2072 | |
---|
| 2073 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2074 | |
---|
| 2075 | |
---|
| 2076 | 8.4. Host |
---|
| 2077 | |
---|
| 2078 | The request-header field "Host" specifies the Internet host and port |
---|
| 2079 | number of the resource being requested, as obtained from the original |
---|
| 2080 | URI given by the user or referring resource (generally an HTTP URL, |
---|
| 2081 | as described in Section 3.2.1). The Host field value MUST represent |
---|
| 2082 | the naming authority of the origin server or gateway given by the |
---|
| 2083 | original URL. This allows the origin server or gateway to |
---|
| 2084 | differentiate between internally-ambiguous URLs, such as the root "/" |
---|
| 2085 | URL of a server for multiple host names on a single IP address. |
---|
| 2086 | |
---|
| 2087 | Host = "Host" ":" OWS Host-v |
---|
| 2088 | Host-v = uri-host [ ":" port ] ; Section 3.2.1 |
---|
| 2089 | |
---|
| 2090 | A "host" without any trailing port information implies the default |
---|
| 2091 | port for the service requested (e.g., "80" for an HTTP URL). For |
---|
| 2092 | example, a request on the origin server for |
---|
| 2093 | <http://www.example.org/pub/WWW/> would properly include: |
---|
| 2094 | |
---|
| 2095 | GET /pub/WWW/ HTTP/1.1 |
---|
| 2096 | Host: www.example.org |
---|
| 2097 | |
---|
| 2098 | A client MUST include a Host header field in all HTTP/1.1 request |
---|
| 2099 | messages. If the requested URI does not include an Internet host |
---|
| 2100 | name for the service being requested, then the Host header field MUST |
---|
| 2101 | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any |
---|
| 2102 | request message it forwards does contain an appropriate Host header |
---|
| 2103 | field that identifies the service being requested by the proxy. All |
---|
| 2104 | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) |
---|
| 2105 | status code to any HTTP/1.1 request message which lacks a Host header |
---|
| 2106 | field. |
---|
| 2107 | |
---|
| 2108 | See Sections 5.2 and C.1.1 for other requirements relating to Host. |
---|
| 2109 | |
---|
| 2110 | 8.5. TE |
---|
| 2111 | |
---|
| 2112 | The request-header field "TE" indicates what extension transfer- |
---|
| 2113 | codings it is willing to accept in the response and whether or not it |
---|
| 2114 | is willing to accept trailer fields in a chunked transfer-coding. |
---|
| 2115 | Its value may consist of the keyword "trailers" and/or a comma- |
---|
| 2116 | separated list of extension transfer-coding names with optional |
---|
| 2117 | accept parameters (as described in Section 3.4). |
---|
| 2118 | |
---|
| 2119 | TE = "TE" ":" OWS TE-v |
---|
| 2120 | TE-v = #t-codings |
---|
| 2121 | t-codings = "trailers" / ( transfer-extension [ accept-params ] ) |
---|
| 2122 | |
---|
| 2123 | The presence of the keyword "trailers" indicates that the client is |
---|
| 2124 | |
---|
| 2125 | |
---|
| 2126 | |
---|
| 2127 | Fielding, et al. Expires May 20, 2009 [Page 38] |
---|
| 2128 | |
---|
| 2129 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2130 | |
---|
| 2131 | |
---|
| 2132 | willing to accept trailer fields in a chunked transfer-coding, as |
---|
| 2133 | defined in Section 3.4.1. This keyword is reserved for use with |
---|
| 2134 | transfer-coding values even though it does not itself represent a |
---|
| 2135 | transfer-coding. |
---|
| 2136 | |
---|
| 2137 | Examples of its use are: |
---|
| 2138 | |
---|
| 2139 | TE: deflate |
---|
| 2140 | TE: |
---|
| 2141 | TE: trailers, deflate;q=0.5 |
---|
| 2142 | |
---|
| 2143 | The TE header field only applies to the immediate connection. |
---|
| 2144 | Therefore, the keyword MUST be supplied within a Connection header |
---|
| 2145 | field (Section 8.1) whenever TE is present in an HTTP/1.1 message. |
---|
| 2146 | |
---|
| 2147 | A server tests whether a transfer-coding is acceptable, according to |
---|
| 2148 | a TE field, using these rules: |
---|
| 2149 | |
---|
| 2150 | 1. The "chunked" transfer-coding is always acceptable. If the |
---|
| 2151 | keyword "trailers" is listed, the client indicates that it is |
---|
| 2152 | willing to accept trailer fields in the chunked response on |
---|
| 2153 | behalf of itself and any downstream clients. The implication is |
---|
| 2154 | that, if given, the client is stating that either all downstream |
---|
| 2155 | clients are willing to accept trailer fields in the forwarded |
---|
| 2156 | response, or that it will attempt to buffer the response on |
---|
| 2157 | behalf of downstream recipients. |
---|
| 2158 | |
---|
| 2159 | Note: HTTP/1.1 does not define any means to limit the size of a |
---|
| 2160 | chunked response such that a client can be assured of buffering |
---|
| 2161 | the entire response. |
---|
| 2162 | |
---|
| 2163 | 2. If the transfer-coding being tested is one of the transfer- |
---|
| 2164 | codings listed in the TE field, then it is acceptable unless it |
---|
| 2165 | is accompanied by a qvalue of 0. (As defined in Section 3.4 of |
---|
| 2166 | [Part3], a qvalue of 0 means "not acceptable.") |
---|
| 2167 | |
---|
| 2168 | 3. If multiple transfer-codings are acceptable, then the acceptable |
---|
| 2169 | transfer-coding with the highest non-zero qvalue is preferred. |
---|
| 2170 | The "chunked" transfer-coding always has a qvalue of 1. |
---|
| 2171 | |
---|
| 2172 | If the TE field-value is empty or if no TE field is present, the only |
---|
| 2173 | transfer-coding is "chunked". A message with no transfer-coding is |
---|
| 2174 | always acceptable. |
---|
| 2175 | |
---|
| 2176 | 8.6. Trailer |
---|
| 2177 | |
---|
| 2178 | The general field "Trailer" indicates that the given set of header |
---|
| 2179 | fields is present in the trailer of a message encoded with chunked |
---|
| 2180 | |
---|
| 2181 | |
---|
| 2182 | |
---|
| 2183 | Fielding, et al. Expires May 20, 2009 [Page 39] |
---|
| 2184 | |
---|
| 2185 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2186 | |
---|
| 2187 | |
---|
| 2188 | transfer-coding. |
---|
| 2189 | |
---|
| 2190 | Trailer = "Trailer" ":" OWS Trailer-v |
---|
| 2191 | Trailer-v = 1#field-name |
---|
| 2192 | |
---|
| 2193 | An HTTP/1.1 message SHOULD include a Trailer header field in a |
---|
| 2194 | message using chunked transfer-coding with a non-empty trailer. |
---|
| 2195 | Doing so allows the recipient to know which header fields to expect |
---|
| 2196 | in the trailer. |
---|
| 2197 | |
---|
| 2198 | If no Trailer header field is present, the trailer SHOULD NOT include |
---|
| 2199 | any header fields. See Section 3.4.1 for restrictions on the use of |
---|
| 2200 | trailer fields in a "chunked" transfer-coding. |
---|
| 2201 | |
---|
| 2202 | Message header fields listed in the Trailer header field MUST NOT |
---|
| 2203 | include the following header fields: |
---|
| 2204 | |
---|
| 2205 | o Transfer-Encoding |
---|
| 2206 | |
---|
| 2207 | o Content-Length |
---|
| 2208 | |
---|
| 2209 | o Trailer |
---|
| 2210 | |
---|
| 2211 | 8.7. Transfer-Encoding |
---|
| 2212 | |
---|
| 2213 | The general-header "Transfer-Encoding" field indicates what (if any) |
---|
| 2214 | type of transformation has been applied to the message body in order |
---|
| 2215 | to safely transfer it between the sender and the recipient. This |
---|
| 2216 | differs from the content-coding in that the transfer-coding is a |
---|
| 2217 | property of the message, not of the entity. |
---|
| 2218 | |
---|
| 2219 | Transfer-Encoding = "Transfer-Encoding" ":" OWS |
---|
| 2220 | Transfer-Encoding-v |
---|
| 2221 | Transfer-Encoding-v = 1#transfer-coding |
---|
| 2222 | |
---|
| 2223 | Transfer-codings are defined in Section 3.4. An example is: |
---|
| 2224 | |
---|
| 2225 | Transfer-Encoding: chunked |
---|
| 2226 | |
---|
| 2227 | If multiple encodings have been applied to an entity, the transfer- |
---|
| 2228 | codings MUST be listed in the order in which they were applied. |
---|
| 2229 | Additional information about the encoding parameters MAY be provided |
---|
| 2230 | by other entity-header fields not defined by this specification. |
---|
| 2231 | |
---|
| 2232 | Many older HTTP/1.0 applications do not understand the Transfer- |
---|
| 2233 | Encoding header. |
---|
| 2234 | |
---|
| 2235 | |
---|
| 2236 | |
---|
| 2237 | |
---|
| 2238 | |
---|
| 2239 | Fielding, et al. Expires May 20, 2009 [Page 40] |
---|
| 2240 | |
---|
| 2241 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2242 | |
---|
| 2243 | |
---|
| 2244 | 8.8. Upgrade |
---|
| 2245 | |
---|
| 2246 | The general-header "Upgrade" allows the client to specify what |
---|
| 2247 | additional communication protocols it supports and would like to use |
---|
| 2248 | if the server finds it appropriate to switch protocols. The server |
---|
| 2249 | MUST use the Upgrade header field within a 101 (Switching Protocols) |
---|
| 2250 | response to indicate which protocol(s) are being switched. |
---|
| 2251 | |
---|
| 2252 | Upgrade = "Upgrade" ":" OWS Upgrade-v |
---|
| 2253 | Upgrade-v = 1#product |
---|
| 2254 | |
---|
| 2255 | For example, |
---|
| 2256 | |
---|
| 2257 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
---|
| 2258 | |
---|
| 2259 | The Upgrade header field is intended to provide a simple mechanism |
---|
| 2260 | for transition from HTTP/1.1 to some other, incompatible protocol. |
---|
| 2261 | It does so by allowing the client to advertise its desire to use |
---|
| 2262 | another protocol, such as a later version of HTTP with a higher major |
---|
| 2263 | version number, even though the current request has been made using |
---|
| 2264 | HTTP/1.1. This eases the difficult transition between incompatible |
---|
| 2265 | protocols by allowing the client to initiate a request in the more |
---|
| 2266 | commonly supported protocol while indicating to the server that it |
---|
| 2267 | would like to use a "better" protocol if available (where "better" is |
---|
| 2268 | determined by the server, possibly according to the nature of the |
---|
| 2269 | method and/or resource being requested). |
---|
| 2270 | |
---|
| 2271 | The Upgrade header field only applies to switching application-layer |
---|
| 2272 | protocols upon the existing transport-layer connection. Upgrade |
---|
| 2273 | cannot be used to insist on a protocol change; its acceptance and use |
---|
| 2274 | by the server is optional. The capabilities and nature of the |
---|
| 2275 | application-layer communication after the protocol change is entirely |
---|
| 2276 | dependent upon the new protocol chosen, although the first action |
---|
| 2277 | after changing the protocol MUST be a response to the initial HTTP |
---|
| 2278 | request containing the Upgrade header field. |
---|
| 2279 | |
---|
| 2280 | The Upgrade header field only applies to the immediate connection. |
---|
| 2281 | Therefore, the upgrade keyword MUST be supplied within a Connection |
---|
| 2282 | header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 |
---|
| 2283 | message. |
---|
| 2284 | |
---|
| 2285 | The Upgrade header field cannot be used to indicate a switch to a |
---|
| 2286 | protocol on a different connection. For that purpose, it is more |
---|
| 2287 | appropriate to use a 301, 302, 303, or 305 redirection response. |
---|
| 2288 | |
---|
| 2289 | This specification only defines the protocol name "HTTP" for use by |
---|
| 2290 | the family of Hypertext Transfer Protocols, as defined by the HTTP |
---|
| 2291 | version rules of Section 3.1 and future updates to this |
---|
| 2292 | |
---|
| 2293 | |
---|
| 2294 | |
---|
| 2295 | Fielding, et al. Expires May 20, 2009 [Page 41] |
---|
| 2296 | |
---|
| 2297 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2298 | |
---|
| 2299 | |
---|
| 2300 | specification. Any token can be used as a protocol name; however, it |
---|
| 2301 | will only be useful if both the client and server associate the name |
---|
| 2302 | with the same protocol. |
---|
| 2303 | |
---|
| 2304 | 8.9. Via |
---|
| 2305 | |
---|
| 2306 | The general-header field "Via" MUST be used by gateways and proxies |
---|
| 2307 | to indicate the intermediate protocols and recipients between the |
---|
| 2308 | user agent and the server on requests, and between the origin server |
---|
| 2309 | and the client on responses. It is analogous to the "Received" field |
---|
| 2310 | defined in Section 3.6.7 of [RFC5322] and is intended to be used for |
---|
| 2311 | tracking message forwards, avoiding request loops, and identifying |
---|
| 2312 | the protocol capabilities of all senders along the request/response |
---|
| 2313 | chain. |
---|
| 2314 | |
---|
| 2315 | Via = "Via" ":" OWS Via-v |
---|
| 2316 | Via-v = 1#( received-protocol RWS received-by |
---|
| 2317 | [ RWS comment ] ) |
---|
| 2318 | received-protocol = [ protocol-name "/" ] protocol-version |
---|
| 2319 | protocol-name = token |
---|
| 2320 | protocol-version = token |
---|
| 2321 | received-by = ( uri-host [ ":" port ] ) / pseudonym |
---|
| 2322 | pseudonym = token |
---|
| 2323 | |
---|
| 2324 | The received-protocol indicates the protocol version of the message |
---|
| 2325 | received by the server or client along each segment of the request/ |
---|
| 2326 | response chain. The received-protocol version is appended to the Via |
---|
| 2327 | field value when the message is forwarded so that information about |
---|
| 2328 | the protocol capabilities of upstream applications remains visible to |
---|
| 2329 | all recipients. |
---|
| 2330 | |
---|
| 2331 | The protocol-name is optional if and only if it would be "HTTP". The |
---|
| 2332 | received-by field is normally the host and optional port number of a |
---|
| 2333 | recipient server or client that subsequently forwarded the message. |
---|
| 2334 | However, if the real host is considered to be sensitive information, |
---|
| 2335 | it MAY be replaced by a pseudonym. If the port is not given, it MAY |
---|
| 2336 | be assumed to be the default port of the received-protocol. |
---|
| 2337 | |
---|
| 2338 | Multiple Via field values represents each proxy or gateway that has |
---|
| 2339 | forwarded the message. Each recipient MUST append its information |
---|
| 2340 | such that the end result is ordered according to the sequence of |
---|
| 2341 | forwarding applications. |
---|
| 2342 | |
---|
| 2343 | Comments MAY be used in the Via header field to identify the software |
---|
| 2344 | of the recipient proxy or gateway, analogous to the User-Agent and |
---|
| 2345 | Server header fields. However, all comments in the Via field are |
---|
| 2346 | optional and MAY be removed by any recipient prior to forwarding the |
---|
| 2347 | message. |
---|
| 2348 | |
---|
| 2349 | |
---|
| 2350 | |
---|
| 2351 | Fielding, et al. Expires May 20, 2009 [Page 42] |
---|
| 2352 | |
---|
| 2353 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2354 | |
---|
| 2355 | |
---|
| 2356 | For example, a request message could be sent from an HTTP/1.0 user |
---|
| 2357 | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
---|
| 2358 | forward the request to a public proxy at p.example.net, which |
---|
| 2359 | completes the request by forwarding it to the origin server at |
---|
| 2360 | www.example.com. The request received by www.example.com would then |
---|
| 2361 | have the following Via header field: |
---|
| 2362 | |
---|
| 2363 | Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |
---|
| 2364 | |
---|
| 2365 | Proxies and gateways used as a portal through a network firewall |
---|
| 2366 | SHOULD NOT, by default, forward the names and ports of hosts within |
---|
| 2367 | the firewall region. This information SHOULD only be propagated if |
---|
| 2368 | explicitly enabled. If not enabled, the received-by host of any host |
---|
| 2369 | behind the firewall SHOULD be replaced by an appropriate pseudonym |
---|
| 2370 | for that host. |
---|
| 2371 | |
---|
| 2372 | For organizations that have strong privacy requirements for hiding |
---|
| 2373 | internal structures, a proxy MAY combine an ordered subsequence of |
---|
| 2374 | Via header field entries with identical received-protocol values into |
---|
| 2375 | a single such entry. For example, |
---|
| 2376 | |
---|
| 2377 | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
---|
| 2378 | |
---|
| 2379 | could be collapsed to |
---|
| 2380 | |
---|
| 2381 | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
---|
| 2382 | |
---|
| 2383 | Applications SHOULD NOT combine multiple entries unless they are all |
---|
| 2384 | under the same organizational control and the hosts have already been |
---|
| 2385 | replaced by pseudonyms. Applications MUST NOT combine entries which |
---|
| 2386 | have different received-protocol values. |
---|
| 2387 | |
---|
| 2388 | |
---|
| 2389 | 9. IANA Considerations |
---|
| 2390 | |
---|
| 2391 | 9.1. Message Header Registration |
---|
| 2392 | |
---|
| 2393 | The Message Header Registry located at <http://www.iana.org/ |
---|
| 2394 | assignments/message-headers/message-header-index.html> should be |
---|
| 2395 | updated with the permanent registrations below (see [RFC3864]): |
---|
| 2396 | |
---|
| 2397 | |
---|
| 2398 | |
---|
| 2399 | |
---|
| 2400 | |
---|
| 2401 | |
---|
| 2402 | |
---|
| 2403 | |
---|
| 2404 | |
---|
| 2405 | |
---|
| 2406 | |
---|
| 2407 | Fielding, et al. Expires May 20, 2009 [Page 43] |
---|
| 2408 | |
---|
| 2409 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2410 | |
---|
| 2411 | |
---|
| 2412 | +-------------------+----------+----------+-------------+ |
---|
| 2413 | | Header Field Name | Protocol | Status | Reference | |
---|
| 2414 | +-------------------+----------+----------+-------------+ |
---|
| 2415 | | Connection | http | standard | Section 8.1 | |
---|
| 2416 | | Content-Length | http | standard | Section 8.2 | |
---|
| 2417 | | Date | http | standard | Section 8.3 | |
---|
| 2418 | | Host | http | standard | Section 8.4 | |
---|
| 2419 | | TE | http | standard | Section 8.5 | |
---|
| 2420 | | Trailer | http | standard | Section 8.6 | |
---|
| 2421 | | Transfer-Encoding | http | standard | Section 8.7 | |
---|
| 2422 | | Upgrade | http | standard | Section 8.8 | |
---|
| 2423 | | Via | http | standard | Section 8.9 | |
---|
| 2424 | +-------------------+----------+----------+-------------+ |
---|
| 2425 | |
---|
| 2426 | The change controller is: "IETF (iesg@ietf.org) - Internet |
---|
| 2427 | Engineering Task Force". |
---|
| 2428 | |
---|
| 2429 | 9.2. URI Scheme Registration |
---|
| 2430 | |
---|
| 2431 | The entry for the "http" URI Scheme in the registry located at |
---|
| 2432 | <http://www.iana.org/assignments/uri-schemes.html> should be updated |
---|
| 2433 | to point to Section 3.2.1 of this document (see [RFC4395]). |
---|
| 2434 | |
---|
| 2435 | 9.3. Internet Media Type Registrations |
---|
| 2436 | |
---|
| 2437 | This document serves as the specification for the Internet media |
---|
| 2438 | types "message/http" and "application/http". The following is to be |
---|
| 2439 | registered with IANA (see [RFC4288]). |
---|
| 2440 | |
---|
| 2441 | 9.3.1. Internet Media Type message/http |
---|
| 2442 | |
---|
| 2443 | The message/http type can be used to enclose a single HTTP request or |
---|
| 2444 | response message, provided that it obeys the MIME restrictions for |
---|
| 2445 | all "message" types regarding line length and encodings. |
---|
| 2446 | |
---|
| 2447 | Type name: message |
---|
| 2448 | |
---|
| 2449 | Subtype name: http |
---|
| 2450 | |
---|
| 2451 | Required parameters: none |
---|
| 2452 | |
---|
| 2453 | Optional parameters: version, msgtype |
---|
| 2454 | |
---|
| 2455 | version: The HTTP-Version number of the enclosed message (e.g., |
---|
| 2456 | "1.1"). If not present, the version can be determined from the |
---|
| 2457 | first line of the body. |
---|
| 2458 | |
---|
| 2459 | |
---|
| 2460 | |
---|
| 2461 | |
---|
| 2462 | |
---|
| 2463 | Fielding, et al. Expires May 20, 2009 [Page 44] |
---|
| 2464 | |
---|
| 2465 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2466 | |
---|
| 2467 | |
---|
| 2468 | msgtype: The message type -- "request" or "response". If not |
---|
| 2469 | present, the type can be determined from the first line of the |
---|
| 2470 | body. |
---|
| 2471 | |
---|
| 2472 | Encoding considerations: only "7bit", "8bit", or "binary" are |
---|
| 2473 | permitted |
---|
| 2474 | |
---|
| 2475 | Security considerations: none |
---|
| 2476 | |
---|
| 2477 | Interoperability considerations: none |
---|
| 2478 | |
---|
| 2479 | Published specification: This specification (see Section 9.3.1). |
---|
| 2480 | |
---|
| 2481 | Applications that use this media type: |
---|
| 2482 | |
---|
| 2483 | Additional information: |
---|
| 2484 | |
---|
| 2485 | Magic number(s): none |
---|
| 2486 | |
---|
| 2487 | File extension(s): none |
---|
| 2488 | |
---|
| 2489 | Macintosh file type code(s): none |
---|
| 2490 | |
---|
| 2491 | Person and email address to contact for further information: See |
---|
| 2492 | Authors Section. |
---|
| 2493 | |
---|
| 2494 | Intended usage: COMMON |
---|
| 2495 | |
---|
| 2496 | Restrictions on usage: none |
---|
| 2497 | |
---|
| 2498 | Author/Change controller: IESG |
---|
| 2499 | |
---|
| 2500 | 9.3.2. Internet Media Type application/http |
---|
| 2501 | |
---|
| 2502 | The application/http type can be used to enclose a pipeline of one or |
---|
| 2503 | more HTTP request or response messages (not intermixed). |
---|
| 2504 | |
---|
| 2505 | Type name: application |
---|
| 2506 | |
---|
| 2507 | Subtype name: http |
---|
| 2508 | |
---|
| 2509 | Required parameters: none |
---|
| 2510 | |
---|
| 2511 | Optional parameters: version, msgtype |
---|
| 2512 | |
---|
| 2513 | |
---|
| 2514 | |
---|
| 2515 | |
---|
| 2516 | |
---|
| 2517 | |
---|
| 2518 | |
---|
| 2519 | Fielding, et al. Expires May 20, 2009 [Page 45] |
---|
| 2520 | |
---|
| 2521 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2522 | |
---|
| 2523 | |
---|
| 2524 | version: The HTTP-Version number of the enclosed messages (e.g., |
---|
| 2525 | "1.1"). If not present, the version can be determined from the |
---|
| 2526 | first line of the body. |
---|
| 2527 | |
---|
| 2528 | msgtype: The message type -- "request" or "response". If not |
---|
| 2529 | present, the type can be determined from the first line of the |
---|
| 2530 | body. |
---|
| 2531 | |
---|
| 2532 | Encoding considerations: HTTP messages enclosed by this type are in |
---|
| 2533 | "binary" format; use of an appropriate Content-Transfer-Encoding |
---|
| 2534 | is required when transmitted via E-mail. |
---|
| 2535 | |
---|
| 2536 | Security considerations: none |
---|
| 2537 | |
---|
| 2538 | Interoperability considerations: none |
---|
| 2539 | |
---|
| 2540 | Published specification: This specification (see Section 9.3.2). |
---|
| 2541 | |
---|
| 2542 | Applications that use this media type: |
---|
| 2543 | |
---|
| 2544 | Additional information: |
---|
| 2545 | |
---|
| 2546 | Magic number(s): none |
---|
| 2547 | |
---|
| 2548 | File extension(s): none |
---|
| 2549 | |
---|
| 2550 | Macintosh file type code(s): none |
---|
| 2551 | |
---|
| 2552 | Person and email address to contact for further information: See |
---|
| 2553 | Authors Section. |
---|
| 2554 | |
---|
| 2555 | Intended usage: COMMON |
---|
| 2556 | |
---|
| 2557 | Restrictions on usage: none |
---|
| 2558 | |
---|
| 2559 | Author/Change controller: IESG |
---|
| 2560 | |
---|
| 2561 | |
---|
| 2562 | 10. Security Considerations |
---|
| 2563 | |
---|
| 2564 | This section is meant to inform application developers, information |
---|
| 2565 | providers, and users of the security limitations in HTTP/1.1 as |
---|
| 2566 | described by this document. The discussion does not include |
---|
| 2567 | definitive solutions to the problems revealed, though it does make |
---|
| 2568 | some suggestions for reducing security risks. |
---|
| 2569 | |
---|
| 2570 | |
---|
| 2571 | |
---|
| 2572 | |
---|
| 2573 | |
---|
| 2574 | |
---|
| 2575 | Fielding, et al. Expires May 20, 2009 [Page 46] |
---|
| 2576 | |
---|
| 2577 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2578 | |
---|
| 2579 | |
---|
| 2580 | 10.1. Personal Information |
---|
| 2581 | |
---|
| 2582 | HTTP clients are often privy to large amounts of personal information |
---|
| 2583 | (e.g. the user's name, location, mail address, passwords, encryption |
---|
| 2584 | keys, etc.), and SHOULD be very careful to prevent unintentional |
---|
| 2585 | leakage of this information. We very strongly recommend that a |
---|
| 2586 | convenient interface be provided for the user to control |
---|
| 2587 | dissemination of such information, and that designers and |
---|
| 2588 | implementors be particularly careful in this area. History shows |
---|
| 2589 | that errors in this area often create serious security and/or privacy |
---|
| 2590 | problems and generate highly adverse publicity for the implementor's |
---|
| 2591 | company. |
---|
| 2592 | |
---|
| 2593 | 10.2. Abuse of Server Log Information |
---|
| 2594 | |
---|
| 2595 | A server is in the position to save personal data about a user's |
---|
| 2596 | requests which might identify their reading patterns or subjects of |
---|
| 2597 | interest. This information is clearly confidential in nature and its |
---|
| 2598 | handling can be constrained by law in certain countries. People |
---|
| 2599 | using HTTP to provide data are responsible for ensuring that such |
---|
| 2600 | material is not distributed without the permission of any individuals |
---|
| 2601 | that are identifiable by the published results. |
---|
| 2602 | |
---|
| 2603 | 10.3. Attacks Based On File and Path Names |
---|
| 2604 | |
---|
| 2605 | Implementations of HTTP origin servers SHOULD be careful to restrict |
---|
| 2606 | the documents returned by HTTP requests to be only those that were |
---|
| 2607 | intended by the server administrators. If an HTTP server translates |
---|
| 2608 | HTTP URIs directly into file system calls, the server MUST take |
---|
| 2609 | special care not to serve files that were not intended to be |
---|
| 2610 | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |
---|
| 2611 | other operating systems use ".." as a path component to indicate a |
---|
| 2612 | directory level above the current one. On such a system, an HTTP |
---|
| 2613 | server MUST disallow any such construct in the Request-URI if it |
---|
| 2614 | would otherwise allow access to a resource outside those intended to |
---|
| 2615 | be accessible via the HTTP server. Similarly, files intended for |
---|
| 2616 | reference only internally to the server (such as access control |
---|
| 2617 | files, configuration files, and script code) MUST be protected from |
---|
| 2618 | inappropriate retrieval, since they might contain sensitive |
---|
| 2619 | information. Experience has shown that minor bugs in such HTTP |
---|
| 2620 | server implementations have turned into security risks. |
---|
| 2621 | |
---|
| 2622 | 10.4. DNS Spoofing |
---|
| 2623 | |
---|
| 2624 | Clients using HTTP rely heavily on the Domain Name Service, and are |
---|
| 2625 | thus generally prone to security attacks based on the deliberate mis- |
---|
| 2626 | association of IP addresses and DNS names. Clients need to be |
---|
| 2627 | cautious in assuming the continuing validity of an IP number/DNS name |
---|
| 2628 | |
---|
| 2629 | |
---|
| 2630 | |
---|
| 2631 | Fielding, et al. Expires May 20, 2009 [Page 47] |
---|
| 2632 | |
---|
| 2633 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2634 | |
---|
| 2635 | |
---|
| 2636 | association. |
---|
| 2637 | |
---|
| 2638 | In particular, HTTP clients SHOULD rely on their name resolver for |
---|
| 2639 | confirmation of an IP number/DNS name association, rather than |
---|
| 2640 | caching the result of previous host name lookups. Many platforms |
---|
| 2641 | already can cache host name lookups locally when appropriate, and |
---|
| 2642 | they SHOULD be configured to do so. It is proper for these lookups |
---|
| 2643 | to be cached, however, only when the TTL (Time To Live) information |
---|
| 2644 | reported by the name server makes it likely that the cached |
---|
| 2645 | information will remain useful. |
---|
| 2646 | |
---|
| 2647 | If HTTP clients cache the results of host name lookups in order to |
---|
| 2648 | achieve a performance improvement, they MUST observe the TTL |
---|
| 2649 | information reported by DNS. |
---|
| 2650 | |
---|
| 2651 | If HTTP clients do not observe this rule, they could be spoofed when |
---|
| 2652 | a previously-accessed server's IP address changes. As network |
---|
| 2653 | renumbering is expected to become increasingly common [RFC1900], the |
---|
| 2654 | possibility of this form of attack will grow. Observing this |
---|
| 2655 | requirement thus reduces this potential security vulnerability. |
---|
| 2656 | |
---|
| 2657 | This requirement also improves the load-balancing behavior of clients |
---|
| 2658 | for replicated servers using the same DNS name and reduces the |
---|
| 2659 | likelihood of a user's experiencing failure in accessing sites which |
---|
| 2660 | use that strategy. |
---|
| 2661 | |
---|
| 2662 | 10.5. Proxies and Caching |
---|
| 2663 | |
---|
| 2664 | By their very nature, HTTP proxies are men-in-the-middle, and |
---|
| 2665 | represent an opportunity for man-in-the-middle attacks. Compromise |
---|
| 2666 | of the systems on which the proxies run can result in serious |
---|
| 2667 | security and privacy problems. Proxies have access to security- |
---|
| 2668 | related information, personal information about individual users and |
---|
| 2669 | organizations, and proprietary information belonging to users and |
---|
| 2670 | content providers. A compromised proxy, or a proxy implemented or |
---|
| 2671 | configured without regard to security and privacy considerations, |
---|
| 2672 | might be used in the commission of a wide range of potential attacks. |
---|
| 2673 | |
---|
| 2674 | Proxy operators should protect the systems on which proxies run as |
---|
| 2675 | they would protect any system that contains or transports sensitive |
---|
| 2676 | information. In particular, log information gathered at proxies |
---|
| 2677 | often contains highly sensitive personal information, and/or |
---|
| 2678 | information about organizations. Log information should be carefully |
---|
| 2679 | guarded, and appropriate guidelines for use developed and followed. |
---|
| 2680 | (Section 10.2). |
---|
| 2681 | |
---|
| 2682 | Proxy implementors should consider the privacy and security |
---|
| 2683 | implications of their design and coding decisions, and of the |
---|
| 2684 | |
---|
| 2685 | |
---|
| 2686 | |
---|
| 2687 | Fielding, et al. Expires May 20, 2009 [Page 48] |
---|
| 2688 | |
---|
| 2689 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2690 | |
---|
| 2691 | |
---|
| 2692 | configuration options they provide to proxy operators (especially the |
---|
| 2693 | default configuration). |
---|
| 2694 | |
---|
| 2695 | Users of a proxy need to be aware that they are no trustworthier than |
---|
| 2696 | the people who run the proxy; HTTP itself cannot solve this problem. |
---|
| 2697 | |
---|
| 2698 | The judicious use of cryptography, when appropriate, may suffice to |
---|
| 2699 | protect against a broad range of security and privacy attacks. Such |
---|
| 2700 | cryptography is beyond the scope of the HTTP/1.1 specification. |
---|
| 2701 | |
---|
| 2702 | 10.6. Denial of Service Attacks on Proxies |
---|
| 2703 | |
---|
| 2704 | They exist. They are hard to defend against. Research continues. |
---|
| 2705 | Beware. |
---|
| 2706 | |
---|
| 2707 | |
---|
| 2708 | 11. Acknowledgments |
---|
| 2709 | |
---|
| 2710 | HTTP has evolved considerably over the years. It has benefited from |
---|
| 2711 | a large and active developer community--the many people who have |
---|
| 2712 | participated on the www-talk mailing list--and it is that community |
---|
| 2713 | which has been most responsible for the success of HTTP and of the |
---|
| 2714 | World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel |
---|
| 2715 | W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. |
---|
| 2716 | Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, |
---|
| 2717 | Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |
---|
| 2718 | recognition for their efforts in defining early aspects of the |
---|
| 2719 | protocol. |
---|
| 2720 | |
---|
| 2721 | This document has benefited greatly from the comments of all those |
---|
| 2722 | participating in the HTTP-WG. In addition to those already |
---|
| 2723 | mentioned, the following individuals have contributed to this |
---|
| 2724 | specification: |
---|
| 2725 | |
---|
| 2726 | Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |
---|
| 2727 | Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, |
---|
| 2728 | Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc |
---|
| 2729 | Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel |
---|
| 2730 | Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, |
---|
| 2731 | David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert |
---|
| 2732 | Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David |
---|
| 2733 | Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott |
---|
| 2734 | Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich |
---|
| 2735 | Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, |
---|
| 2736 | Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) |
---|
| 2737 | Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. |
---|
| 2738 | |
---|
| 2739 | Thanks to the "cave men" of Palo Alto. You know who you are. |
---|
| 2740 | |
---|
| 2741 | |
---|
| 2742 | |
---|
| 2743 | Fielding, et al. Expires May 20, 2009 [Page 49] |
---|
| 2744 | |
---|
| 2745 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2746 | |
---|
| 2747 | |
---|
| 2748 | Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy |
---|
| 2749 | Fielding, the editor of [RFC2068], along with John Klensin, Jeff |
---|
| 2750 | Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh |
---|
| 2751 | Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their |
---|
| 2752 | help. And thanks go particularly to Jeff Mogul and Scott Lawrence |
---|
| 2753 | for performing the "MUST/MAY/SHOULD" audit. |
---|
| 2754 | |
---|
| 2755 | The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik |
---|
| 2756 | Frystyk implemented RFC 2068 early, and we wish to thank them for the |
---|
| 2757 | discovery of many of the problems that this document attempts to |
---|
| 2758 | rectify. |
---|
| 2759 | |
---|
| 2760 | This specification makes heavy use of the augmented BNF and generic |
---|
| 2761 | constructs defined by David H. Crocker for [RFC5234]. Similarly, it |
---|
| 2762 | reuses many of the definitions provided by Nathaniel Borenstein and |
---|
| 2763 | Ned Freed for MIME [RFC2045]. We hope that their inclusion in this |
---|
| 2764 | specification will help reduce past confusion over the relationship |
---|
| 2765 | between HTTP and Internet mail message formats. |
---|
| 2766 | |
---|
| 2767 | |
---|
| 2768 | 12. References |
---|
| 2769 | |
---|
| 2770 | 12.1. Normative References |
---|
| 2771 | |
---|
| 2772 | [ISO-8859-1] |
---|
| 2773 | International Organization for Standardization, |
---|
| 2774 | "Information technology -- 8-bit single-byte coded graphic |
---|
| 2775 | character sets -- Part 1: Latin alphabet No. 1", ISO/ |
---|
| 2776 | IEC 8859-1:1998, 1998. |
---|
| 2777 | |
---|
| 2778 | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
| 2779 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
| 2780 | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
---|
| 2781 | Semantics", draft-ietf-httpbis-p2-semantics-05 (work in |
---|
| 2782 | progress), November 2008. |
---|
| 2783 | |
---|
| 2784 | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
| 2785 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
| 2786 | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
---|
| 2787 | and Content Negotiation", draft-ietf-httpbis-p3-payload-05 |
---|
| 2788 | (work in progress), November 2008. |
---|
| 2789 | |
---|
| 2790 | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
| 2791 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
| 2792 | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
---|
| 2793 | Partial Responses", draft-ietf-httpbis-p5-range-05 (work |
---|
| 2794 | in progress), November 2008. |
---|
| 2795 | |
---|
| 2796 | |
---|
| 2797 | |
---|
| 2798 | |
---|
| 2799 | Fielding, et al. Expires May 20, 2009 [Page 50] |
---|
| 2800 | |
---|
| 2801 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2802 | |
---|
| 2803 | |
---|
| 2804 | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
| 2805 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
| 2806 | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
---|
| 2807 | draft-ietf-httpbis-p6-cache-05 (work in progress), |
---|
| 2808 | November 2008. |
---|
| 2809 | |
---|
| 2810 | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
---|
| 2811 | Extensions (MIME) Part One: Format of Internet Message |
---|
| 2812 | Bodies", RFC 2045, November 1996. |
---|
| 2813 | |
---|
| 2814 | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |
---|
| 2815 | Part Three: Message Header Extensions for Non-ASCII Text", |
---|
| 2816 | RFC 2047, November 1996. |
---|
| 2817 | |
---|
| 2818 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
---|
| 2819 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
---|
| 2820 | |
---|
| 2821 | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
---|
| 2822 | Resource Identifier (URI): Generic Syntax", RFC 3986, |
---|
| 2823 | STD 66, January 2005. |
---|
| 2824 | |
---|
| 2825 | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
---|
| 2826 | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
---|
| 2827 | |
---|
| 2828 | [USASCII] American National Standards Institute, "Coded Character |
---|
| 2829 | Set -- 7-bit American Standard Code for Information |
---|
| 2830 | Interchange", ANSI X3.4, 1986. |
---|
| 2831 | |
---|
| 2832 | 12.2. Informative References |
---|
| 2833 | |
---|
| 2834 | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
---|
| 2835 | Politics", ACM Transactions on Internet Technology Vol. 1, |
---|
| 2836 | #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. |
---|
| 2837 | |
---|
| 2838 | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |
---|
| 2839 | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |
---|
| 2840 | and PNG", ACM Proceedings of the ACM SIGCOMM '97 |
---|
| 2841 | conference on Applications, technologies, architectures, |
---|
| 2842 | and protocols for computer communication SIGCOMM '97, |
---|
| 2843 | September 1997, |
---|
| 2844 | <http://doi.acm.org/10.1145/263105.263157>. |
---|
| 2845 | |
---|
| 2846 | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |
---|
| 2847 | Computer Networks and ISDN Systems v. 28, pp. 25-35, |
---|
| 2848 | December 1995, |
---|
| 2849 | <http://portal.acm.org/citation.cfm?id=219094>. |
---|
| 2850 | |
---|
| 2851 | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application |
---|
| 2852 | |
---|
| 2853 | |
---|
| 2854 | |
---|
| 2855 | Fielding, et al. Expires May 20, 2009 [Page 51] |
---|
| 2856 | |
---|
| 2857 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2858 | |
---|
| 2859 | |
---|
| 2860 | and Support", STD 3, RFC 1123, October 1989. |
---|
| 2861 | |
---|
| 2862 | [RFC1305] Mills, D., "Network Time Protocol (Version 3) |
---|
| 2863 | Specification, Implementation", RFC 1305, March 1992. |
---|
| 2864 | |
---|
| 2865 | [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., |
---|
| 2866 | Torrey, D., and B. Alberti, "The Internet Gopher Protocol |
---|
| 2867 | (a distributed document search and retrieval protocol)", |
---|
| 2868 | RFC 1436, March 1993. |
---|
| 2869 | |
---|
| 2870 | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |
---|
| 2871 | RFC 1900, February 1996. |
---|
| 2872 | |
---|
| 2873 | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
---|
| 2874 | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
---|
| 2875 | |
---|
| 2876 | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
---|
| 2877 | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
---|
| 2878 | RFC 2068, January 1997. |
---|
| 2879 | |
---|
| 2880 | [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management |
---|
| 2881 | Mechanism", RFC 2109, February 1997. |
---|
| 2882 | |
---|
| 2883 | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |
---|
| 2884 | and Interpretation of HTTP Version Numbers", RFC 2145, |
---|
| 2885 | May 1997. |
---|
| 2886 | |
---|
| 2887 | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
---|
| 2888 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
---|
| 2889 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
---|
| 2890 | |
---|
| 2891 | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |
---|
| 2892 | |
---|
| 2893 | [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management |
---|
| 2894 | Mechanism", RFC 2965, October 2000. |
---|
| 2895 | |
---|
| 2896 | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
---|
| 2897 | Procedures for Message Header Fields", BCP 90, RFC 3864, |
---|
| 2898 | September 2004. |
---|
| 2899 | |
---|
| 2900 | [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", |
---|
| 2901 | RFC 3977, October 2006. |
---|
| 2902 | |
---|
| 2903 | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
---|
| 2904 | Registration Procedures", BCP 13, RFC 4288, December 2005. |
---|
| 2905 | |
---|
| 2906 | [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and |
---|
| 2907 | Registration Procedures for New URI Schemes", BCP 115, |
---|
| 2908 | |
---|
| 2909 | |
---|
| 2910 | |
---|
| 2911 | Fielding, et al. Expires May 20, 2009 [Page 52] |
---|
| 2912 | |
---|
| 2913 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2914 | |
---|
| 2915 | |
---|
| 2916 | RFC 4395, February 2006. |
---|
| 2917 | |
---|
| 2918 | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
---|
| 2919 | October 2008. |
---|
| 2920 | |
---|
| 2921 | [RFC822] Crocker, D., "Standard for the format of ARPA Internet |
---|
| 2922 | text messages", STD 11, RFC 822, August 1982. |
---|
| 2923 | |
---|
| 2924 | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", |
---|
| 2925 | STD 9, RFC 959, October 1985. |
---|
| 2926 | |
---|
| 2927 | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
---|
| 2928 | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
---|
| 2929 | |
---|
| 2930 | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |
---|
| 2931 | HTTP Performance", ISI Research Report ISI/RR-98-463, |
---|
| 2932 | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |
---|
| 2933 | |
---|
| 2934 | (original report dated Aug. 1996) |
---|
| 2935 | |
---|
| 2936 | [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., |
---|
| 2937 | Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface |
---|
| 2938 | Protocol Prototype Functional Specification (v1.5)", |
---|
| 2939 | Thinking Machines Corporation , April 1990. |
---|
| 2940 | |
---|
| 2941 | |
---|
| 2942 | Appendix A. Tolerant Applications |
---|
| 2943 | |
---|
| 2944 | Although this document specifies the requirements for the generation |
---|
| 2945 | of HTTP/1.1 messages, not all applications will be correct in their |
---|
| 2946 | implementation. We therefore recommend that operational applications |
---|
| 2947 | be tolerant of deviations whenever those deviations can be |
---|
| 2948 | interpreted unambiguously. |
---|
| 2949 | |
---|
| 2950 | Clients SHOULD be tolerant in parsing the Status-Line and servers |
---|
| 2951 | tolerant when parsing the Request-Line. In particular, they SHOULD |
---|
| 2952 | accept any amount of SP or HTAB characters between fields, even |
---|
| 2953 | though only a single SP is required. |
---|
| 2954 | |
---|
| 2955 | The line terminator for message-header fields is the sequence CRLF. |
---|
| 2956 | However, we recommend that applications, when parsing such headers, |
---|
| 2957 | recognize a single LF as a line terminator and ignore the leading CR. |
---|
| 2958 | |
---|
| 2959 | The character set of an entity-body SHOULD be labeled as the lowest |
---|
| 2960 | common denominator of the character codes used within that body, with |
---|
| 2961 | the exception that not labeling the entity is preferred over labeling |
---|
| 2962 | the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. |
---|
| 2963 | |
---|
| 2964 | |
---|
| 2965 | |
---|
| 2966 | |
---|
| 2967 | Fielding, et al. Expires May 20, 2009 [Page 53] |
---|
| 2968 | |
---|
| 2969 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 2970 | |
---|
| 2971 | |
---|
| 2972 | Additional rules for requirements on parsing and encoding of dates |
---|
| 2973 | and other potential problems with date encodings include: |
---|
| 2974 | |
---|
| 2975 | o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |
---|
| 2976 | which appears to be more than 50 years in the future is in fact in |
---|
| 2977 | the past (this helps solve the "year 2000" problem). |
---|
| 2978 | |
---|
| 2979 | o An HTTP/1.1 implementation MAY internally represent a parsed |
---|
| 2980 | Expires date as earlier than the proper value, but MUST NOT |
---|
| 2981 | internally represent a parsed Expires date as later than the |
---|
| 2982 | proper value. |
---|
| 2983 | |
---|
| 2984 | o All expiration-related calculations MUST be done in GMT. The |
---|
| 2985 | local time zone MUST NOT influence the calculation or comparison |
---|
| 2986 | of an age or expiration time. |
---|
| 2987 | |
---|
| 2988 | o If an HTTP header incorrectly carries a date value with a time |
---|
| 2989 | zone other than GMT, it MUST be converted into GMT using the most |
---|
| 2990 | conservative possible conversion. |
---|
| 2991 | |
---|
| 2992 | |
---|
| 2993 | Appendix B. Conversion of Date Formats |
---|
| 2994 | |
---|
| 2995 | HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to |
---|
| 2996 | simplify the process of date comparison. Proxies and gateways from |
---|
| 2997 | other protocols SHOULD ensure that any Date header field present in a |
---|
| 2998 | message conforms to one of the HTTP/1.1 formats and rewrite the date |
---|
| 2999 | if necessary. |
---|
| 3000 | |
---|
| 3001 | |
---|
| 3002 | Appendix C. Compatibility with Previous Versions |
---|
| 3003 | |
---|
| 3004 | HTTP has been in use by the World-Wide Web global information |
---|
| 3005 | initiative since 1990. The first version of HTTP, later referred to |
---|
| 3006 | as HTTP/0.9, was a simple protocol for hypertext data transfer across |
---|
| 3007 | the Internet with only a single method and no metadata. HTTP/1.0, as |
---|
| 3008 | defined by [RFC1945], added a range of request methods and MIME-like |
---|
| 3009 | messaging that could include metadata about the data transferred and |
---|
| 3010 | modifiers on the request/response semantics. However, HTTP/1.0 did |
---|
| 3011 | not sufficiently take into consideration the effects of hierarchical |
---|
| 3012 | proxies, caching, the need for persistent connections, or name-based |
---|
| 3013 | virtual hosts. The proliferation of incompletely-implemented |
---|
| 3014 | applications calling themselves "HTTP/1.0" further necessitated a |
---|
| 3015 | protocol version change in order for two communicating applications |
---|
| 3016 | to determine each other's true capabilities. |
---|
| 3017 | |
---|
| 3018 | HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent |
---|
| 3019 | requirements that enable reliable implementations, adding only those |
---|
| 3020 | |
---|
| 3021 | |
---|
| 3022 | |
---|
| 3023 | Fielding, et al. Expires May 20, 2009 [Page 54] |
---|
| 3024 | |
---|
| 3025 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3026 | |
---|
| 3027 | |
---|
| 3028 | new features that will either be safely ignored by an HTTP/1.0 |
---|
| 3029 | recipient or only sent when communicating with a party advertising |
---|
| 3030 | compliance with HTTP/1.1. |
---|
| 3031 | |
---|
| 3032 | It is beyond the scope of a protocol specification to mandate |
---|
| 3033 | compliance with previous versions. HTTP/1.1 was deliberately |
---|
| 3034 | designed, however, to make supporting previous versions easy. It is |
---|
| 3035 | worth noting that, at the time of composing this specification |
---|
| 3036 | (1996), we would expect commercial HTTP/1.1 servers to: |
---|
| 3037 | |
---|
| 3038 | o recognize the format of the Request-Line for HTTP/0.9, 1.0, and |
---|
| 3039 | 1.1 requests; |
---|
| 3040 | |
---|
| 3041 | o understand any valid request in the format of HTTP/0.9, 1.0, or |
---|
| 3042 | 1.1; |
---|
| 3043 | |
---|
| 3044 | o respond appropriately with a message in the same major version |
---|
| 3045 | used by the client. |
---|
| 3046 | |
---|
| 3047 | And we would expect HTTP/1.1 clients to: |
---|
| 3048 | |
---|
| 3049 | o recognize the format of the Status-Line for HTTP/1.0 and 1.1 |
---|
| 3050 | responses; |
---|
| 3051 | |
---|
| 3052 | o understand any valid response in the format of HTTP/0.9, 1.0, or |
---|
| 3053 | 1.1. |
---|
| 3054 | |
---|
| 3055 | For most implementations of HTTP/1.0, each connection is established |
---|
| 3056 | by the client prior to the request and closed by the server after |
---|
| 3057 | sending the response. Some implementations implement the Keep-Alive |
---|
| 3058 | version of persistent connections described in Section 19.7.1 of |
---|
| 3059 | [RFC2068]. |
---|
| 3060 | |
---|
| 3061 | C.1. Changes from HTTP/1.0 |
---|
| 3062 | |
---|
| 3063 | This section summarizes major differences between versions HTTP/1.0 |
---|
| 3064 | and HTTP/1.1. |
---|
| 3065 | |
---|
| 3066 | C.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |
---|
| 3067 | Addresses |
---|
| 3068 | |
---|
| 3069 | The requirements that clients and servers support the Host request- |
---|
| 3070 | header, report an error if the Host request-header (Section 8.4) is |
---|
| 3071 | missing from an HTTP/1.1 request, and accept absolute URIs |
---|
| 3072 | (Section 5.1.2) are among the most important changes defined by this |
---|
| 3073 | specification. |
---|
| 3074 | |
---|
| 3075 | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
---|
| 3076 | |
---|
| 3077 | |
---|
| 3078 | |
---|
| 3079 | Fielding, et al. Expires May 20, 2009 [Page 55] |
---|
| 3080 | |
---|
| 3081 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3082 | |
---|
| 3083 | |
---|
| 3084 | addresses and servers; there was no other established mechanism for |
---|
| 3085 | distinguishing the intended server of a request than the IP address |
---|
| 3086 | to which that request was directed. The changes outlined above will |
---|
| 3087 | allow the Internet, once older HTTP clients are no longer common, to |
---|
| 3088 | support multiple Web sites from a single IP address, greatly |
---|
| 3089 | simplifying large operational Web servers, where allocation of many |
---|
| 3090 | IP addresses to a single host has created serious problems. The |
---|
| 3091 | Internet will also be able to recover the IP addresses that have been |
---|
| 3092 | allocated for the sole purpose of allowing special-purpose domain |
---|
| 3093 | names to be used in root-level HTTP URLs. Given the rate of growth |
---|
| 3094 | of the Web, and the number of servers already deployed, it is |
---|
| 3095 | extremely important that all implementations of HTTP (including |
---|
| 3096 | updates to existing HTTP/1.0 applications) correctly implement these |
---|
| 3097 | requirements: |
---|
| 3098 | |
---|
| 3099 | o Both clients and servers MUST support the Host request-header. |
---|
| 3100 | |
---|
| 3101 | o A client that sends an HTTP/1.1 request MUST send a Host header. |
---|
| 3102 | |
---|
| 3103 | o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |
---|
| 3104 | request does not include a Host request-header. |
---|
| 3105 | |
---|
| 3106 | o Servers MUST accept absolute URIs. |
---|
| 3107 | |
---|
| 3108 | C.2. Compatibility with HTTP/1.0 Persistent Connections |
---|
| 3109 | |
---|
| 3110 | Some clients and servers might wish to be compatible with some |
---|
| 3111 | previous implementations of persistent connections in HTTP/1.0 |
---|
| 3112 | clients and servers. Persistent connections in HTTP/1.0 are |
---|
| 3113 | explicitly negotiated as they are not the default behavior. HTTP/1.0 |
---|
| 3114 | experimental implementations of persistent connections are faulty, |
---|
| 3115 | and the new facilities in HTTP/1.1 are designed to rectify these |
---|
| 3116 | problems. The problem was that some existing 1.0 clients may be |
---|
| 3117 | sending Keep-Alive to a proxy server that doesn't understand |
---|
| 3118 | Connection, which would then erroneously forward it to the next |
---|
| 3119 | inbound server, which would establish the Keep-Alive connection and |
---|
| 3120 | result in a hung HTTP/1.0 proxy waiting for the close on the |
---|
| 3121 | response. The result is that HTTP/1.0 clients must be prevented from |
---|
| 3122 | using Keep-Alive when talking to proxies. |
---|
| 3123 | |
---|
| 3124 | However, talking to proxies is the most important use of persistent |
---|
| 3125 | connections, so that prohibition is clearly unacceptable. Therefore, |
---|
| 3126 | we need some other mechanism for indicating a persistent connection |
---|
| 3127 | is desired, which is safe to use even when talking to an old proxy |
---|
| 3128 | that ignores Connection. Persistent connections are the default for |
---|
| 3129 | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
---|
| 3130 | declaring non-persistence. See Section 8.1. |
---|
| 3131 | |
---|
| 3132 | |
---|
| 3133 | |
---|
| 3134 | |
---|
| 3135 | Fielding, et al. Expires May 20, 2009 [Page 56] |
---|
| 3136 | |
---|
| 3137 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3138 | |
---|
| 3139 | |
---|
| 3140 | The original HTTP/1.0 form of persistent connections (the Connection: |
---|
| 3141 | Keep-Alive and Keep-Alive header) is documented in [RFC2068]. |
---|
| 3142 | |
---|
| 3143 | C.3. Changes from RFC 2068 |
---|
| 3144 | |
---|
| 3145 | This specification has been carefully audited to correct and |
---|
| 3146 | disambiguate key word usage; RFC 2068 had many problems in respect to |
---|
| 3147 | the conventions laid out in [RFC2119]. |
---|
| 3148 | |
---|
| 3149 | Transfer-coding and message lengths all interact in ways that |
---|
| 3150 | required fixing exactly when chunked encoding is used (to allow for |
---|
| 3151 | transfer encoding that may not be self delimiting); it was important |
---|
| 3152 | to straighten out exactly how message lengths are computed. |
---|
| 3153 | (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) |
---|
| 3154 | |
---|
| 3155 | The use and interpretation of HTTP version numbers has been clarified |
---|
| 3156 | by [RFC2145]. Require proxies to upgrade requests to highest |
---|
| 3157 | protocol version they support to deal with problems discovered in |
---|
| 3158 | HTTP/1.0 implementations (Section 3.1) |
---|
| 3159 | |
---|
| 3160 | Transfer-coding had significant problems, particularly with |
---|
| 3161 | interactions with chunked encoding. The solution is that transfer- |
---|
| 3162 | codings become as full fledged as content-codings. This involves |
---|
| 3163 | adding an IANA registry for transfer-codings (separate from content |
---|
| 3164 | codings), a new header field (TE) and enabling trailer headers in the |
---|
| 3165 | future. Transfer encoding is a major performance benefit, so it was |
---|
| 3166 | worth fixing [Nie1997]. TE also solves another, obscure, downward |
---|
| 3167 | interoperability problem that could have occurred due to interactions |
---|
| 3168 | between authentication trailers, chunked encoding and HTTP/1.0 |
---|
| 3169 | clients.(Section 3.4, 3.4.1, and 8.5) |
---|
| 3170 | |
---|
| 3171 | C.4. Changes from RFC 2616 |
---|
| 3172 | |
---|
| 3173 | Rules about implicit linear white space between certain grammar |
---|
| 3174 | productions have been removed; now it's only allowed when |
---|
| 3175 | specifically pointed out in the ABNF. The CHAR rule does not allow |
---|
| 3176 | the NUL character anymore (this affects the comment and quoted-string |
---|
| 3177 | rules). Furthermore, the quoted-pair rule does not allow escaping |
---|
| 3178 | NUL, CR or LF anymore. (Section 2.2) |
---|
| 3179 | |
---|
| 3180 | Clarify that HTTP-Version is case sensitive. (Section 3.1) |
---|
| 3181 | |
---|
| 3182 | Remove reference to non-existant identity transfer-coding value |
---|
| 3183 | tokens. (Sections 3.4 and 4.4) |
---|
| 3184 | |
---|
| 3185 | Clarification that the chunk length does not include the count of the |
---|
| 3186 | octets in the chunk header and trailer. (Section 3.4.1) |
---|
| 3187 | |
---|
| 3188 | |
---|
| 3189 | |
---|
| 3190 | |
---|
| 3191 | Fielding, et al. Expires May 20, 2009 [Page 57] |
---|
| 3192 | |
---|
| 3193 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3194 | |
---|
| 3195 | |
---|
| 3196 | Update use of abs_path production from RFC1808 to the path-absolute + |
---|
| 3197 | query components of RFC3986. (Section 5.1.2) |
---|
| 3198 | |
---|
| 3199 | Clarify exactly when close connection options must be sent. |
---|
| 3200 | (Section 8.1) |
---|
| 3201 | |
---|
| 3202 | |
---|
| 3203 | Appendix D. Terminology |
---|
| 3204 | |
---|
| 3205 | This specification uses a number of terms to refer to the roles |
---|
| 3206 | played by participants in, and objects of, the HTTP communication. |
---|
| 3207 | |
---|
| 3208 | connection |
---|
| 3209 | |
---|
| 3210 | A transport layer virtual circuit established between two programs |
---|
| 3211 | for the purpose of communication. |
---|
| 3212 | |
---|
| 3213 | message |
---|
| 3214 | |
---|
| 3215 | The basic unit of HTTP communication, consisting of a structured |
---|
| 3216 | sequence of octets matching the syntax defined in Section 4 and |
---|
| 3217 | transmitted via the connection. |
---|
| 3218 | |
---|
| 3219 | request |
---|
| 3220 | |
---|
| 3221 | An HTTP request message, as defined in Section 5. |
---|
| 3222 | |
---|
| 3223 | response |
---|
| 3224 | |
---|
| 3225 | An HTTP response message, as defined in Section 6. |
---|
| 3226 | |
---|
| 3227 | resource |
---|
| 3228 | |
---|
| 3229 | A network data object or service that can be identified by a URI, |
---|
| 3230 | as defined in Section 3.2. Resources may be available in multiple |
---|
| 3231 | representations (e.g. multiple languages, data formats, size, and |
---|
| 3232 | resolutions) or vary in other ways. |
---|
| 3233 | |
---|
| 3234 | entity |
---|
| 3235 | |
---|
| 3236 | The information transferred as the payload of a request or |
---|
| 3237 | response. An entity consists of metainformation in the form of |
---|
| 3238 | entity-header fields and content in the form of an entity-body, as |
---|
| 3239 | described in Section 4 of [Part3]. |
---|
| 3240 | |
---|
| 3241 | representation |
---|
| 3242 | |
---|
| 3243 | |
---|
| 3244 | |
---|
| 3245 | |
---|
| 3246 | |
---|
| 3247 | Fielding, et al. Expires May 20, 2009 [Page 58] |
---|
| 3248 | |
---|
| 3249 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3250 | |
---|
| 3251 | |
---|
| 3252 | An entity included with a response that is subject to content |
---|
| 3253 | negotiation, as described in Section 5 of [Part3]. There may |
---|
| 3254 | exist multiple representations associated with a particular |
---|
| 3255 | response status. |
---|
| 3256 | |
---|
| 3257 | content negotiation |
---|
| 3258 | |
---|
| 3259 | The mechanism for selecting the appropriate representation when |
---|
| 3260 | servicing a request, as described in Section 5 of [Part3]. The |
---|
| 3261 | representation of entities in any response can be negotiated |
---|
| 3262 | (including error responses). |
---|
| 3263 | |
---|
| 3264 | variant |
---|
| 3265 | |
---|
| 3266 | A resource may have one, or more than one, representation(s) |
---|
| 3267 | associated with it at any given instant. Each of these |
---|
| 3268 | representations is termed a `variant'. Use of the term `variant' |
---|
| 3269 | does not necessarily imply that the resource is subject to content |
---|
| 3270 | negotiation. |
---|
| 3271 | |
---|
| 3272 | client |
---|
| 3273 | |
---|
| 3274 | A program that establishes connections for the purpose of sending |
---|
| 3275 | requests. |
---|
| 3276 | |
---|
| 3277 | user agent |
---|
| 3278 | |
---|
| 3279 | The client which initiates a request. These are often browsers, |
---|
| 3280 | editors, spiders (web-traversing robots), or other end user tools. |
---|
| 3281 | |
---|
| 3282 | server |
---|
| 3283 | |
---|
| 3284 | An application program that accepts connections in order to |
---|
| 3285 | service requests by sending back responses. Any given program may |
---|
| 3286 | be capable of being both a client and a server; our use of these |
---|
| 3287 | terms refers only to the role being performed by the program for a |
---|
| 3288 | particular connection, rather than to the program's capabilities |
---|
| 3289 | in general. Likewise, any server may act as an origin server, |
---|
| 3290 | proxy, gateway, or tunnel, switching behavior based on the nature |
---|
| 3291 | of each request. |
---|
| 3292 | |
---|
| 3293 | origin server |
---|
| 3294 | |
---|
| 3295 | The server on which a given resource resides or is to be created. |
---|
| 3296 | |
---|
| 3297 | proxy |
---|
| 3298 | |
---|
| 3299 | |
---|
| 3300 | |
---|
| 3301 | |
---|
| 3302 | |
---|
| 3303 | Fielding, et al. Expires May 20, 2009 [Page 59] |
---|
| 3304 | |
---|
| 3305 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3306 | |
---|
| 3307 | |
---|
| 3308 | An intermediary program which acts as both a server and a client |
---|
| 3309 | for the purpose of making requests on behalf of other clients. |
---|
| 3310 | Requests are serviced internally or by passing them on, with |
---|
| 3311 | possible translation, to other servers. A proxy MUST implement |
---|
| 3312 | both the client and server requirements of this specification. A |
---|
| 3313 | "transparent proxy" is a proxy that does not modify the request or |
---|
| 3314 | response beyond what is required for proxy authentication and |
---|
| 3315 | identification. A "non-transparent proxy" is a proxy that |
---|
| 3316 | modifies the request or response in order to provide some added |
---|
| 3317 | service to the user agent, such as group annotation services, |
---|
| 3318 | media type transformation, protocol reduction, or anonymity |
---|
| 3319 | filtering. Except where either transparent or non-transparent |
---|
| 3320 | behavior is explicitly stated, the HTTP proxy requirements apply |
---|
| 3321 | to both types of proxies. |
---|
| 3322 | |
---|
| 3323 | gateway |
---|
| 3324 | |
---|
| 3325 | A server which acts as an intermediary for some other server. |
---|
| 3326 | Unlike a proxy, a gateway receives requests as if it were the |
---|
| 3327 | origin server for the requested resource; the requesting client |
---|
| 3328 | may not be aware that it is communicating with a gateway. |
---|
| 3329 | |
---|
| 3330 | tunnel |
---|
| 3331 | |
---|
| 3332 | An intermediary program which is acting as a blind relay between |
---|
| 3333 | two connections. Once active, a tunnel is not considered a party |
---|
| 3334 | to the HTTP communication, though the tunnel may have been |
---|
| 3335 | initiated by an HTTP request. The tunnel ceases to exist when |
---|
| 3336 | both ends of the relayed connections are closed. |
---|
| 3337 | |
---|
| 3338 | cache |
---|
| 3339 | |
---|
| 3340 | A program's local store of response messages and the subsystem |
---|
| 3341 | that controls its message storage, retrieval, and deletion. A |
---|
| 3342 | cache stores cacheable responses in order to reduce the response |
---|
| 3343 | time and network bandwidth consumption on future, equivalent |
---|
| 3344 | requests. Any client or server may include a cache, though a |
---|
| 3345 | cache cannot be used by a server that is acting as a tunnel. |
---|
| 3346 | |
---|
| 3347 | cacheable |
---|
| 3348 | |
---|
| 3349 | A response is cacheable if a cache is allowed to store a copy of |
---|
| 3350 | the response message for use in answering subsequent requests. |
---|
| 3351 | The rules for determining the cacheability of HTTP responses are |
---|
| 3352 | defined in Section 1 of [Part6]. Even if a resource is cacheable, |
---|
| 3353 | there may be additional constraints on whether a cache can use the |
---|
| 3354 | cached copy for a particular request. |
---|
| 3355 | |
---|
| 3356 | |
---|
| 3357 | |
---|
| 3358 | |
---|
| 3359 | Fielding, et al. Expires May 20, 2009 [Page 60] |
---|
| 3360 | |
---|
| 3361 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3362 | |
---|
| 3363 | |
---|
| 3364 | upstream/downstream |
---|
| 3365 | |
---|
| 3366 | Upstream and downstream describe the flow of a message: all |
---|
| 3367 | messages flow from upstream to downstream. |
---|
| 3368 | |
---|
| 3369 | inbound/outbound |
---|
| 3370 | |
---|
| 3371 | Inbound and outbound refer to the request and response paths for |
---|
| 3372 | messages: "inbound" means "traveling toward the origin server", |
---|
| 3373 | and "outbound" means "traveling toward the user agent" |
---|
| 3374 | |
---|
| 3375 | |
---|
| 3376 | Appendix E. Change Log (to be removed by RFC Editor before publication) |
---|
| 3377 | |
---|
| 3378 | E.1. Since RFC2616 |
---|
| 3379 | |
---|
| 3380 | Extracted relevant partitions from [RFC2616]. |
---|
| 3381 | |
---|
| 3382 | E.2. Since draft-ietf-httpbis-p1-messaging-00 |
---|
| 3383 | |
---|
| 3384 | Closed issues: |
---|
| 3385 | |
---|
| 3386 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |
---|
| 3387 | should be case sensitive" |
---|
| 3388 | (<http://purl.org/NET/http-errata#verscase>) |
---|
| 3389 | |
---|
| 3390 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |
---|
| 3391 | characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |
---|
| 3392 | |
---|
| 3393 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size |
---|
| 3394 | Definition" (<http://purl.org/NET/http-errata#chunk-size>) |
---|
| 3395 | |
---|
| 3396 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length" |
---|
| 3397 | (<http://purl.org/NET/http-errata#msg-len-chars>) |
---|
| 3398 | |
---|
| 3399 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type |
---|
| 3400 | Registrations" (<http://purl.org/NET/http-errata#media-reg>) |
---|
| 3401 | |
---|
| 3402 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes |
---|
| 3403 | query" (<http://purl.org/NET/http-errata#uriquery>) |
---|
| 3404 | |
---|
| 3405 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on |
---|
| 3406 | 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>) |
---|
| 3407 | |
---|
| 3408 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove |
---|
| 3409 | 'identity' token references" |
---|
| 3410 | (<http://purl.org/NET/http-errata#identity>) |
---|
| 3411 | |
---|
| 3412 | |
---|
| 3413 | |
---|
| 3414 | |
---|
| 3415 | Fielding, et al. Expires May 20, 2009 [Page 61] |
---|
| 3416 | |
---|
| 3417 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3418 | |
---|
| 3419 | |
---|
| 3420 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query |
---|
| 3421 | BNF" |
---|
| 3422 | |
---|
| 3423 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF" |
---|
| 3424 | |
---|
| 3425 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |
---|
| 3426 | Informative references" |
---|
| 3427 | |
---|
| 3428 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606 |
---|
| 3429 | Compliance" |
---|
| 3430 | |
---|
| 3431 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977 |
---|
| 3432 | reference" |
---|
| 3433 | |
---|
| 3434 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 |
---|
| 3435 | references" |
---|
| 3436 | |
---|
| 3437 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency |
---|
| 3438 | in date format explanation" |
---|
| 3439 | |
---|
| 3440 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference |
---|
| 3441 | typo" |
---|
| 3442 | |
---|
| 3443 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |
---|
| 3444 | references" |
---|
| 3445 | |
---|
| 3446 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 |
---|
| 3447 | Reference" |
---|
| 3448 | |
---|
| 3449 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |
---|
| 3450 | to-date references" |
---|
| 3451 | |
---|
| 3452 | Other changes: |
---|
| 3453 | |
---|
| 3454 | o Update media type registrations to use RFC4288 template. |
---|
| 3455 | |
---|
| 3456 | o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF |
---|
| 3457 | for chunk-data (work in progress on |
---|
| 3458 | <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |
---|
| 3459 | |
---|
| 3460 | E.3. Since draft-ietf-httpbis-p1-messaging-01 |
---|
| 3461 | |
---|
| 3462 | Closed issues: |
---|
| 3463 | |
---|
| 3464 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET |
---|
| 3465 | (and other) requests" |
---|
| 3466 | |
---|
| 3467 | |
---|
| 3468 | |
---|
| 3469 | |
---|
| 3470 | |
---|
| 3471 | Fielding, et al. Expires May 20, 2009 [Page 62] |
---|
| 3472 | |
---|
| 3473 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3474 | |
---|
| 3475 | |
---|
| 3476 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |
---|
| 3477 | RFC4288" |
---|
| 3478 | |
---|
| 3479 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code |
---|
| 3480 | and Reason Phrase" |
---|
| 3481 | |
---|
| 3482 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not |
---|
| 3483 | used" |
---|
| 3484 | |
---|
| 3485 | Ongoing work on ABNF conversion |
---|
| 3486 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
| 3487 | |
---|
| 3488 | o Get rid of duplicate BNF rule names ("host" -> "uri-host", |
---|
| 3489 | "trailer" -> "trailer-part"). |
---|
| 3490 | |
---|
| 3491 | o Avoid underscore character in rule names ("http_URL" -> "http- |
---|
| 3492 | URL", "abs_path" -> "path-absolute"). |
---|
| 3493 | |
---|
| 3494 | o Add rules for terms imported from URI spec ("absoluteURI", |
---|
| 3495 | "authority", "path-absolute", "port", "query", "relativeURI", |
---|
| 3496 | "host) -- these will have to be updated when switching over to |
---|
| 3497 | RFC3986. |
---|
| 3498 | |
---|
| 3499 | o Synchronize core rules with RFC5234 (this includes a change to |
---|
| 3500 | CHAR which now excludes NUL). |
---|
| 3501 | |
---|
| 3502 | o Get rid of prose rules that span multiple lines. |
---|
| 3503 | |
---|
| 3504 | o Get rid of unused rules LOALPHA and UPALPHA. |
---|
| 3505 | |
---|
| 3506 | o Move "Product Tokens" section (back) into Part 1, as "token" is |
---|
| 3507 | used in the definition of the Upgrade header. |
---|
| 3508 | |
---|
| 3509 | o Add explicit references to BNF syntax and rules imported from |
---|
| 3510 | other parts of the specification. |
---|
| 3511 | |
---|
| 3512 | o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |
---|
| 3513 | "TEXT". |
---|
| 3514 | |
---|
| 3515 | E.4. Since draft-ietf-httpbis-p1-messaging-02 |
---|
| 3516 | |
---|
| 3517 | Closed issues: |
---|
| 3518 | |
---|
| 3519 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |
---|
| 3520 | rfc1123-date" |
---|
| 3521 | |
---|
| 3522 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |
---|
| 3523 | pair" |
---|
| 3524 | |
---|
| 3525 | |
---|
| 3526 | |
---|
| 3527 | Fielding, et al. Expires May 20, 2009 [Page 63] |
---|
| 3528 | |
---|
| 3529 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3530 | |
---|
| 3531 | |
---|
| 3532 | Ongoing work on IANA Message Header Registration |
---|
| 3533 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
---|
| 3534 | |
---|
| 3535 | o Reference RFC 3984, and update header registrations for headers |
---|
| 3536 | defined in this document. |
---|
| 3537 | |
---|
| 3538 | Ongoing work on ABNF conversion |
---|
| 3539 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
| 3540 | |
---|
| 3541 | o Replace string literals when the string really is case-sensitive |
---|
| 3542 | (HTTP-Version). |
---|
| 3543 | |
---|
| 3544 | E.5. Since draft-ietf-httpbis-p1-messaging-03 |
---|
| 3545 | |
---|
| 3546 | Closed issues: |
---|
| 3547 | |
---|
| 3548 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |
---|
| 3549 | closing" |
---|
| 3550 | |
---|
| 3551 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |
---|
| 3552 | registrations and registry information to IANA Considerations" |
---|
| 3553 | |
---|
| 3554 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL |
---|
| 3555 | for PAD1995 reference" |
---|
| 3556 | |
---|
| 3557 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA |
---|
| 3558 | Considerations: update HTTP URI scheme registration" |
---|
| 3559 | |
---|
| 3560 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS |
---|
| 3561 | URI scheme definition" |
---|
| 3562 | |
---|
| 3563 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type |
---|
| 3564 | headers vs Set-Cookie" |
---|
| 3565 | |
---|
| 3566 | Ongoing work on ABNF conversion |
---|
| 3567 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
| 3568 | |
---|
| 3569 | o Replace string literals when the string really is case-sensitive |
---|
| 3570 | (HTTP-Date). |
---|
| 3571 | |
---|
| 3572 | o Replace HEX by HEXDIG for future consistence with RFC 5234's core |
---|
| 3573 | rules. |
---|
| 3574 | |
---|
| 3575 | E.6. Since draft-ietf-httpbis-p1-messaging-04 |
---|
| 3576 | |
---|
| 3577 | Closed issues: |
---|
| 3578 | |
---|
| 3579 | |
---|
| 3580 | |
---|
| 3581 | |
---|
| 3582 | |
---|
| 3583 | Fielding, et al. Expires May 20, 2009 [Page 64] |
---|
| 3584 | |
---|
| 3585 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3586 | |
---|
| 3587 | |
---|
| 3588 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date |
---|
| 3589 | reference for URIs" |
---|
| 3590 | |
---|
| 3591 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |
---|
| 3592 | updated by RFC 5322" |
---|
| 3593 | |
---|
| 3594 | Ongoing work on ABNF conversion |
---|
| 3595 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
| 3596 | |
---|
| 3597 | o Use "/" instead of "|" for alternatives. |
---|
| 3598 | |
---|
| 3599 | o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |
---|
| 3600 | |
---|
| 3601 | o Only reference RFC 5234's core rules. |
---|
| 3602 | |
---|
| 3603 | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
| 3604 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
| 3605 | |
---|
| 3606 | o Rewrite ABNFs to spell out whitespace rules, factor out header |
---|
| 3607 | value format definitions. |
---|
| 3608 | |
---|
| 3609 | |
---|
| 3610 | Index |
---|
| 3611 | |
---|
| 3612 | A |
---|
| 3613 | application/http Media Type 45 |
---|
| 3614 | |
---|
| 3615 | C |
---|
| 3616 | cache 60 |
---|
| 3617 | cacheable 60 |
---|
| 3618 | client 59 |
---|
| 3619 | connection 58 |
---|
| 3620 | Connection header 35 |
---|
| 3621 | content negotiation 59 |
---|
| 3622 | Content-Length header 36 |
---|
| 3623 | |
---|
| 3624 | D |
---|
| 3625 | Date header 36 |
---|
| 3626 | downstream 61 |
---|
| 3627 | |
---|
| 3628 | E |
---|
| 3629 | entity 58 |
---|
| 3630 | |
---|
| 3631 | G |
---|
| 3632 | gateway 60 |
---|
| 3633 | Grammar |
---|
| 3634 | absolute-URI 12 |
---|
| 3635 | asctime-date 14 |
---|
| 3636 | |
---|
| 3637 | |
---|
| 3638 | |
---|
| 3639 | Fielding, et al. Expires May 20, 2009 [Page 65] |
---|
| 3640 | |
---|
| 3641 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3642 | |
---|
| 3643 | |
---|
| 3644 | attribute 16 |
---|
| 3645 | authority 12 |
---|
| 3646 | BWS 9 |
---|
| 3647 | chunk 17 |
---|
| 3648 | chunk-data 17 |
---|
| 3649 | chunk-ext 17 |
---|
| 3650 | chunk-ext-name 17 |
---|
| 3651 | chunk-ext-val 17 |
---|
| 3652 | chunk-size 17 |
---|
| 3653 | Chunked-Body 17 |
---|
| 3654 | comment 10 |
---|
| 3655 | Connection 35 |
---|
| 3656 | connection-token 35 |
---|
| 3657 | Connection-v 35 |
---|
| 3658 | Content-Length 36 |
---|
| 3659 | Content-Length-v 36 |
---|
| 3660 | ctext 10 |
---|
| 3661 | Date 36 |
---|
| 3662 | Date-v 36 |
---|
| 3663 | date1 14 |
---|
| 3664 | date2 14 |
---|
| 3665 | date3 14 |
---|
| 3666 | extension-code 27 |
---|
| 3667 | extension-method 24 |
---|
| 3668 | field-content 20 |
---|
| 3669 | field-name 20 |
---|
| 3670 | field-value 20 |
---|
| 3671 | general-header 23 |
---|
| 3672 | generic-message 19 |
---|
| 3673 | Host 38 |
---|
| 3674 | Host-v 38 |
---|
| 3675 | HTTP-date 14 |
---|
| 3676 | HTTP-message 19 |
---|
| 3677 | HTTP-Prot-Name 11 |
---|
| 3678 | http-URI 13 |
---|
| 3679 | HTTP-Version 11 |
---|
| 3680 | last-chunk 17 |
---|
| 3681 | message-body 21 |
---|
| 3682 | message-header 20 |
---|
| 3683 | Method 24 |
---|
| 3684 | month 14 |
---|
| 3685 | obsolete-date 14 |
---|
| 3686 | OWS 9 |
---|
| 3687 | parameter 16 |
---|
| 3688 | path-absolute 12 |
---|
| 3689 | port 12 |
---|
| 3690 | product 18 |
---|
| 3691 | product-version 18 |
---|
| 3692 | |
---|
| 3693 | |
---|
| 3694 | |
---|
| 3695 | Fielding, et al. Expires May 20, 2009 [Page 66] |
---|
| 3696 | |
---|
| 3697 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3698 | |
---|
| 3699 | |
---|
| 3700 | protocol-name 42 |
---|
| 3701 | protocol-version 42 |
---|
| 3702 | pseudonym 42 |
---|
| 3703 | qdtext 10 |
---|
| 3704 | query 12 |
---|
| 3705 | quoted-pair 10 |
---|
| 3706 | quoted-string 10 |
---|
| 3707 | quoted-text 10 |
---|
| 3708 | Reason-Phrase 27 |
---|
| 3709 | received-by 42 |
---|
| 3710 | received-protocol 42 |
---|
| 3711 | relative-part 12 |
---|
| 3712 | relativeURI 12 |
---|
| 3713 | Request 24 |
---|
| 3714 | Request-Line 24 |
---|
| 3715 | Request-URI 24 |
---|
| 3716 | Response 26 |
---|
| 3717 | rfc850-date 14 |
---|
| 3718 | rfc1123-date 14 |
---|
| 3719 | RWS 9 |
---|
| 3720 | start-line 19 |
---|
| 3721 | Status-Code 27 |
---|
| 3722 | Status-Line 27 |
---|
| 3723 | t-codings 38 |
---|
| 3724 | tchar 10 |
---|
| 3725 | TE 38 |
---|
| 3726 | TE-v 38 |
---|
| 3727 | TEXT 9 |
---|
| 3728 | time 14 |
---|
| 3729 | token 10 |
---|
| 3730 | Trailer 40 |
---|
| 3731 | trailer-part 17 |
---|
| 3732 | Trailer-v 40 |
---|
| 3733 | transfer-coding 16 |
---|
| 3734 | Transfer-Encoding 40 |
---|
| 3735 | Transfer-Encoding-v 40 |
---|
| 3736 | transfer-extension 16 |
---|
| 3737 | Upgrade 41 |
---|
| 3738 | Upgrade-v 41 |
---|
| 3739 | uri-host 12 |
---|
| 3740 | URI-reference 12 |
---|
| 3741 | value 16 |
---|
| 3742 | Via 42 |
---|
| 3743 | Via-v 42 |
---|
| 3744 | weekday 14 |
---|
| 3745 | wkday 14 |
---|
| 3746 | |
---|
| 3747 | H |
---|
| 3748 | |
---|
| 3749 | |
---|
| 3750 | |
---|
| 3751 | Fielding, et al. Expires May 20, 2009 [Page 67] |
---|
| 3752 | |
---|
| 3753 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3754 | |
---|
| 3755 | |
---|
| 3756 | Headers |
---|
| 3757 | Connection 35 |
---|
| 3758 | Content-Length 36 |
---|
| 3759 | Date 36 |
---|
| 3760 | Host 38 |
---|
| 3761 | TE 38 |
---|
| 3762 | Trailer 39 |
---|
| 3763 | Transfer-Encoding 40 |
---|
| 3764 | Upgrade 41 |
---|
| 3765 | Via 42 |
---|
| 3766 | Host header 38 |
---|
| 3767 | http URI scheme 13 |
---|
| 3768 | https URI scheme 13 |
---|
| 3769 | |
---|
| 3770 | I |
---|
| 3771 | inbound 61 |
---|
| 3772 | |
---|
| 3773 | M |
---|
| 3774 | Media Type |
---|
| 3775 | application/http 45 |
---|
| 3776 | message/http 44 |
---|
| 3777 | message 58 |
---|
| 3778 | message/http Media Type 44 |
---|
| 3779 | |
---|
| 3780 | O |
---|
| 3781 | origin server 59 |
---|
| 3782 | outbound 61 |
---|
| 3783 | |
---|
| 3784 | P |
---|
| 3785 | proxy 59 |
---|
| 3786 | |
---|
| 3787 | R |
---|
| 3788 | representation 58 |
---|
| 3789 | request 58 |
---|
| 3790 | resource 58 |
---|
| 3791 | response 58 |
---|
| 3792 | |
---|
| 3793 | S |
---|
| 3794 | server 59 |
---|
| 3795 | |
---|
| 3796 | T |
---|
| 3797 | TE header 38 |
---|
| 3798 | Trailer header 39 |
---|
| 3799 | Transfer-Encoding header 40 |
---|
| 3800 | tunnel 60 |
---|
| 3801 | |
---|
| 3802 | U |
---|
| 3803 | Upgrade header 41 |
---|
| 3804 | |
---|
| 3805 | |
---|
| 3806 | |
---|
| 3807 | Fielding, et al. Expires May 20, 2009 [Page 68] |
---|
| 3808 | |
---|
| 3809 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3810 | |
---|
| 3811 | |
---|
| 3812 | upstream 61 |
---|
| 3813 | URI scheme |
---|
| 3814 | http 13 |
---|
| 3815 | https 13 |
---|
| 3816 | user agent 59 |
---|
| 3817 | |
---|
| 3818 | V |
---|
| 3819 | variant 59 |
---|
| 3820 | Via header 42 |
---|
| 3821 | |
---|
| 3822 | |
---|
| 3823 | Authors' Addresses |
---|
| 3824 | |
---|
| 3825 | Roy T. Fielding (editor) |
---|
| 3826 | Day Software |
---|
| 3827 | 23 Corporate Plaza DR, Suite 280 |
---|
| 3828 | Newport Beach, CA 92660 |
---|
| 3829 | USA |
---|
| 3830 | |
---|
| 3831 | Phone: +1-949-706-5300 |
---|
| 3832 | Fax: +1-949-706-5305 |
---|
| 3833 | Email: fielding@gbiv.com |
---|
| 3834 | URI: http://roy.gbiv.com/ |
---|
| 3835 | |
---|
| 3836 | |
---|
| 3837 | Jim Gettys |
---|
| 3838 | One Laptop per Child |
---|
| 3839 | 21 Oak Knoll Road |
---|
| 3840 | Carlisle, MA 01741 |
---|
| 3841 | USA |
---|
| 3842 | |
---|
| 3843 | Email: jg@laptop.org |
---|
| 3844 | URI: http://www.laptop.org/ |
---|
| 3845 | |
---|
| 3846 | |
---|
| 3847 | Jeffrey C. Mogul |
---|
| 3848 | Hewlett-Packard Company |
---|
| 3849 | HP Labs, Large Scale Systems Group |
---|
| 3850 | 1501 Page Mill Road, MS 1177 |
---|
| 3851 | Palo Alto, CA 94304 |
---|
| 3852 | USA |
---|
| 3853 | |
---|
| 3854 | Email: JeffMogul@acm.org |
---|
| 3855 | |
---|
| 3856 | |
---|
| 3857 | |
---|
| 3858 | |
---|
| 3859 | |
---|
| 3860 | |
---|
| 3861 | |
---|
| 3862 | |
---|
| 3863 | Fielding, et al. Expires May 20, 2009 [Page 69] |
---|
| 3864 | |
---|
| 3865 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3866 | |
---|
| 3867 | |
---|
| 3868 | Henrik Frystyk Nielsen |
---|
| 3869 | Microsoft Corporation |
---|
| 3870 | 1 Microsoft Way |
---|
| 3871 | Redmond, WA 98052 |
---|
| 3872 | USA |
---|
| 3873 | |
---|
| 3874 | Email: henrikn@microsoft.com |
---|
| 3875 | |
---|
| 3876 | |
---|
| 3877 | Larry Masinter |
---|
| 3878 | Adobe Systems, Incorporated |
---|
| 3879 | 345 Park Ave |
---|
| 3880 | San Jose, CA 95110 |
---|
| 3881 | USA |
---|
| 3882 | |
---|
| 3883 | Email: LMM@acm.org |
---|
| 3884 | URI: http://larry.masinter.net/ |
---|
| 3885 | |
---|
| 3886 | |
---|
| 3887 | Paul J. Leach |
---|
| 3888 | Microsoft Corporation |
---|
| 3889 | 1 Microsoft Way |
---|
| 3890 | Redmond, WA 98052 |
---|
| 3891 | |
---|
| 3892 | Email: paulle@microsoft.com |
---|
| 3893 | |
---|
| 3894 | |
---|
| 3895 | Tim Berners-Lee |
---|
| 3896 | World Wide Web Consortium |
---|
| 3897 | MIT Computer Science and Artificial Intelligence Laboratory |
---|
| 3898 | The Stata Center, Building 32 |
---|
| 3899 | 32 Vassar Street |
---|
| 3900 | Cambridge, MA 02139 |
---|
| 3901 | USA |
---|
| 3902 | |
---|
| 3903 | Email: timbl@w3.org |
---|
| 3904 | URI: http://www.w3.org/People/Berners-Lee/ |
---|
| 3905 | |
---|
| 3906 | |
---|
| 3907 | |
---|
| 3908 | |
---|
| 3909 | |
---|
| 3910 | |
---|
| 3911 | |
---|
| 3912 | |
---|
| 3913 | |
---|
| 3914 | |
---|
| 3915 | |
---|
| 3916 | |
---|
| 3917 | |
---|
| 3918 | |
---|
| 3919 | Fielding, et al. Expires May 20, 2009 [Page 70] |
---|
| 3920 | |
---|
| 3921 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3922 | |
---|
| 3923 | |
---|
| 3924 | Yves Lafon (editor) |
---|
| 3925 | World Wide Web Consortium |
---|
| 3926 | W3C / ERCIM |
---|
| 3927 | 2004, rte des Lucioles |
---|
| 3928 | Sophia-Antipolis, AM 06902 |
---|
| 3929 | France |
---|
| 3930 | |
---|
| 3931 | Email: ylafon@w3.org |
---|
| 3932 | URI: http://www.raubacapeu.net/people/yves/ |
---|
| 3933 | |
---|
| 3934 | |
---|
| 3935 | Julian F. Reschke (editor) |
---|
| 3936 | greenbytes GmbH |
---|
| 3937 | Hafenweg 16 |
---|
| 3938 | Muenster, NW 48155 |
---|
| 3939 | Germany |
---|
| 3940 | |
---|
| 3941 | Phone: +49 251 2807760 |
---|
| 3942 | Fax: +49 251 2807761 |
---|
| 3943 | Email: julian.reschke@greenbytes.de |
---|
| 3944 | URI: http://greenbytes.de/tech/webdav/ |
---|
| 3945 | |
---|
| 3946 | |
---|
| 3947 | |
---|
| 3948 | |
---|
| 3949 | |
---|
| 3950 | |
---|
| 3951 | |
---|
| 3952 | |
---|
| 3953 | |
---|
| 3954 | |
---|
| 3955 | |
---|
| 3956 | |
---|
| 3957 | |
---|
| 3958 | |
---|
| 3959 | |
---|
| 3960 | |
---|
| 3961 | |
---|
| 3962 | |
---|
| 3963 | |
---|
| 3964 | |
---|
| 3965 | |
---|
| 3966 | |
---|
| 3967 | |
---|
| 3968 | |
---|
| 3969 | |
---|
| 3970 | |
---|
| 3971 | |
---|
| 3972 | |
---|
| 3973 | |
---|
| 3974 | |
---|
| 3975 | Fielding, et al. Expires May 20, 2009 [Page 71] |
---|
| 3976 | |
---|
| 3977 | Internet-Draft HTTP/1.1, Part 1 November 2008 |
---|
| 3978 | |
---|
| 3979 | |
---|
| 3980 | Full Copyright Statement |
---|
| 3981 | |
---|
| 3982 | Copyright (C) The IETF Trust (2008). |
---|
| 3983 | |
---|
| 3984 | This document is subject to the rights, licenses and restrictions |
---|
| 3985 | contained in BCP 78, and except as set forth therein, the authors |
---|
| 3986 | retain all their rights. |
---|
| 3987 | |
---|
| 3988 | This document and the information contained herein are provided on an |
---|
| 3989 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
---|
| 3990 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
---|
| 3991 | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
---|
| 3992 | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
---|
| 3993 | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |
---|
| 3994 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
---|
| 3995 | |
---|
| 3996 | |
---|
| 3997 | Intellectual Property |
---|
| 3998 | |
---|
| 3999 | The IETF takes no position regarding the validity or scope of any |
---|
| 4000 | Intellectual Property Rights or other rights that might be claimed to |
---|
| 4001 | pertain to the implementation or use of the technology described in |
---|
| 4002 | this document or the extent to which any license under such rights |
---|
| 4003 | might or might not be available; nor does it represent that it has |
---|
| 4004 | made any independent effort to identify any such rights. Information |
---|
| 4005 | on the procedures with respect to rights in RFC documents can be |
---|
| 4006 | found in BCP 78 and BCP 79. |
---|
| 4007 | |
---|
| 4008 | Copies of IPR disclosures made to the IETF Secretariat and any |
---|
| 4009 | assurances of licenses to be made available, or the result of an |
---|
| 4010 | attempt made to obtain a general license or permission for the use of |
---|
| 4011 | such proprietary rights by implementers or users of this |
---|
| 4012 | specification can be obtained from the IETF on-line IPR repository at |
---|
| 4013 | http://www.ietf.org/ipr. |
---|
| 4014 | |
---|
| 4015 | The IETF invites any interested party to bring to its attention any |
---|
| 4016 | copyrights, patents or patent applications, or other proprietary |
---|
| 4017 | rights that may cover technology that may be required to implement |
---|
| 4018 | this standard. Please address the information to the IETF at |
---|
| 4019 | ietf-ipr@ietf.org. |
---|
| 4020 | |
---|
| 4021 | |
---|
| 4022 | |
---|
| 4023 | |
---|
| 4024 | |
---|
| 4025 | |
---|
| 4026 | |
---|
| 4027 | |
---|
| 4028 | |
---|
| 4029 | |
---|
| 4030 | |
---|
| 4031 | Fielding, et al. Expires May 20, 2009 [Page 72] |
---|
| 4032 | |
---|