| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group R. Fielding |
| 8 | Request for Comments: 2068 UC Irvine |
| 9 | Category: Standards Track J. Gettys |
| 10 | J. Mogul |
| 11 | DEC |
| 12 | H. Frystyk |
| 13 | T. Berners-Lee |
| 14 | MIT/LCS |
| 15 | January 1997 |
| 16 | |
| 17 | |
| 18 | Hypertext Transfer Protocol -- HTTP/1.1 |
| 19 | |
| 20 | Status of this Memo |
| 21 | |
| 22 | This document specifies an Internet standards track protocol for the |
| 23 | Internet community, and requests discussion and suggestions for |
| 24 | improvements. Please refer to the current edition of the "Internet |
| 25 | Official Protocol Standards" (STD 1) for the standardization state |
| 26 | and status of this protocol. Distribution of this memo is unlimited. |
| 27 | |
| 28 | Abstract |
| 29 | |
| 30 | The Hypertext Transfer Protocol (HTTP) is an application-level |
| 31 | protocol for distributed, collaborative, hypermedia information |
| 32 | systems. It is a generic, stateless, object-oriented protocol which |
| 33 | can be used for many tasks, such as name servers and distributed |
| 34 | object management systems, through extension of its request methods. |
| 35 | A feature of HTTP is the typing and negotiation of data |
| 36 | representation, allowing systems to be built independently of the |
| 37 | data being transferred. |
| 38 | |
| 39 | HTTP has been in use by the World-Wide Web global information |
| 40 | initiative since 1990. This specification defines the protocol |
| 41 | referred to as "HTTP/1.1". |
| 42 | |
| 43 | Table of Contents |
| 44 | |
| 45 | 1 Introduction.............................................7 |
| 46 | 1.1 Purpose ..............................................7 |
| 47 | 1.2 Requirements .........................................7 |
| 48 | 1.3 Terminology ..........................................8 |
| 49 | 1.4 Overall Operation ...................................11 |
| 50 | 2 Notational Conventions and Generic Grammar..............13 |
| 51 | 2.1 Augmented BNF .......................................13 |
| 52 | 2.2 Basic Rules .........................................15 |
| 53 | 3 Protocol Parameters.....................................17 |
| 54 | 3.1 HTTP Version ........................................17 |
| 55 | |
| 56 | |
| 57 | |
| 58 | Fielding, et. al. Standards Track [Page 1] |
| 59 | \f |
| 60 | RFC 2068 HTTP/1.1 January 1997 |
| 61 | |
| 62 | |
| 63 | 3.2 Uniform Resource Identifiers ........................18 |
| 64 | 3.2.1 General Syntax ...................................18 |
| 65 | 3.2.2 http URL .........................................19 |
| 66 | 3.2.3 URI Comparison ...................................20 |
| 67 | 3.3 Date/Time Formats ...................................21 |
| 68 | 3.3.1 Full Date ........................................21 |
| 69 | 3.3.2 Delta Seconds ....................................22 |
| 70 | 3.4 Character Sets ......................................22 |
| 71 | 3.5 Content Codings .....................................23 |
| 72 | 3.6 Transfer Codings ....................................24 |
| 73 | 3.7 Media Types .........................................25 |
| 74 | 3.7.1 Canonicalization and Text Defaults ...............26 |
| 75 | 3.7.2 Multipart Types ..................................27 |
| 76 | 3.8 Product Tokens ......................................28 |
| 77 | 3.9 Quality Values ......................................28 |
| 78 | 3.10 Language Tags ......................................28 |
| 79 | 3.11 Entity Tags ........................................29 |
| 80 | 3.12 Range Units ........................................30 |
| 81 | 4 HTTP Message............................................30 |
| 82 | 4.1 Message Types .......................................30 |
| 83 | 4.2 Message Headers .....................................31 |
| 84 | 4.3 Message Body ........................................32 |
| 85 | 4.4 Message Length ......................................32 |
| 86 | 4.5 General Header Fields ...............................34 |
| 87 | 5 Request.................................................34 |
| 88 | 5.1 Request-Line ........................................34 |
| 89 | 5.1.1 Method ...........................................35 |
| 90 | 5.1.2 Request-URI ......................................35 |
| 91 | 5.2 The Resource Identified by a Request ................37 |
| 92 | 5.3 Request Header Fields ...............................37 |
| 93 | 6 Response................................................38 |
| 94 | 6.1 Status-Line .........................................38 |
| 95 | 6.1.1 Status Code and Reason Phrase ....................39 |
| 96 | 6.2 Response Header Fields ..............................41 |
| 97 | 7 Entity..................................................41 |
| 98 | 7.1 Entity Header Fields ................................41 |
| 99 | 7.2 Entity Body .........................................42 |
| 100 | 7.2.1 Type .............................................42 |
| 101 | 7.2.2 Length ...........................................43 |
| 102 | 8 Connections.............................................43 |
| 103 | 8.1 Persistent Connections ..............................43 |
| 104 | 8.1.1 Purpose ..........................................43 |
| 105 | 8.1.2 Overall Operation ................................44 |
| 106 | 8.1.3 Proxy Servers ....................................45 |
| 107 | 8.1.4 Practical Considerations .........................45 |
| 108 | 8.2 Message Transmission Requirements ...................46 |
| 109 | 9 Method Definitions......................................48 |
| 110 | 9.1 Safe and Idempotent Methods .........................48 |
| 111 | |
| 112 | |
| 113 | |
| 114 | Fielding, et. al. Standards Track [Page 2] |
| 115 | \f |
| 116 | RFC 2068 HTTP/1.1 January 1997 |
| 117 | |
| 118 | |
| 119 | 9.1.1 Safe Methods .....................................48 |
| 120 | 9.1.2 Idempotent Methods ...............................49 |
| 121 | 9.2 OPTIONS .............................................49 |
| 122 | 9.3 GET .................................................50 |
| 123 | 9.4 HEAD ................................................50 |
| 124 | 9.5 POST ................................................51 |
| 125 | 9.6 PUT .................................................52 |
| 126 | 9.7 DELETE ..............................................53 |
| 127 | 9.8 TRACE ...............................................53 |
| 128 | 10 Status Code Definitions................................53 |
| 129 | 10.1 Informational 1xx ..................................54 |
| 130 | 10.1.1 100 Continue ....................................54 |
| 131 | 10.1.2 101 Switching Protocols .........................54 |
| 132 | 10.2 Successful 2xx .....................................54 |
| 133 | 10.2.1 200 OK ..........................................54 |
| 134 | 10.2.2 201 Created .....................................55 |
| 135 | 10.2.3 202 Accepted ....................................55 |
| 136 | 10.2.4 203 Non-Authoritative Information ...............55 |
| 137 | 10.2.5 204 No Content ..................................55 |
| 138 | 10.2.6 205 Reset Content ...............................56 |
| 139 | 10.2.7 206 Partial Content .............................56 |
| 140 | 10.3 Redirection 3xx ....................................56 |
| 141 | 10.3.1 300 Multiple Choices ............................57 |
| 142 | 10.3.2 301 Moved Permanently ...........................57 |
| 143 | 10.3.3 302 Moved Temporarily ...........................58 |
| 144 | 10.3.4 303 See Other ...................................58 |
| 145 | 10.3.5 304 Not Modified ................................58 |
| 146 | 10.3.6 305 Use Proxy ...................................59 |
| 147 | 10.4 Client Error 4xx ...................................59 |
| 148 | 10.4.1 400 Bad Request .................................60 |
| 149 | 10.4.2 401 Unauthorized ................................60 |
| 150 | 10.4.3 402 Payment Required ............................60 |
| 151 | 10.4.4 403 Forbidden ...................................60 |
| 152 | 10.4.5 404 Not Found ...................................60 |
| 153 | 10.4.6 405 Method Not Allowed ..........................61 |
| 154 | 10.4.7 406 Not Acceptable ..............................61 |
| 155 | 10.4.8 407 Proxy Authentication Required ...............61 |
| 156 | 10.4.9 408 Request Timeout .............................62 |
| 157 | 10.4.10 409 Conflict ...................................62 |
| 158 | 10.4.11 410 Gone .......................................62 |
| 159 | 10.4.12 411 Length Required ............................63 |
| 160 | 10.4.13 412 Precondition Failed ........................63 |
| 161 | 10.4.14 413 Request Entity Too Large ...................63 |
| 162 | 10.4.15 414 Request-URI Too Long .......................63 |
| 163 | 10.4.16 415 Unsupported Media Type .....................63 |
| 164 | 10.5 Server Error 5xx ...................................64 |
| 165 | 10.5.1 500 Internal Server Error .......................64 |
| 166 | 10.5.2 501 Not Implemented .............................64 |
| 167 | |
| 168 | |
| 169 | |
| 170 | Fielding, et. al. Standards Track [Page 3] |
| 171 | \f |
| 172 | RFC 2068 HTTP/1.1 January 1997 |
| 173 | |
| 174 | |
| 175 | 10.5.3 502 Bad Gateway .................................64 |
| 176 | 10.5.4 503 Service Unavailable .........................64 |
| 177 | 10.5.5 504 Gateway Timeout .............................64 |
| 178 | 10.5.6 505 HTTP Version Not Supported ..................65 |
| 179 | 11 Access Authentication..................................65 |
| 180 | 11.1 Basic Authentication Scheme ........................66 |
| 181 | 11.2 Digest Authentication Scheme .......................67 |
| 182 | 12 Content Negotiation....................................67 |
| 183 | 12.1 Server-driven Negotiation ..........................68 |
| 184 | 12.2 Agent-driven Negotiation ...........................69 |
| 185 | 12.3 Transparent Negotiation ............................70 |
| 186 | 13 Caching in HTTP........................................70 |
| 187 | 13.1.1 Cache Correctness ...............................72 |
| 188 | 13.1.2 Warnings ........................................73 |
| 189 | 13.1.3 Cache-control Mechanisms ........................74 |
| 190 | 13.1.4 Explicit User Agent Warnings ....................74 |
| 191 | 13.1.5 Exceptions to the Rules and Warnings ............75 |
| 192 | 13.1.6 Client-controlled Behavior ......................75 |
| 193 | 13.2 Expiration Model ...................................75 |
| 194 | 13.2.1 Server-Specified Expiration .....................75 |
| 195 | 13.2.2 Heuristic Expiration ............................76 |
| 196 | 13.2.3 Age Calculations ................................77 |
| 197 | 13.2.4 Expiration Calculations .........................79 |
| 198 | 13.2.5 Disambiguating Expiration Values ................80 |
| 199 | 13.2.6 Disambiguating Multiple Responses ...............80 |
| 200 | 13.3 Validation Model ...................................81 |
| 201 | 13.3.1 Last-modified Dates .............................82 |
| 202 | 13.3.2 Entity Tag Cache Validators .....................82 |
| 203 | 13.3.3 Weak and Strong Validators ......................82 |
| 204 | 13.3.4 Rules for When to Use Entity Tags and Last- |
| 205 | modified Dates..........................................85 |
| 206 | 13.3.5 Non-validating Conditionals .....................86 |
| 207 | 13.4 Response Cachability ...............................86 |
| 208 | 13.5 Constructing Responses From Caches .................87 |
| 209 | 13.5.1 End-to-end and Hop-by-hop Headers ...............88 |
| 210 | 13.5.2 Non-modifiable Headers ..........................88 |
| 211 | 13.5.3 Combining Headers ...............................89 |
| 212 | 13.5.4 Combining Byte Ranges ...........................90 |
| 213 | 13.6 Caching Negotiated Responses .......................90 |
| 214 | 13.7 Shared and Non-Shared Caches .......................91 |
| 215 | 13.8 Errors or Incomplete Response Cache Behavior .......91 |
| 216 | 13.9 Side Effects of GET and HEAD .......................92 |
| 217 | 13.10 Invalidation After Updates or Deletions ...........92 |
| 218 | 13.11 Write-Through Mandatory ...........................93 |
| 219 | 13.12 Cache Replacement .................................93 |
| 220 | 13.13 History Lists .....................................93 |
| 221 | 14 Header Field Definitions...............................94 |
| 222 | 14.1 Accept .............................................95 |
| 223 | |
| 224 | |
| 225 | |
| 226 | Fielding, et. al. Standards Track [Page 4] |
| 227 | \f |
| 228 | RFC 2068 HTTP/1.1 January 1997 |
| 229 | |
| 230 | |
| 231 | 14.2 Accept-Charset .....................................97 |
| 232 | 14.3 Accept-Encoding ....................................97 |
| 233 | 14.4 Accept-Language ....................................98 |
| 234 | 14.5 Accept-Ranges ......................................99 |
| 235 | 14.6 Age ................................................99 |
| 236 | 14.7 Allow .............................................100 |
| 237 | 14.8 Authorization .....................................100 |
| 238 | 14.9 Cache-Control .....................................101 |
| 239 | 14.9.1 What is Cachable ...............................103 |
| 240 | 14.9.2 What May be Stored by Caches ...................103 |
| 241 | 14.9.3 Modifications of the Basic Expiration Mechanism 104 |
| 242 | 14.9.4 Cache Revalidation and Reload Controls .........105 |
| 243 | 14.9.5 No-Transform Directive .........................107 |
| 244 | 14.9.6 Cache Control Extensions .......................108 |
| 245 | 14.10 Connection .......................................109 |
| 246 | 14.11 Content-Base .....................................109 |
| 247 | 14.12 Content-Encoding .................................110 |
| 248 | 14.13 Content-Language .................................110 |
| 249 | 14.14 Content-Length ...................................111 |
| 250 | 14.15 Content-Location .................................112 |
| 251 | 14.16 Content-MD5 ......................................113 |
| 252 | 14.17 Content-Range ....................................114 |
| 253 | 14.18 Content-Type .....................................116 |
| 254 | 14.19 Date .............................................116 |
| 255 | 14.20 ETag .............................................117 |
| 256 | 14.21 Expires ..........................................117 |
| 257 | 14.22 From .............................................118 |
| 258 | 14.23 Host .............................................119 |
| 259 | 14.24 If-Modified-Since ................................119 |
| 260 | 14.25 If-Match .........................................121 |
| 261 | 14.26 If-None-Match ....................................122 |
| 262 | 14.27 If-Range .........................................123 |
| 263 | 14.28 If-Unmodified-Since ..............................124 |
| 264 | 14.29 Last-Modified ....................................124 |
| 265 | 14.30 Location .........................................125 |
| 266 | 14.31 Max-Forwards .....................................125 |
| 267 | 14.32 Pragma ...........................................126 |
| 268 | 14.33 Proxy-Authenticate ...............................127 |
| 269 | 14.34 Proxy-Authorization ..............................127 |
| 270 | 14.35 Public ...........................................127 |
| 271 | 14.36 Range ............................................128 |
| 272 | 14.36.1 Byte Ranges ...................................128 |
| 273 | 14.36.2 Range Retrieval Requests ......................130 |
| 274 | 14.37 Referer ..........................................131 |
| 275 | 14.38 Retry-After ......................................131 |
| 276 | 14.39 Server ...........................................132 |
| 277 | 14.40 Transfer-Encoding ................................132 |
| 278 | 14.41 Upgrade ..........................................132 |
| 279 | |
| 280 | |
| 281 | |
| 282 | Fielding, et. al. Standards Track [Page 5] |
| 283 | \f |
| 284 | RFC 2068 HTTP/1.1 January 1997 |
| 285 | |
| 286 | |
| 287 | 14.42 User-Agent .......................................134 |
| 288 | 14.43 Vary .............................................134 |
| 289 | 14.44 Via ..............................................135 |
| 290 | 14.45 Warning ..........................................137 |
| 291 | 14.46 WWW-Authenticate .................................139 |
| 292 | 15 Security Considerations...............................139 |
| 293 | 15.1 Authentication of Clients .........................139 |
| 294 | 15.2 Offering a Choice of Authentication Schemes .......140 |
| 295 | 15.3 Abuse of Server Log Information ...................141 |
| 296 | 15.4 Transfer of Sensitive Information .................141 |
| 297 | 15.5 Attacks Based On File and Path Names ..............142 |
| 298 | 15.6 Personal Information ..............................143 |
| 299 | 15.7 Privacy Issues Connected to Accept Headers ........143 |
| 300 | 15.8 DNS Spoofing ......................................144 |
| 301 | 15.9 Location Headers and Spoofing .....................144 |
| 302 | 16 Acknowledgments.......................................144 |
| 303 | 17 References............................................146 |
| 304 | 18 Authors' Addresses....................................149 |
| 305 | 19 Appendices............................................150 |
| 306 | 19.1 Internet Media Type message/http ..................150 |
| 307 | 19.2 Internet Media Type multipart/byteranges ..........150 |
| 308 | 19.3 Tolerant Applications .............................151 |
| 309 | 19.4 Differences Between HTTP Entities and |
| 310 | MIME Entities...........................................152 |
| 311 | 19.4.1 Conversion to Canonical Form ...................152 |
| 312 | 19.4.2 Conversion of Date Formats .....................153 |
| 313 | 19.4.3 Introduction of Content-Encoding ...............153 |
| 314 | 19.4.4 No Content-Transfer-Encoding ...................153 |
| 315 | 19.4.5 HTTP Header Fields in Multipart Body-Parts .....153 |
| 316 | 19.4.6 Introduction of Transfer-Encoding ..............154 |
| 317 | 19.4.7 MIME-Version ...................................154 |
| 318 | 19.5 Changes from HTTP/1.0 .............................154 |
| 319 | 19.5.1 Changes to Simplify Multi-homed Web Servers and |
| 320 | Conserve IP Addresses .................................155 |
| 321 | 19.6 Additional Features ...............................156 |
| 322 | 19.6.1 Additional Request Methods .....................156 |
| 323 | 19.6.2 Additional Header Field Definitions ............156 |
| 324 | 19.7 Compatibility with Previous Versions ..............160 |
| 325 | 19.7.1 Compatibility with HTTP/1.0 Persistent |
| 326 | Connections............................................161 |
| 327 | |
| 328 | |
| 329 | |
| 330 | |
| 331 | |
| 332 | |
| 333 | |
| 334 | |
| 335 | |
| 336 | |
| 337 | |
| 338 | Fielding, et. al. Standards Track [Page 6] |
| 339 | \f |
| 340 | RFC 2068 HTTP/1.1 January 1997 |
| 341 | |
| 342 | |
| 343 | 1 Introduction |
| 344 | |
| 345 | 1.1 Purpose |
| 346 | |
| 347 | The Hypertext Transfer Protocol (HTTP) is an application-level |
| 348 | protocol for distributed, collaborative, hypermedia information |
| 349 | systems. HTTP has been in use by the World-Wide Web global |
| 350 | information initiative since 1990. The first version of HTTP, |
| 351 | referred to as HTTP/0.9, was a simple protocol for raw data transfer |
| 352 | across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved |
| 353 | the protocol by allowing messages to be in the format of MIME-like |
| 354 | messages, containing metainformation about the data transferred and |
| 355 | modifiers on the request/response semantics. However, HTTP/1.0 does |
| 356 | not sufficiently take into consideration the effects of hierarchical |
| 357 | proxies, caching, the need for persistent connections, and virtual |
| 358 | hosts. In addition, the proliferation of incompletely-implemented |
| 359 | applications calling themselves "HTTP/1.0" has necessitated a |
| 360 | protocol version change in order for two communicating applications |
| 361 | to determine each other's true capabilities. |
| 362 | |
| 363 | This specification defines the protocol referred to as "HTTP/1.1". |
| 364 | This protocol includes more stringent requirements than HTTP/1.0 in |
| 365 | order to ensure reliable implementation of its features. |
| 366 | |
| 367 | Practical information systems require more functionality than simple |
| 368 | retrieval, including search, front-end update, and annotation. HTTP |
| 369 | allows an open-ended set of methods that indicate the purpose of a |
| 370 | request. It builds on the discipline of reference provided by the |
| 371 | Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or |
| 372 | name (URN) , for indicating the resource to which a method is to be |
| 373 | applied. Messages are passed in a format similar to that used by |
| 374 | Internet mail as defined by the Multipurpose Internet Mail Extensions |
| 375 | (MIME). |
| 376 | |
| 377 | HTTP is also used as a generic protocol for communication between |
| 378 | user agents and proxies/gateways to other Internet systems, including |
| 379 | those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], |
| 380 | and WAIS [10] protocols. In this way, HTTP allows basic hypermedia |
| 381 | access to resources available from diverse applications. |
| 382 | |
| 383 | 1.2 Requirements |
| 384 | |
| 385 | This specification uses the same words as RFC 1123 [8] for defining |
| 386 | the significance of each particular requirement. These words are: |
| 387 | |
| 388 | MUST |
| 389 | This word or the adjective "required" means that the item is an |
| 390 | absolute requirement of the specification. |
| 391 | |
| 392 | |
| 393 | |
| 394 | Fielding, et. al. Standards Track [Page 7] |
| 395 | \f |
| 396 | RFC 2068 HTTP/1.1 January 1997 |
| 397 | |
| 398 | |
| 399 | SHOULD |
| 400 | This word or the adjective "recommended" means that there may |
| 401 | exist valid reasons in particular circumstances to ignore this |
| 402 | item, but the full implications should be understood and the case |
| 403 | carefully weighed before choosing a different course. |
| 404 | |
| 405 | MAY |
| 406 | This word or the adjective "optional" means that this item is |
| 407 | truly optional. One vendor may choose to include the item because |
| 408 | a particular marketplace requires it or because it enhances the |
| 409 | product, for example; another vendor may omit the same item. |
| 410 | |
| 411 | An implementation is not compliant if it fails to satisfy one or more |
| 412 | of the MUST requirements for the protocols it implements. An |
| 413 | implementation that satisfies all the MUST and all the SHOULD |
| 414 | requirements for its protocols is said to be "unconditionally |
| 415 | compliant"; one that satisfies all the MUST requirements but not all |
| 416 | the SHOULD requirements for its protocols is said to be |
| 417 | "conditionally compliant." |
| 418 | |
| 419 | 1.3 Terminology |
| 420 | |
| 421 | This specification uses a number of terms to refer to the roles |
| 422 | played by participants in, and objects of, the HTTP communication. |
| 423 | |
| 424 | connection |
| 425 | A transport layer virtual circuit established between two programs |
| 426 | for the purpose of communication. |
| 427 | |
| 428 | message |
| 429 | The basic unit of HTTP communication, consisting of a structured |
| 430 | sequence of octets matching the syntax defined in section 4 and |
| 431 | transmitted via the connection. |
| 432 | |
| 433 | request |
| 434 | An HTTP request message, as defined in section 5. |
| 435 | |
| 436 | response |
| 437 | An HTTP response message, as defined in section 6. |
| 438 | |
| 439 | resource |
| 440 | A network data object or service that can be identified by a URI, |
| 441 | as defined in section 3.2. Resources may be available in multiple |
| 442 | representations (e.g. multiple languages, data formats, size, |
| 443 | resolutions) or vary in other ways. |
| 444 | |
| 445 | |
| 446 | |
| 447 | |
| 448 | |
| 449 | |
| 450 | Fielding, et. al. Standards Track [Page 8] |
| 451 | \f |
| 452 | RFC 2068 HTTP/1.1 January 1997 |
| 453 | |
| 454 | |
| 455 | entity |
| 456 | The information transferred as the payload of a request or |
| 457 | response. An entity consists of metainformation in the form of |
| 458 | entity-header fields and content in the form of an entity-body, as |
| 459 | described in section 7. |
| 460 | |
| 461 | representation |
| 462 | An entity included with a response that is subject to content |
| 463 | negotiation, as described in section 12. There may exist multiple |
| 464 | representations associated with a particular response status. |
| 465 | |
| 466 | content negotiation |
| 467 | The mechanism for selecting the appropriate representation when |
| 468 | servicing a request, as described in section 12. The |
| 469 | representation of entities in any response can be negotiated |
| 470 | (including error responses). |
| 471 | |
| 472 | variant |
| 473 | A resource may have one, or more than one, representation(s) |
| 474 | associated with it at any given instant. Each of these |
| 475 | representations is termed a `variant.' Use of the term `variant' |
| 476 | does not necessarily imply that the resource is subject to content |
| 477 | negotiation. |
| 478 | |
| 479 | client |
| 480 | A program that establishes connections for the purpose of sending |
| 481 | requests. |
| 482 | |
| 483 | user agent |
| 484 | The client which initiates a request. These are often browsers, |
| 485 | editors, spiders (web-traversing robots), or other end user tools. |
| 486 | |
| 487 | server |
| 488 | An application program that accepts connections in order to |
| 489 | service requests by sending back responses. Any given program may |
| 490 | be capable of being both a client and a server; our use of these |
| 491 | terms refers only to the role being performed by the program for a |
| 492 | particular connection, rather than to the program's capabilities |
| 493 | in general. Likewise, any server may act as an origin server, |
| 494 | proxy, gateway, or tunnel, switching behavior based on the nature |
| 495 | of each request. |
| 496 | |
| 497 | origin server |
| 498 | The server on which a given resource resides or is to be created. |
| 499 | |
| 500 | |
| 501 | |
| 502 | |
| 503 | |
| 504 | |
| 505 | |
| 506 | Fielding, et. al. Standards Track [Page 9] |
| 507 | \f |
| 508 | RFC 2068 HTTP/1.1 January 1997 |
| 509 | |
| 510 | |
| 511 | proxy |
| 512 | An intermediary program which acts as both a server and a client |
| 513 | for the purpose of making requests on behalf of other clients. |
| 514 | Requests are serviced internally or by passing them on, with |
| 515 | possible translation, to other servers. A proxy must implement |
| 516 | both the client and server requirements of this specification. |
| 517 | |
| 518 | gateway |
| 519 | A server which acts as an intermediary for some other server. |
| 520 | Unlike a proxy, a gateway receives requests as if it were the |
| 521 | origin server for the requested resource; the requesting client |
| 522 | may not be aware that it is communicating with a gateway. |
| 523 | |
| 524 | tunnel |
| 525 | An intermediary program which is acting as a blind relay between |
| 526 | two connections. Once active, a tunnel is not considered a party |
| 527 | to the HTTP communication, though the tunnel may have been |
| 528 | initiated by an HTTP request. The tunnel ceases to exist when both |
| 529 | ends of the relayed connections are closed. |
| 530 | |
| 531 | cache |
| 532 | A program's local store of response messages and the subsystem |
| 533 | that controls its message storage, retrieval, and deletion. A |
| 534 | cache stores cachable responses in order to reduce the response |
| 535 | time and network bandwidth consumption on future, equivalent |
| 536 | requests. Any client or server may include a cache, though a cache |
| 537 | cannot be used by a server that is acting as a tunnel. |
| 538 | |
| 539 | cachable |
| 540 | A response is cachable if a cache is allowed to store a copy of |
| 541 | the response message for use in answering subsequent requests. The |
| 542 | rules for determining the cachability of HTTP responses are |
| 543 | defined in section 13. Even if a resource is cachable, there may |
| 544 | be additional constraints on whether a cache can use the cached |
| 545 | copy for a particular request. |
| 546 | |
| 547 | first-hand |
| 548 | A response is first-hand if it comes directly and without |
| 549 | unnecessary delay from the origin server, perhaps via one or more |
| 550 | proxies. A response is also first-hand if its validity has just |
| 551 | been checked directly with the origin server. |
| 552 | |
| 553 | explicit expiration time |
| 554 | The time at which the origin server intends that an entity should |
| 555 | no longer be returned by a cache without further validation. |
| 556 | |
| 557 | |
| 558 | |
| 559 | |
| 560 | |
| 561 | |
| 562 | Fielding, et. al. Standards Track [Page 10] |
| 563 | \f |
| 564 | RFC 2068 HTTP/1.1 January 1997 |
| 565 | |
| 566 | |
| 567 | heuristic expiration time |
| 568 | An expiration time assigned by a cache when no explicit expiration |
| 569 | time is available. |
| 570 | |
| 571 | age |
| 572 | The age of a response is the time since it was sent by, or |
| 573 | successfully validated with, the origin server. |
| 574 | |
| 575 | freshness lifetime |
| 576 | The length of time between the generation of a response and its |
| 577 | expiration time. |
| 578 | |
| 579 | fresh |
| 580 | A response is fresh if its age has not yet exceeded its freshness |
| 581 | lifetime. |
| 582 | |
| 583 | stale |
| 584 | A response is stale if its age has passed its freshness lifetime. |
| 585 | |
| 586 | semantically transparent |
| 587 | A cache behaves in a "semantically transparent" manner, with |
| 588 | respect to a particular response, when its use affects neither the |
| 589 | requesting client nor the origin server, except to improve |
| 590 | performance. When a cache is semantically transparent, the client |
| 591 | receives exactly the same response (except for hop-by-hop headers) |
| 592 | that it would have received had its request been handled directly |
| 593 | by the origin server. |
| 594 | |
| 595 | validator |
| 596 | A protocol element (e.g., an entity tag or a Last-Modified time) |
| 597 | that is used to find out whether a cache entry is an equivalent |
| 598 | copy of an entity. |
| 599 | |
| 600 | 1.4 Overall Operation |
| 601 | |
| 602 | The HTTP protocol is a request/response protocol. A client sends a |
| 603 | request to the server in the form of a request method, URI, and |
| 604 | protocol version, followed by a MIME-like message containing request |
| 605 | modifiers, client information, and possible body content over a |
| 606 | connection with a server. The server responds with a status line, |
| 607 | including the message's protocol version and a success or error code, |
| 608 | followed by a MIME-like message containing server information, entity |
| 609 | metainformation, and possible entity-body content. The relationship |
| 610 | between HTTP and MIME is described in appendix 19.4. |
| 611 | |
| 612 | |
| 613 | |
| 614 | |
| 615 | |
| 616 | |
| 617 | |
| 618 | Fielding, et. al. Standards Track [Page 11] |
| 619 | \f |
| 620 | RFC 2068 HTTP/1.1 January 1997 |
| 621 | |
| 622 | |
| 623 | Most HTTP communication is initiated by a user agent and consists of |
| 624 | a request to be applied to a resource on some origin server. In the |
| 625 | simplest case, this may be accomplished via a single connection (v) |
| 626 | between the user agent (UA) and the origin server (O). |
| 627 | |
| 628 | request chain ------------------------> |
| 629 | UA -------------------v------------------- O |
| 630 | <----------------------- response chain |
| 631 | |
| 632 | A more complicated situation occurs when one or more intermediaries |
| 633 | are present in the request/response chain. There are three common |
| 634 | forms of intermediary: proxy, gateway, and tunnel. A proxy is a |
| 635 | forwarding agent, receiving requests for a URI in its absolute form, |
| 636 | rewriting all or part of the message, and forwarding the reformatted |
| 637 | request toward the server identified by the URI. A gateway is a |
| 638 | receiving agent, acting as a layer above some other server(s) and, if |
| 639 | necessary, translating the requests to the underlying server's |
| 640 | protocol. A tunnel acts as a relay point between two connections |
| 641 | without changing the messages; tunnels are used when the |
| 642 | communication needs to pass through an intermediary (such as a |
| 643 | firewall) even when the intermediary cannot understand the contents |
| 644 | of the messages. |
| 645 | |
| 646 | request chain --------------------------------------> |
| 647 | UA -----v----- A -----v----- B -----v----- C -----v----- O |
| 648 | <------------------------------------- response chain |
| 649 | |
| 650 | The figure above shows three intermediaries (A, B, and C) between the |
| 651 | user agent and origin server. A request or response message that |
| 652 | travels the whole chain will pass through four separate connections. |
| 653 | This distinction is important because some HTTP communication options |
| 654 | may apply only to the connection with the nearest, non-tunnel |
| 655 | neighbor, only to the end-points of the chain, or to all connections |
| 656 | along the chain. Although the diagram is linear, each participant |
| 657 | may be engaged in multiple, simultaneous communications. For example, |
| 658 | B may be receiving requests from many clients other than A, and/or |
| 659 | forwarding requests to servers other than C, at the same time that it |
| 660 | is handling A's request. |
| 661 | |
| 662 | Any party to the communication which is not acting as a tunnel may |
| 663 | employ an internal cache for handling requests. The effect of a cache |
| 664 | is that the request/response chain is shortened if one of the |
| 665 | participants along the chain has a cached response applicable to that |
| 666 | request. The following illustrates the resulting chain if B has a |
| 667 | cached copy of an earlier response from O (via C) for a request which |
| 668 | has not been cached by UA or A. |
| 669 | |
| 670 | |
| 671 | |
| 672 | |
| 673 | |
| 674 | Fielding, et. al. Standards Track [Page 12] |
| 675 | \f |
| 676 | RFC 2068 HTTP/1.1 January 1997 |
| 677 | |
| 678 | |
| 679 | request chain ----------> |
| 680 | UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
| 681 | <--------- response chain |
| 682 | |
| 683 | Not all responses are usefully cachable, and some requests may |
| 684 | contain modifiers which place special requirements on cache behavior. |
| 685 | HTTP requirements for cache behavior and cachable responses are |
| 686 | defined in section 13. |
| 687 | |
| 688 | In fact, there are a wide variety of architectures and configurations |
| 689 | of caches and proxies currently being experimented with or deployed |
| 690 | across the World Wide Web; these systems include national hierarchies |
| 691 | of proxy caches to save transoceanic bandwidth, systems that |
| 692 | broadcast or multicast cache entries, organizations that distribute |
| 693 | subsets of cached data via CD-ROM, and so on. HTTP systems are used |
| 694 | in corporate intranets over high-bandwidth links, and for access via |
| 695 | PDAs with low-power radio links and intermittent connectivity. The |
| 696 | goal of HTTP/1.1 is to support the wide diversity of configurations |
| 697 | already deployed while introducing protocol constructs that meet the |
| 698 | needs of those who build web applications that require high |
| 699 | reliability and, failing that, at least reliable indications of |
| 700 | failure. |
| 701 | |
| 702 | HTTP communication usually takes place over TCP/IP connections. The |
| 703 | default port is TCP 80, but other ports can be used. This does not |
| 704 | preclude HTTP from being implemented on top of any other protocol on |
| 705 | the Internet, or on other networks. HTTP only presumes a reliable |
| 706 | transport; any protocol that provides such guarantees can be used; |
| 707 | the mapping of the HTTP/1.1 request and response structures onto the |
| 708 | transport data units of the protocol in question is outside the scope |
| 709 | of this specification. |
| 710 | |
| 711 | In HTTP/1.0, most implementations used a new connection for each |
| 712 | request/response exchange. In HTTP/1.1, a connection may be used for |
| 713 | one or more request/response exchanges, although connections may be |
| 714 | closed for a variety of reasons (see section 8.1). |
| 715 | |
| 716 | 2 Notational Conventions and Generic Grammar |
| 717 | |
| 718 | 2.1 Augmented BNF |
| 719 | |
| 720 | All of the mechanisms specified in this document are described in |
| 721 | both prose and an augmented Backus-Naur Form (BNF) similar to that |
| 722 | used by RFC 822 [9]. Implementers will need to be familiar with the |
| 723 | notation in order to understand this specification. The augmented BNF |
| 724 | includes the following constructs: |
| 725 | |
| 726 | |
| 727 | |
| 728 | |
| 729 | |
| 730 | Fielding, et. al. Standards Track [Page 13] |
| 731 | \f |
| 732 | RFC 2068 HTTP/1.1 January 1997 |
| 733 | |
| 734 | |
| 735 | name = definition |
| 736 | The name of a rule is simply the name itself (without any enclosing |
| 737 | "<" and ">") and is separated from its definition by the equal "=" |
| 738 | character. Whitespace is only significant in that indentation of |
| 739 | continuation lines is used to indicate a rule definition that spans |
| 740 | more than one line. Certain basic rules are in uppercase, such as |
| 741 | SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used |
| 742 | within definitions whenever their presence will facilitate |
| 743 | discerning the use of rule names. |
| 744 | |
| 745 | "literal" |
| 746 | Quotation marks surround literal text. Unless stated otherwise, the |
| 747 | text is case-insensitive. |
| 748 | |
| 749 | rule1 | rule2 |
| 750 | Elements separated by a bar ("|") are alternatives, e.g., "yes | |
| 751 | no" will accept yes or no. |
| 752 | |
| 753 | (rule1 rule2) |
| 754 | Elements enclosed in parentheses are treated as a single element. |
| 755 | Thus, "(elem (foo | bar) elem)" allows the token sequences "elem |
| 756 | foo elem" and "elem bar elem". |
| 757 | |
| 758 | *rule |
| 759 | The character "*" preceding an element indicates repetition. The |
| 760 | full form is "<n>*<m>element" indicating at least <n> and at most |
| 761 | <m> occurrences of element. Default values are 0 and infinity so |
| 762 | that "*(element)" allows any number, including zero; "1*element" |
| 763 | requires at least one; and "1*2element" allows one or two. |
| 764 | |
| 765 | [rule] |
| 766 | Square brackets enclose optional elements; "[foo bar]" is |
| 767 | equivalent to "*1(foo bar)". |
| 768 | |
| 769 | N rule |
| 770 | Specific repetition: "<n>(element)" is equivalent to |
| 771 | "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). |
| 772 | Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three |
| 773 | alphabetic characters. |
| 774 | |
| 775 | #rule |
| 776 | A construct "#" is defined, similar to "*", for defining lists of |
| 777 | elements. The full form is "<n>#<m>element " indicating at least |
| 778 | <n> and at most <m> elements, each separated by one or more commas |
| 779 | (",") and optional linear whitespace (LWS). This makes the usual |
| 780 | form of lists very easy; a rule such as "( *LWS element *( *LWS "," |
| 781 | *LWS element )) " can be shown as "1#element". Wherever this |
| 782 | construct is used, null elements are allowed, but do not contribute |
| 783 | |
| 784 | |
| 785 | |
| 786 | Fielding, et. al. Standards Track [Page 14] |
| 787 | \f |
| 788 | RFC 2068 HTTP/1.1 January 1997 |
| 789 | |
| 790 | |
| 791 | to the count of elements present. That is, "(element), , (element) |
| 792 | " is permitted, but counts as only two elements. Therefore, where |
| 793 | at least one element is required, at least one non-null element |
| 794 | must be present. Default values are 0 and infinity so that |
| 795 | "#element" allows any number, including zero; "1#element" requires |
| 796 | at least one; and "1#2element" allows one or two. |
| 797 | |
| 798 | ; comment |
| 799 | A semi-colon, set off some distance to the right of rule text, |
| 800 | starts a comment that continues to the end of line. This is a |
| 801 | simple way of including useful notes in parallel with the |
| 802 | specifications. |
| 803 | |
| 804 | implied *LWS |
| 805 | The grammar described by this specification is word-based. Except |
| 806 | where noted otherwise, linear whitespace (LWS) can be included |
| 807 | between any two adjacent words (token or quoted-string), and |
| 808 | between adjacent tokens and delimiters (tspecials), without |
| 809 | changing the interpretation of a field. At least one delimiter |
| 810 | (tspecials) must exist between any two tokens, since they would |
| 811 | otherwise be interpreted as a single token. |
| 812 | |
| 813 | 2.2 Basic Rules |
| 814 | |
| 815 | The following rules are used throughout this specification to |
| 816 | describe basic parsing constructs. The US-ASCII coded character set |
| 817 | is defined by ANSI X3.4-1986 [21]. |
| 818 | |
| 819 | OCTET = <any 8-bit sequence of data> |
| 820 | CHAR = <any US-ASCII character (octets 0 - 127)> |
| 821 | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |
| 822 | LOALPHA = <any US-ASCII lowercase letter "a".."z"> |
| 823 | ALPHA = UPALPHA | LOALPHA |
| 824 | DIGIT = <any US-ASCII digit "0".."9"> |
| 825 | CTL = <any US-ASCII control character |
| 826 | (octets 0 - 31) and DEL (127)> |
| 827 | CR = <US-ASCII CR, carriage return (13)> |
| 828 | LF = <US-ASCII LF, linefeed (10)> |
| 829 | SP = <US-ASCII SP, space (32)> |
| 830 | HT = <US-ASCII HT, horizontal-tab (9)> |
| 831 | <"> = <US-ASCII double-quote mark (34)> |
| 832 | |
| 833 | |
| 834 | |
| 835 | |
| 836 | |
| 837 | |
| 838 | |
| 839 | |
| 840 | |
| 841 | |
| 842 | Fielding, et. al. Standards Track [Page 15] |
| 843 | \f |
| 844 | RFC 2068 HTTP/1.1 January 1997 |
| 845 | |
| 846 | |
| 847 | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |
| 848 | protocol elements except the entity-body (see appendix 19.3 for |
| 849 | tolerant applications). The end-of-line marker within an entity-body |
| 850 | is defined by its associated media type, as described in section 3.7. |
| 851 | |
| 852 | CRLF = CR LF |
| 853 | |
| 854 | HTTP/1.1 headers can be folded onto multiple lines if the |
| 855 | continuation line begins with a space or horizontal tab. All linear |
| 856 | white space, including folding, has the same semantics as SP. |
| 857 | |
| 858 | LWS = [CRLF] 1*( SP | HT ) |
| 859 | |
| 860 | The TEXT rule is only used for descriptive field contents and values |
| 861 | that are not intended to be interpreted by the message parser. Words |
| 862 | of *TEXT may contain characters from character sets other than ISO |
| 863 | 8859-1 [22] only when encoded according to the rules of RFC 1522 |
| 864 | [14]. |
| 865 | |
| 866 | TEXT = <any OCTET except CTLs, |
| 867 | but including LWS> |
| 868 | |
| 869 | Hexadecimal numeric characters are used in several protocol elements. |
| 870 | |
| 871 | HEX = "A" | "B" | "C" | "D" | "E" | "F" |
| 872 | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT |
| 873 | |
| 874 | Many HTTP/1.1 header field values consist of words separated by LWS |
| 875 | or special characters. These special characters MUST be in a quoted |
| 876 | string to be used within a parameter value. |
| 877 | |
| 878 | token = 1*<any CHAR except CTLs or tspecials> |
| 879 | |
| 880 | tspecials = "(" | ")" | "<" | ">" | "@" |
| 881 | | "," | ";" | ":" | "\" | <"> |
| 882 | | "/" | "[" | "]" | "?" | "=" |
| 883 | | "{" | "}" | SP | HT |
| 884 | |
| 885 | Comments can be included in some HTTP header fields by surrounding |
| 886 | the comment text with parentheses. Comments are only allowed in |
| 887 | fields containing "comment" as part of their field value definition. |
| 888 | In all other fields, parentheses are considered part of the field |
| 889 | value. |
| 890 | |
| 891 | comment = "(" *( ctext | comment ) ")" |
| 892 | ctext = <any TEXT excluding "(" and ")"> |
| 893 | |
| 894 | |
| 895 | |
| 896 | |
| 897 | |
| 898 | Fielding, et. al. Standards Track [Page 16] |
| 899 | \f |
| 900 | RFC 2068 HTTP/1.1 January 1997 |
| 901 | |
| 902 | |
| 903 | A string of text is parsed as a single word if it is quoted using |
| 904 | double-quote marks. |
| 905 | |
| 906 | quoted-string = ( <"> *(qdtext) <"> ) |
| 907 | |
| 908 | qdtext = <any TEXT except <">> |
| 909 | |
| 910 | The backslash character ("\") may be used as a single-character quoting |
| 911 | mechanism only within quoted-string and comment constructs. |
| 912 | |
| 913 | quoted-pair = "\" CHAR |
| 914 | |
| 915 | 3 Protocol Parameters |
| 916 | |
| 917 | 3.1 HTTP Version |
| 918 | |
| 919 | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
| 920 | of the protocol. The protocol versioning policy is intended to allow |
| 921 | the sender to indicate the format of a message and its capacity for |
| 922 | understanding further HTTP communication, rather than the features |
| 923 | obtained via that communication. No change is made to the version |
| 924 | number for the addition of message components which do not affect |
| 925 | communication behavior or which only add to extensible field values. |
| 926 | The <minor> number is incremented when the changes made to the |
| 927 | protocol add features which do not change the general message parsing |
| 928 | algorithm, but which may add to the message semantics and imply |
| 929 | additional capabilities of the sender. The <major> number is |
| 930 | incremented when the format of a message within the protocol is |
| 931 | changed. |
| 932 | |
| 933 | The version of an HTTP message is indicated by an HTTP-Version field |
| 934 | in the first line of the message. |
| 935 | |
| 936 | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |
| 937 | |
| 938 | Note that the major and minor numbers MUST be treated as separate |
| 939 | integers and that each may be incremented higher than a single digit. |
| 940 | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
| 941 | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and |
| 942 | MUST NOT be sent. |
| 943 | |
| 944 | Applications sending Request or Response messages, as defined by this |
| 945 | specification, MUST include an HTTP-Version of "HTTP/1.1". Use of |
| 946 | this version number indicates that the sending application is at |
| 947 | least conditionally compliant with this specification. |
| 948 | |
| 949 | The HTTP version of an application is the highest HTTP version for |
| 950 | which the application is at least conditionally compliant. |
| 951 | |
| 952 | |
| 953 | |
| 954 | Fielding, et. al. Standards Track [Page 17] |
| 955 | \f |
| 956 | RFC 2068 HTTP/1.1 January 1997 |
| 957 | |
| 958 | |
| 959 | Proxy and gateway applications must be careful when forwarding |
| 960 | messages in protocol versions different from that of the application. |
| 961 | Since the protocol version indicates the protocol capability of the |
| 962 | sender, a proxy/gateway MUST never send a message with a version |
| 963 | indicator which is greater than its actual version; if a higher |
| 964 | version request is received, the proxy/gateway MUST either downgrade |
| 965 | the request version, respond with an error, or switch to tunnel |
| 966 | behavior. Requests with a version lower than that of the |
| 967 | proxy/gateway's version MAY be upgraded before being forwarded; the |
| 968 | proxy/gateway's response to that request MUST be in the same major |
| 969 | version as the request. |
| 970 | |
| 971 | Note: Converting between versions of HTTP may involve modification |
| 972 | of header fields required or forbidden by the versions involved. |
| 973 | |
| 974 | 3.2 Uniform Resource Identifiers |
| 975 | |
| 976 | URIs have been known by many names: WWW addresses, Universal Document |
| 977 | Identifiers, Universal Resource Identifiers , and finally the |
| 978 | combination of Uniform Resource Locators (URL) and Names (URN). As |
| 979 | far as HTTP is concerned, Uniform Resource Identifiers are simply |
| 980 | formatted strings which identify--via name, location, or any other |
| 981 | characteristic--a resource. |
| 982 | |
| 983 | 3.2.1 General Syntax |
| 984 | |
| 985 | URIs in HTTP can be represented in absolute form or relative to some |
| 986 | known base URI, depending upon the context of their use. The two |
| 987 | forms are differentiated by the fact that absolute URIs always begin |
| 988 | with a scheme name followed by a colon. |
| 989 | |
| 990 | URI = ( absoluteURI | relativeURI ) [ "#" fragment ] |
| 991 | |
| 992 | absoluteURI = scheme ":" *( uchar | reserved ) |
| 993 | |
| 994 | relativeURI = net_path | abs_path | rel_path |
| 995 | |
| 996 | net_path = "//" net_loc [ abs_path ] |
| 997 | abs_path = "/" rel_path |
| 998 | rel_path = [ path ] [ ";" params ] [ "?" query ] |
| 999 | |
| 1000 | path = fsegment *( "/" segment ) |
| 1001 | fsegment = 1*pchar |
| 1002 | segment = *pchar |
| 1003 | |
| 1004 | params = param *( ";" param ) |
| 1005 | param = *( pchar | "/" ) |
| 1006 | |
| 1007 | |
| 1008 | |
| 1009 | |
| 1010 | Fielding, et. al. Standards Track [Page 18] |
| 1011 | \f |
| 1012 | RFC 2068 HTTP/1.1 January 1997 |
| 1013 | |
| 1014 | |
| 1015 | scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) |
| 1016 | net_loc = *( pchar | ";" | "?" ) |
| 1017 | |
| 1018 | query = *( uchar | reserved ) |
| 1019 | fragment = *( uchar | reserved ) |
| 1020 | |
| 1021 | pchar = uchar | ":" | "@" | "&" | "=" | "+" |
| 1022 | uchar = unreserved | escape |
| 1023 | unreserved = ALPHA | DIGIT | safe | extra | national |
| 1024 | |
| 1025 | escape = "%" HEX HEX |
| 1026 | reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
| 1027 | extra = "!" | "*" | "'" | "(" | ")" | "," |
| 1028 | safe = "$" | "-" | "_" | "." |
| 1029 | unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" |
| 1030 | national = <any OCTET excluding ALPHA, DIGIT, |
| 1031 | reserved, extra, safe, and unsafe> |
| 1032 | |
| 1033 | For definitive information on URL syntax and semantics, see RFC 1738 |
| 1034 | [4] and RFC 1808 [11]. The BNF above includes national characters not |
| 1035 | allowed in valid URLs as specified by RFC 1738, since HTTP servers |
| 1036 | are not restricted in the set of unreserved characters allowed to |
| 1037 | represent the rel_path part of addresses, and HTTP proxies may |
| 1038 | receive requests for URIs not defined by RFC 1738. |
| 1039 | |
| 1040 | The HTTP protocol does not place any a priori limit on the length of |
| 1041 | a URI. Servers MUST be able to handle the URI of any resource they |
| 1042 | serve, and SHOULD be able to handle URIs of unbounded length if they |
| 1043 | provide GET-based forms that could generate such URIs. A server |
| 1044 | SHOULD return 414 (Request-URI Too Long) status if a URI is longer |
| 1045 | than the server can handle (see section 10.4.15). |
| 1046 | |
| 1047 | Note: Servers should be cautious about depending on URI lengths |
| 1048 | above 255 bytes, because some older client or proxy implementations |
| 1049 | may not properly support these lengths. |
| 1050 | |
| 1051 | 3.2.2 http URL |
| 1052 | |
| 1053 | The "http" scheme is used to locate network resources via the HTTP |
| 1054 | protocol. This section defines the scheme-specific syntax and |
| 1055 | semantics for http URLs. |
| 1056 | |
| 1057 | |
| 1058 | |
| 1059 | |
| 1060 | |
| 1061 | |
| 1062 | |
| 1063 | |
| 1064 | |
| 1065 | |
| 1066 | Fielding, et. al. Standards Track [Page 19] |
| 1067 | \f |
| 1068 | RFC 2068 HTTP/1.1 January 1997 |
| 1069 | |
| 1070 | |
| 1071 | http_URL = "http:" "//" host [ ":" port ] [ abs_path ] |
| 1072 | |
| 1073 | host = <A legal Internet host domain name |
| 1074 | or IP address (in dotted-decimal form), |
| 1075 | as defined by Section 2.1 of RFC 1123> |
| 1076 | |
| 1077 | port = *DIGIT |
| 1078 | |
| 1079 | If the port is empty or not given, port 80 is assumed. The semantics |
| 1080 | are that the identified resource is located at the server listening |
| 1081 | for TCP connections on that port of that host, and the Request-URI |
| 1082 | for the resource is abs_path. The use of IP addresses in URL's SHOULD |
| 1083 | be avoided whenever possible (see RFC 1900 [24]). If the abs_path is |
| 1084 | not present in the URL, it MUST be given as "/" when used as a |
| 1085 | Request-URI for a resource (section 5.1.2). |
| 1086 | |
| 1087 | 3.2.3 URI Comparison |
| 1088 | |
| 1089 | When comparing two URIs to decide if they match or not, a client |
| 1090 | SHOULD use a case-sensitive octet-by-octet comparison of the entire |
| 1091 | URIs, with these exceptions: |
| 1092 | |
| 1093 | o A port that is empty or not given is equivalent to the default |
| 1094 | port for that URI; |
| 1095 | |
| 1096 | o Comparisons of host names MUST be case-insensitive; |
| 1097 | |
| 1098 | o Comparisons of scheme names MUST be case-insensitive; |
| 1099 | |
| 1100 | o An empty abs_path is equivalent to an abs_path of "/". |
| 1101 | |
| 1102 | Characters other than those in the "reserved" and "unsafe" sets (see |
| 1103 | section 3.2) are equivalent to their ""%" HEX HEX" encodings. |
| 1104 | |
| 1105 | For example, the following three URIs are equivalent: |
| 1106 | |
| 1107 | http://abc.com:80/~smith/home.html |
| 1108 | http://ABC.com/%7Esmith/home.html |
| 1109 | http://ABC.com:/%7esmith/home.html |
| 1110 | |
| 1111 | |
| 1112 | |
| 1113 | |
| 1114 | |
| 1115 | |
| 1116 | |
| 1117 | |
| 1118 | |
| 1119 | |
| 1120 | |
| 1121 | |
| 1122 | Fielding, et. al. Standards Track [Page 20] |
| 1123 | \f |
| 1124 | RFC 2068 HTTP/1.1 January 1997 |
| 1125 | |
| 1126 | |
| 1127 | 3.3 Date/Time Formats |
| 1128 | |
| 1129 | 3.3.1 Full Date |
| 1130 | |
| 1131 | HTTP applications have historically allowed three different formats |
| 1132 | for the representation of date/time stamps: |
| 1133 | |
| 1134 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |
| 1135 | Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 |
| 1136 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
| 1137 | |
| 1138 | The first format is preferred as an Internet standard and represents |
| 1139 | a fixed-length subset of that defined by RFC 1123 (an update to RFC |
| 1140 | 822). The second format is in common use, but is based on the |
| 1141 | obsolete RFC 850 [12] date format and lacks a four-digit year. |
| 1142 | HTTP/1.1 clients and servers that parse the date value MUST accept |
| 1143 | all three formats (for compatibility with HTTP/1.0), though they MUST |
| 1144 | only generate the RFC 1123 format for representing HTTP-date values |
| 1145 | in header fields. |
| 1146 | |
| 1147 | Note: Recipients of date values are encouraged to be robust in |
| 1148 | accepting date values that may have been sent by non-HTTP |
| 1149 | applications, as is sometimes the case when retrieving or posting |
| 1150 | messages via proxies/gateways to SMTP or NNTP. |
| 1151 | |
| 1152 | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
| 1153 | (GMT), without exception. This is indicated in the first two formats |
| 1154 | by the inclusion of "GMT" as the three-letter abbreviation for time |
| 1155 | zone, and MUST be assumed when reading the asctime format. |
| 1156 | |
| 1157 | HTTP-date = rfc1123-date | rfc850-date | asctime-date |
| 1158 | |
| 1159 | rfc1123-date = wkday "," SP date1 SP time SP "GMT" |
| 1160 | rfc850-date = weekday "," SP date2 SP time SP "GMT" |
| 1161 | asctime-date = wkday SP date3 SP time SP 4DIGIT |
| 1162 | |
| 1163 | date1 = 2DIGIT SP month SP 4DIGIT |
| 1164 | ; day month year (e.g., 02 Jun 1982) |
| 1165 | date2 = 2DIGIT "-" month "-" 2DIGIT |
| 1166 | ; day-month-year (e.g., 02-Jun-82) |
| 1167 | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |
| 1168 | ; month day (e.g., Jun 2) |
| 1169 | |
| 1170 | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
| 1171 | ; 00:00:00 - 23:59:59 |
| 1172 | |
| 1173 | wkday = "Mon" | "Tue" | "Wed" |
| 1174 | | "Thu" | "Fri" | "Sat" | "Sun" |
| 1175 | |
| 1176 | |
| 1177 | |
| 1178 | Fielding, et. al. Standards Track [Page 21] |
| 1179 | \f |
| 1180 | RFC 2068 HTTP/1.1 January 1997 |
| 1181 | |
| 1182 | |
| 1183 | weekday = "Monday" | "Tuesday" | "Wednesday" |
| 1184 | | "Thursday" | "Friday" | "Saturday" | "Sunday" |
| 1185 | |
| 1186 | month = "Jan" | "Feb" | "Mar" | "Apr" |
| 1187 | | "May" | "Jun" | "Jul" | "Aug" |
| 1188 | | "Sep" | "Oct" | "Nov" | "Dec" |
| 1189 | |
| 1190 | Note: HTTP requirements for the date/time stamp format apply only |
| 1191 | to their usage within the protocol stream. Clients and servers are |
| 1192 | not required to use these formats for user presentation, request |
| 1193 | logging, etc. |
| 1194 | |
| 1195 | 3.3.2 Delta Seconds |
| 1196 | |
| 1197 | Some HTTP header fields allow a time value to be specified as an |
| 1198 | integer number of seconds, represented in decimal, after the time |
| 1199 | that the message was received. |
| 1200 | |
| 1201 | delta-seconds = 1*DIGIT |
| 1202 | |
| 1203 | 3.4 Character Sets |
| 1204 | |
| 1205 | HTTP uses the same definition of the term "character set" as that |
| 1206 | described for MIME: |
| 1207 | |
| 1208 | The term "character set" is used in this document to refer to a |
| 1209 | method used with one or more tables to convert a sequence of octets |
| 1210 | into a sequence of characters. Note that unconditional conversion |
| 1211 | in the other direction is not required, in that not all characters |
| 1212 | may be available in a given character set and a character set may |
| 1213 | provide more than one sequence of octets to represent a particular |
| 1214 | character. This definition is intended to allow various kinds of |
| 1215 | character encodings, from simple single-table mappings such as US- |
| 1216 | ASCII to complex table switching methods such as those that use ISO |
| 1217 | 2022's techniques. However, the definition associated with a MIME |
| 1218 | character set name MUST fully specify the mapping to be performed |
| 1219 | from octets to characters. In particular, use of external profiling |
| 1220 | information to determine the exact mapping is not permitted. |
| 1221 | |
| 1222 | Note: This use of the term "character set" is more commonly |
| 1223 | referred to as a "character encoding." However, since HTTP and MIME |
| 1224 | share the same registry, it is important that the terminology also |
| 1225 | be shared. |
| 1226 | |
| 1227 | |
| 1228 | |
| 1229 | |
| 1230 | |
| 1231 | |
| 1232 | |
| 1233 | |
| 1234 | Fielding, et. al. Standards Track [Page 22] |
| 1235 | \f |
| 1236 | RFC 2068 HTTP/1.1 January 1997 |
| 1237 | |
| 1238 | |
| 1239 | HTTP character sets are identified by case-insensitive tokens. The |
| 1240 | complete set of tokens is defined by the IANA Character Set registry |
| 1241 | [19]. |
| 1242 | |
| 1243 | charset = token |
| 1244 | |
| 1245 | Although HTTP allows an arbitrary token to be used as a charset |
| 1246 | value, any token that has a predefined value within the IANA |
| 1247 | Character Set registry MUST represent the character set defined by |
| 1248 | that registry. Applications SHOULD limit their use of character sets |
| 1249 | to those defined by the IANA registry. |
| 1250 | |
| 1251 | 3.5 Content Codings |
| 1252 | |
| 1253 | Content coding values indicate an encoding transformation that has |
| 1254 | been or can be applied to an entity. Content codings are primarily |
| 1255 | used to allow a document to be compressed or otherwise usefully |
| 1256 | transformed without losing the identity of its underlying media type |
| 1257 | and without loss of information. Frequently, the entity is stored in |
| 1258 | coded form, transmitted directly, and only decoded by the recipient. |
| 1259 | |
| 1260 | content-coding = token |
| 1261 | |
| 1262 | All content-coding values are case-insensitive. HTTP/1.1 uses |
| 1263 | content-coding values in the Accept-Encoding (section 14.3) and |
| 1264 | Content-Encoding (section 14.12) header fields. Although the value |
| 1265 | describes the content-coding, what is more important is that it |
| 1266 | indicates what decoding mechanism will be required to remove the |
| 1267 | encoding. |
| 1268 | |
| 1269 | The Internet Assigned Numbers Authority (IANA) acts as a registry for |
| 1270 | content-coding value tokens. Initially, the registry contains the |
| 1271 | following tokens: |
| 1272 | |
| 1273 | gzip An encoding format produced by the file compression program "gzip" |
| 1274 | (GNU zip) as described in RFC 1952 [25]. This format is a Lempel- |
| 1275 | Ziv coding (LZ77) with a 32 bit CRC. |
| 1276 | |
| 1277 | compress |
| 1278 | The encoding format produced by the common UNIX file compression |
| 1279 | program "compress". This format is an adaptive Lempel-Ziv-Welch |
| 1280 | coding (LZW). |
| 1281 | |
| 1282 | |
| 1283 | |
| 1284 | |
| 1285 | |
| 1286 | |
| 1287 | |
| 1288 | |
| 1289 | |
| 1290 | Fielding, et. al. Standards Track [Page 23] |
| 1291 | \f |
| 1292 | RFC 2068 HTTP/1.1 January 1997 |
| 1293 | |
| 1294 | |
| 1295 | Note: Use of program names for the identification of encoding |
| 1296 | formats is not desirable and should be discouraged for future |
| 1297 | encodings. Their use here is representative of historical practice, |
| 1298 | not good design. For compatibility with previous implementations of |
| 1299 | HTTP, applications should consider "x-gzip" and "x-compress" to be |
| 1300 | equivalent to "gzip" and "compress" respectively. |
| 1301 | |
| 1302 | deflate The "zlib" format defined in RFC 1950[31] in combination with |
| 1303 | the "deflate" compression mechanism described in RFC 1951[29]. |
| 1304 | |
| 1305 | New content-coding value tokens should be registered; to allow |
| 1306 | interoperability between clients and servers, specifications of the |
| 1307 | content coding algorithms needed to implement a new value should be |
| 1308 | publicly available and adequate for independent implementation, and |
| 1309 | conform to the purpose of content coding defined in this section. |
| 1310 | |
| 1311 | 3.6 Transfer Codings |
| 1312 | |
| 1313 | Transfer coding values are used to indicate an encoding |
| 1314 | transformation that has been, can be, or may need to be applied to an |
| 1315 | entity-body in order to ensure "safe transport" through the network. |
| 1316 | This differs from a content coding in that the transfer coding is a |
| 1317 | property of the message, not of the original entity. |
| 1318 | |
| 1319 | transfer-coding = "chunked" | transfer-extension |
| 1320 | |
| 1321 | transfer-extension = token |
| 1322 | |
| 1323 | All transfer-coding values are case-insensitive. HTTP/1.1 uses |
| 1324 | transfer coding values in the Transfer-Encoding header field (section |
| 1325 | 14.40). |
| 1326 | |
| 1327 | Transfer codings are analogous to the Content-Transfer-Encoding |
| 1328 | values of MIME , which were designed to enable safe transport of |
| 1329 | binary data over a 7-bit transport service. However, safe transport |
| 1330 | has a different focus for an 8bit-clean transfer protocol. In HTTP, |
| 1331 | the only unsafe characteristic of message-bodies is the difficulty in |
| 1332 | determining the exact body length (section 7.2.2), or the desire to |
| 1333 | encrypt data over a shared transport. |
| 1334 | |
| 1335 | The chunked encoding modifies the body of a message in order to |
| 1336 | transfer it as a series of chunks, each with its own size indicator, |
| 1337 | followed by an optional footer containing entity-header fields. This |
| 1338 | allows dynamically-produced content to be transferred along with the |
| 1339 | information necessary for the recipient to verify that it has |
| 1340 | received the full message. |
| 1341 | |
| 1342 | |
| 1343 | |
| 1344 | |
| 1345 | |
| 1346 | Fielding, et. al. Standards Track [Page 24] |
| 1347 | \f |
| 1348 | RFC 2068 HTTP/1.1 January 1997 |
| 1349 | |
| 1350 | |
| 1351 | Chunked-Body = *chunk |
| 1352 | "0" CRLF |
| 1353 | footer |
| 1354 | CRLF |
| 1355 | |
| 1356 | chunk = chunk-size [ chunk-ext ] CRLF |
| 1357 | chunk-data CRLF |
| 1358 | |
| 1359 | hex-no-zero = <HEX excluding "0"> |
| 1360 | |
| 1361 | chunk-size = hex-no-zero *HEX |
| 1362 | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) |
| 1363 | chunk-ext-name = token |
| 1364 | chunk-ext-val = token | quoted-string |
| 1365 | chunk-data = chunk-size(OCTET) |
| 1366 | |
| 1367 | footer = *entity-header |
| 1368 | |
| 1369 | The chunked encoding is ended by a zero-sized chunk followed by the |
| 1370 | footer, which is terminated by an empty line. The purpose of the |
| 1371 | footer is to provide an efficient way to supply information about an |
| 1372 | entity that is generated dynamically; applications MUST NOT send |
| 1373 | header fields in the footer which are not explicitly defined as being |
| 1374 | appropriate for the footer, such as Content-MD5 or future extensions |
| 1375 | to HTTP for digital signatures or other facilities. |
| 1376 | |
| 1377 | An example process for decoding a Chunked-Body is presented in |
| 1378 | appendix 19.4.6. |
| 1379 | |
| 1380 | All HTTP/1.1 applications MUST be able to receive and decode the |
| 1381 | "chunked" transfer coding, and MUST ignore transfer coding extensions |
| 1382 | they do not understand. A server which receives an entity-body with a |
| 1383 | transfer-coding it does not understand SHOULD return 501 |
| 1384 | (Unimplemented), and close the connection. A server MUST NOT send |
| 1385 | transfer-codings to an HTTP/1.0 client. |
| 1386 | |
| 1387 | 3.7 Media Types |
| 1388 | |
| 1389 | HTTP uses Internet Media Types in the Content-Type (section 14.18) |
| 1390 | and Accept (section 14.1) header fields in order to provide open and |
| 1391 | extensible data typing and type negotiation. |
| 1392 | |
| 1393 | media-type = type "/" subtype *( ";" parameter ) |
| 1394 | type = token |
| 1395 | subtype = token |
| 1396 | |
| 1397 | Parameters may follow the type/subtype in the form of attribute/value |
| 1398 | pairs. |
| 1399 | |
| 1400 | |
| 1401 | |
| 1402 | Fielding, et. al. Standards Track [Page 25] |
| 1403 | \f |
| 1404 | RFC 2068 HTTP/1.1 January 1997 |
| 1405 | |
| 1406 | |
| 1407 | parameter = attribute "=" value |
| 1408 | attribute = token |
| 1409 | value = token | quoted-string |
| 1410 | |
| 1411 | The type, subtype, and parameter attribute names are case- |
| 1412 | insensitive. Parameter values may or may not be case-sensitive, |
| 1413 | depending on the semantics of the parameter name. Linear white space |
| 1414 | (LWS) MUST NOT be used between the type and subtype, nor between an |
| 1415 | attribute and its value. User agents that recognize the media-type |
| 1416 | MUST process (or arrange to be processed by any external applications |
| 1417 | used to process that type/subtype by the user agent) the parameters |
| 1418 | for that MIME type as described by that type/subtype definition to |
| 1419 | the and inform the user of any problems discovered. |
| 1420 | |
| 1421 | Note: some older HTTP applications do not recognize media type |
| 1422 | parameters. When sending data to older HTTP applications, |
| 1423 | implementations should only use media type parameters when they are |
| 1424 | required by that type/subtype definition. |
| 1425 | |
| 1426 | Media-type values are registered with the Internet Assigned Number |
| 1427 | Authority (IANA). The media type registration process is outlined in |
| 1428 | RFC 2048 [17]. Use of non-registered media types is discouraged. |
| 1429 | |
| 1430 | 3.7.1 Canonicalization and Text Defaults |
| 1431 | |
| 1432 | Internet media types are registered with a canonical form. In |
| 1433 | general, an entity-body transferred via HTTP messages MUST be |
| 1434 | represented in the appropriate canonical form prior to its |
| 1435 | transmission; the exception is "text" types, as defined in the next |
| 1436 | paragraph. |
| 1437 | |
| 1438 | When in canonical form, media subtypes of the "text" type use CRLF as |
| 1439 | the text line break. HTTP relaxes this requirement and allows the |
| 1440 | transport of text media with plain CR or LF alone representing a line |
| 1441 | break when it is done consistently for an entire entity-body. HTTP |
| 1442 | applications MUST accept CRLF, bare CR, and bare LF as being |
| 1443 | representative of a line break in text media received via HTTP. In |
| 1444 | addition, if the text is represented in a character set that does not |
| 1445 | use octets 13 and 10 for CR and LF respectively, as is the case for |
| 1446 | some multi-byte character sets, HTTP allows the use of whatever octet |
| 1447 | sequences are defined by that character set to represent the |
| 1448 | equivalent of CR and LF for line breaks. This flexibility regarding |
| 1449 | line breaks applies only to text media in the entity-body; a bare CR |
| 1450 | or LF MUST NOT be substituted for CRLF within any of the HTTP control |
| 1451 | structures (such as header fields and multipart boundaries). |
| 1452 | |
| 1453 | If an entity-body is encoded with a Content-Encoding, the underlying |
| 1454 | data MUST be in a form defined above prior to being encoded. |
| 1455 | |
| 1456 | |
| 1457 | |
| 1458 | Fielding, et. al. Standards Track [Page 26] |
| 1459 | \f |
| 1460 | RFC 2068 HTTP/1.1 January 1997 |
| 1461 | |
| 1462 | |
| 1463 | The "charset" parameter is used with some media types to define the |
| 1464 | character set (section 3.4) of the data. When no explicit charset |
| 1465 | parameter is provided by the sender, media subtypes of the "text" |
| 1466 | type are defined to have a default charset value of "ISO-8859-1" when |
| 1467 | received via HTTP. Data in character sets other than "ISO-8859-1" or |
| 1468 | its subsets MUST be labeled with an appropriate charset value. |
| 1469 | |
| 1470 | Some HTTP/1.0 software has interpreted a Content-Type header without |
| 1471 | charset parameter incorrectly to mean "recipient should guess." |
| 1472 | Senders wishing to defeat this behavior MAY include a charset |
| 1473 | parameter even when the charset is ISO-8859-1 and SHOULD do so when |
| 1474 | it is known that it will not confuse the recipient. |
| 1475 | |
| 1476 | Unfortunately, some older HTTP/1.0 clients did not deal properly with |
| 1477 | an explicit charset parameter. HTTP/1.1 recipients MUST respect the |
| 1478 | charset label provided by the sender; and those user agents that have |
| 1479 | a provision to "guess" a charset MUST use the charset from the |
| 1480 | content-type field if they support that charset, rather than the |
| 1481 | recipient's preference, when initially displaying a document. |
| 1482 | |
| 1483 | 3.7.2 Multipart Types |
| 1484 | |
| 1485 | MIME provides for a number of "multipart" types -- encapsulations of |
| 1486 | one or more entities within a single message-body. All multipart |
| 1487 | types share a common syntax, as defined in MIME [7], and MUST |
| 1488 | include a boundary parameter as part of the media type value. The |
| 1489 | message body is itself a protocol element and MUST therefore use only |
| 1490 | CRLF to represent line breaks between body-parts. Unlike in MIME, the |
| 1491 | epilogue of any multipart message MUST be empty; HTTP applications |
| 1492 | MUST NOT transmit the epilogue (even if the original multipart |
| 1493 | contains an epilogue). |
| 1494 | |
| 1495 | In HTTP, multipart body-parts MAY contain header fields which are |
| 1496 | significant to the meaning of that part. A Content-Location header |
| 1497 | field (section 14.15) SHOULD be included in the body-part of each |
| 1498 | enclosed entity that can be identified by a URL. |
| 1499 | |
| 1500 | In general, an HTTP user agent SHOULD follow the same or similar |
| 1501 | behavior as a MIME user agent would upon receipt of a multipart type. |
| 1502 | If an application receives an unrecognized multipart subtype, the |
| 1503 | application MUST treat it as being equivalent to "multipart/mixed". |
| 1504 | |
| 1505 | Note: The "multipart/form-data" type has been specifically defined |
| 1506 | for carrying form data suitable for processing via the POST request |
| 1507 | method, as described in RFC 1867 [15]. |
| 1508 | |
| 1509 | |
| 1510 | |
| 1511 | |
| 1512 | |
| 1513 | |
| 1514 | Fielding, et. al. Standards Track [Page 27] |
| 1515 | \f |
| 1516 | RFC 2068 HTTP/1.1 January 1997 |
| 1517 | |
| 1518 | |
| 1519 | 3.8 Product Tokens |
| 1520 | |
| 1521 | Product tokens are used to allow communicating applications to |
| 1522 | identify themselves by software name and version. Most fields using |
| 1523 | product tokens also allow sub-products which form a significant part |
| 1524 | of the application to be listed, separated by whitespace. By |
| 1525 | convention, the products are listed in order of their significance |
| 1526 | for identifying the application. |
| 1527 | |
| 1528 | product = token ["/" product-version] |
| 1529 | product-version = token |
| 1530 | |
| 1531 | Examples: |
| 1532 | |
| 1533 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| 1534 | Server: Apache/0.8.4 |
| 1535 | |
| 1536 | Product tokens should be short and to the point -- use of them for |
| 1537 | advertising or other non-essential information is explicitly |
| 1538 | forbidden. Although any token character may appear in a product- |
| 1539 | version, this token SHOULD only be used for a version identifier |
| 1540 | (i.e., successive versions of the same product SHOULD only differ in |
| 1541 | the product-version portion of the product value). |
| 1542 | |
| 1543 | 3.9 Quality Values |
| 1544 | |
| 1545 | HTTP content negotiation (section 12) uses short "floating point" |
| 1546 | numbers to indicate the relative importance ("weight") of various |
| 1547 | negotiable parameters. A weight is normalized to a real number in the |
| 1548 | range 0 through 1, where 0 is the minimum and 1 the maximum value. |
| 1549 | HTTP/1.1 applications MUST NOT generate more than three digits after |
| 1550 | the decimal point. User configuration of these values SHOULD also be |
| 1551 | limited in this fashion. |
| 1552 | |
| 1553 | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
| 1554 | | ( "1" [ "." 0*3("0") ] ) |
| 1555 | |
| 1556 | "Quality values" is a misnomer, since these values merely represent |
| 1557 | relative degradation in desired quality. |
| 1558 | |
| 1559 | 3.10 Language Tags |
| 1560 | |
| 1561 | A language tag identifies a natural language spoken, written, or |
| 1562 | otherwise conveyed by human beings for communication of information |
| 1563 | to other human beings. Computer languages are explicitly excluded. |
| 1564 | HTTP uses language tags within the Accept-Language and Content- |
| 1565 | Language fields. |
| 1566 | |
| 1567 | |
| 1568 | |
| 1569 | |
| 1570 | Fielding, et. al. Standards Track [Page 28] |
| 1571 | \f |
| 1572 | RFC 2068 HTTP/1.1 January 1997 |
| 1573 | |
| 1574 | |
| 1575 | The syntax and registry of HTTP language tags is the same as that |
| 1576 | defined by RFC 1766 [1]. In summary, a language tag is composed of 1 |
| 1577 | or more parts: A primary language tag and a possibly empty series of |
| 1578 | subtags: |
| 1579 | |
| 1580 | language-tag = primary-tag *( "-" subtag ) |
| 1581 | |
| 1582 | primary-tag = 1*8ALPHA |
| 1583 | subtag = 1*8ALPHA |
| 1584 | |
| 1585 | Whitespace is not allowed within the tag and all tags are case- |
| 1586 | insensitive. The name space of language tags is administered by the |
| 1587 | IANA. Example tags include: |
| 1588 | |
| 1589 | en, en-US, en-cockney, i-cherokee, x-pig-latin |
| 1590 | |
| 1591 | where any two-letter primary-tag is an ISO 639 language abbreviation |
| 1592 | and any two-letter initial subtag is an ISO 3166 country code. (The |
| 1593 | last three tags above are not registered tags; all but the last are |
| 1594 | examples of tags which could be registered in future.) |
| 1595 | |
| 1596 | 3.11 Entity Tags |
| 1597 | |
| 1598 | Entity tags are used for comparing two or more entities from the same |
| 1599 | requested resource. HTTP/1.1 uses entity tags in the ETag (section |
| 1600 | 14.20), If-Match (section 14.25), If-None-Match (section 14.26), and |
| 1601 | If-Range (section 14.27) header fields. The definition of how they |
| 1602 | are used and compared as cache validators is in section 13.3.3. An |
| 1603 | entity tag consists of an opaque quoted string, possibly prefixed by |
| 1604 | a weakness indicator. |
| 1605 | |
| 1606 | entity-tag = [ weak ] opaque-tag |
| 1607 | |
| 1608 | weak = "W/" |
| 1609 | opaque-tag = quoted-string |
| 1610 | |
| 1611 | A "strong entity tag" may be shared by two entities of a resource |
| 1612 | only if they are equivalent by octet equality. |
| 1613 | |
| 1614 | A "weak entity tag," indicated by the "W/" prefix, may be shared by |
| 1615 | two entities of a resource only if the entities are equivalent and |
| 1616 | could be substituted for each other with no significant change in |
| 1617 | semantics. A weak entity tag can only be used for weak comparison. |
| 1618 | |
| 1619 | An entity tag MUST be unique across all versions of all entities |
| 1620 | associated with a particular resource. A given entity tag value may |
| 1621 | be used for entities obtained by requests on different URIs without |
| 1622 | implying anything about the equivalence of those entities. |
| 1623 | |
| 1624 | |
| 1625 | |
| 1626 | Fielding, et. al. Standards Track [Page 29] |
| 1627 | \f |
| 1628 | RFC 2068 HTTP/1.1 January 1997 |
| 1629 | |
| 1630 | |
| 1631 | 3.12 Range Units |
| 1632 | |
| 1633 | HTTP/1.1 allows a client to request that only part (a range of) the |
| 1634 | response entity be included within the response. HTTP/1.1 uses range |
| 1635 | units in the Range (section 14.36) and Content-Range (section 14.17) |
| 1636 | header fields. An entity may be broken down into subranges according |
| 1637 | to various structural units. |
| 1638 | |
| 1639 | range-unit = bytes-unit | other-range-unit |
| 1640 | |
| 1641 | bytes-unit = "bytes" |
| 1642 | other-range-unit = token |
| 1643 | |
| 1644 | The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 |
| 1645 | implementations may ignore ranges specified using other units. |
| 1646 | HTTP/1.1 has been designed to allow implementations of applications |
| 1647 | that do not depend on knowledge of ranges. |
| 1648 | |
| 1649 | 4 HTTP Message |
| 1650 | |
| 1651 | 4.1 Message Types |
| 1652 | |
| 1653 | HTTP messages consist of requests from client to server and responses |
| 1654 | from server to client. |
| 1655 | |
| 1656 | HTTP-message = Request | Response ; HTTP/1.1 messages |
| 1657 | |
| 1658 | Request (section 5) and Response (section 6) messages use the generic |
| 1659 | message format of RFC 822 [9] for transferring entities (the payload |
| 1660 | of the message). Both types of message consist of a start-line, one |
| 1661 | or more header fields (also known as "headers"), an empty line (i.e., |
| 1662 | a line with nothing preceding the CRLF) indicating the end of the |
| 1663 | header fields, and an optional message-body. |
| 1664 | |
| 1665 | generic-message = start-line |
| 1666 | *message-header |
| 1667 | CRLF |
| 1668 | [ message-body ] |
| 1669 | |
| 1670 | start-line = Request-Line | Status-Line |
| 1671 | |
| 1672 | In the interest of robustness, servers SHOULD ignore any empty |
| 1673 | line(s) received where a Request-Line is expected. In other words, if |
| 1674 | the server is reading the protocol stream at the beginning of a |
| 1675 | message and receives a CRLF first, it should ignore the CRLF. |
| 1676 | |
| 1677 | |
| 1678 | |
| 1679 | |
| 1680 | |
| 1681 | |
| 1682 | Fielding, et. al. Standards Track [Page 30] |
| 1683 | \f |
| 1684 | RFC 2068 HTTP/1.1 January 1997 |
| 1685 | |
| 1686 | |
| 1687 | Note: certain buggy HTTP/1.0 client implementations generate an |
| 1688 | extra CRLF's after a POST request. To restate what is explicitly |
| 1689 | forbidden by the BNF, an HTTP/1.1 client must not preface or follow |
| 1690 | a request with an extra CRLF. |
| 1691 | |
| 1692 | 4.2 Message Headers |
| 1693 | |
| 1694 | HTTP header fields, which include general-header (section 4.5), |
| 1695 | request-header (section 5.3), response-header (section 6.2), and |
| 1696 | entity-header (section 7.1) fields, follow the same generic format as |
| 1697 | that given in Section 3.1 of RFC 822 [9]. Each header field consists |
| 1698 | of a name followed by a colon (":") and the field value. Field names |
| 1699 | are case-insensitive. The field value may be preceded by any amount |
| 1700 | of LWS, though a single SP is preferred. Header fields can be |
| 1701 | extended over multiple lines by preceding each extra line with at |
| 1702 | least one SP or HT. Applications SHOULD follow "common form" when |
| 1703 | generating HTTP constructs, since there might exist some |
| 1704 | implementations that fail to accept anything beyond the common forms. |
| 1705 | |
| 1706 | message-header = field-name ":" [ field-value ] CRLF |
| 1707 | |
| 1708 | field-name = token |
| 1709 | field-value = *( field-content | LWS ) |
| 1710 | |
| 1711 | field-content = <the OCTETs making up the field-value |
| 1712 | and consisting of either *TEXT or combinations |
| 1713 | of token, tspecials, and quoted-string> |
| 1714 | |
| 1715 | The order in which header fields with differing field names are |
| 1716 | received is not significant. However, it is "good practice" to send |
| 1717 | general-header fields first, followed by request-header or response- |
| 1718 | header fields, and ending with the entity-header fields. |
| 1719 | |
| 1720 | Multiple message-header fields with the same field-name may be |
| 1721 | present in a message if and only if the entire field-value for that |
| 1722 | header field is defined as a comma-separated list [i.e., #(values)]. |
| 1723 | It MUST be possible to combine the multiple header fields into one |
| 1724 | "field-name: field-value" pair, without changing the semantics of the |
| 1725 | message, by appending each subsequent field-value to the first, each |
| 1726 | separated by a comma. The order in which header fields with the same |
| 1727 | field-name are received is therefore significant to the |
| 1728 | interpretation of the combined field value, and thus a proxy MUST NOT |
| 1729 | change the order of these field values when a message is forwarded. |
| 1730 | |
| 1731 | |
| 1732 | |
| 1733 | |
| 1734 | |
| 1735 | |
| 1736 | |
| 1737 | |
| 1738 | Fielding, et. al. Standards Track [Page 31] |
| 1739 | \f |
| 1740 | RFC 2068 HTTP/1.1 January 1997 |
| 1741 | |
| 1742 | |
| 1743 | 4.3 Message Body |
| 1744 | |
| 1745 | The message-body (if any) of an HTTP message is used to carry the |
| 1746 | entity-body associated with the request or response. The message-body |
| 1747 | differs from the entity-body only when a transfer coding has been |
| 1748 | applied, as indicated by the Transfer-Encoding header field (section |
| 1749 | 14.40). |
| 1750 | |
| 1751 | message-body = entity-body |
| 1752 | | <entity-body encoded as per Transfer-Encoding> |
| 1753 | |
| 1754 | Transfer-Encoding MUST be used to indicate any transfer codings |
| 1755 | applied by an application to ensure safe and proper transfer of the |
| 1756 | message. Transfer-Encoding is a property of the message, not of the |
| 1757 | entity, and thus can be added or removed by any application along the |
| 1758 | request/response chain. |
| 1759 | |
| 1760 | The rules for when a message-body is allowed in a message differ for |
| 1761 | requests and responses. |
| 1762 | |
| 1763 | The presence of a message-body in a request is signaled by the |
| 1764 | inclusion of a Content-Length or Transfer-Encoding header field in |
| 1765 | the request's message-headers. A message-body MAY be included in a |
| 1766 | request only when the request method (section 5.1.1) allows an |
| 1767 | entity-body. |
| 1768 | |
| 1769 | For response messages, whether or not a message-body is included with |
| 1770 | a message is dependent on both the request method and the response |
| 1771 | status code (section 6.1.1). All responses to the HEAD request method |
| 1772 | MUST NOT include a message-body, even though the presence of entity- |
| 1773 | header fields might lead one to believe they do. All 1xx |
| 1774 | (informational), 204 (no content), and 304 (not modified) responses |
| 1775 | MUST NOT include a message-body. All other responses do include a |
| 1776 | message-body, although it may be of zero length. |
| 1777 | |
| 1778 | 4.4 Message Length |
| 1779 | |
| 1780 | When a message-body is included with a message, the length of that |
| 1781 | body is determined by one of the following (in order of precedence): |
| 1782 | |
| 1783 | 1. Any response message which MUST NOT include a message-body |
| 1784 | (such as the 1xx, 204, and 304 responses and any response to a HEAD |
| 1785 | request) is always terminated by the first empty line after the |
| 1786 | header fields, regardless of the entity-header fields present in the |
| 1787 | message. |
| 1788 | |
| 1789 | 2. If a Transfer-Encoding header field (section 14.40) is present and |
| 1790 | indicates that the "chunked" transfer coding has been applied, then |
| 1791 | |
| 1792 | |
| 1793 | |
| 1794 | Fielding, et. al. Standards Track [Page 32] |
| 1795 | \f |
| 1796 | RFC 2068 HTTP/1.1 January 1997 |
| 1797 | |
| 1798 | |
| 1799 | the length is defined by the chunked encoding (section 3.6). |
| 1800 | |
| 1801 | 3. If a Content-Length header field (section 14.14) is present, its |
| 1802 | value in bytes represents the length of the message-body. |
| 1803 | |
| 1804 | 4. If the message uses the media type "multipart/byteranges", which is |
| 1805 | self-delimiting, then that defines the length. This media type MUST |
| 1806 | NOT be used unless the sender knows that the recipient can parse it; |
| 1807 | the presence in a request of a Range header with multiple byte-range |
| 1808 | specifiers implies that the client can parse multipart/byteranges |
| 1809 | responses. |
| 1810 | |
| 1811 | 5. By the server closing the connection. (Closing the connection |
| 1812 | cannot be used to indicate the end of a request body, since that |
| 1813 | would leave no possibility for the server to send back a response.) |
| 1814 | |
| 1815 | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |
| 1816 | containing a message-body MUST include a valid Content-Length header |
| 1817 | field unless the server is known to be HTTP/1.1 compliant. If a |
| 1818 | request contains a message-body and a Content-Length is not given, |
| 1819 | the server SHOULD respond with 400 (bad request) if it cannot |
| 1820 | determine the length of the message, or with 411 (length required) if |
| 1821 | it wishes to insist on receiving a valid Content-Length. |
| 1822 | |
| 1823 | All HTTP/1.1 applications that receive entities MUST accept the |
| 1824 | "chunked" transfer coding (section 3.6), thus allowing this mechanism |
| 1825 | to be used for messages when the message length cannot be determined |
| 1826 | in advance. |
| 1827 | |
| 1828 | Messages MUST NOT include both a Content-Length header field and the |
| 1829 | "chunked" transfer coding. If both are received, the Content-Length |
| 1830 | MUST be ignored. |
| 1831 | |
| 1832 | When a Content-Length is given in a message where a message-body is |
| 1833 | allowed, its field value MUST exactly match the number of OCTETs in |
| 1834 | the message-body. HTTP/1.1 user agents MUST notify the user when an |
| 1835 | invalid length is received and detected. |
| 1836 | |
| 1837 | |
| 1838 | |
| 1839 | |
| 1840 | |
| 1841 | |
| 1842 | |
| 1843 | |
| 1844 | |
| 1845 | |
| 1846 | |
| 1847 | |
| 1848 | |
| 1849 | |
| 1850 | Fielding, et. al. Standards Track [Page 33] |
| 1851 | \f |
| 1852 | RFC 2068 HTTP/1.1 January 1997 |
| 1853 | |
| 1854 | |
| 1855 | 4.5 General Header Fields |
| 1856 | |
| 1857 | There are a few header fields which have general applicability for |
| 1858 | both request and response messages, but which do not apply to the |
| 1859 | entity being transferred. These header fields apply only to the |
| 1860 | message being transmitted. |
| 1861 | |
| 1862 | general-header = Cache-Control ; Section 14.9 |
| 1863 | | Connection ; Section 14.10 |
| 1864 | | Date ; Section 14.19 |
| 1865 | | Pragma ; Section 14.32 |
| 1866 | | Transfer-Encoding ; Section 14.40 |
| 1867 | | Upgrade ; Section 14.41 |
| 1868 | | Via ; Section 14.44 |
| 1869 | |
| 1870 | General-header field names can be extended reliably only in |
| 1871 | combination with a change in the protocol version. However, new or |
| 1872 | experimental header fields may be given the semantics of general |
| 1873 | header fields if all parties in the communication recognize them to |
| 1874 | be general-header fields. Unrecognized header fields are treated as |
| 1875 | entity-header fields. |
| 1876 | |
| 1877 | 5 Request |
| 1878 | |
| 1879 | A request message from a client to a server includes, within the |
| 1880 | first line of that message, the method to be applied to the resource, |
| 1881 | the identifier of the resource, and the protocol version in use. |
| 1882 | |
| 1883 | Request = Request-Line ; Section 5.1 |
| 1884 | *( general-header ; Section 4.5 |
| 1885 | | request-header ; Section 5.3 |
| 1886 | | entity-header ) ; Section 7.1 |
| 1887 | CRLF |
| 1888 | [ message-body ] ; Section 7.2 |
| 1889 | |
| 1890 | 5.1 Request-Line |
| 1891 | |
| 1892 | The Request-Line begins with a method token, followed by the |
| 1893 | Request-URI and the protocol version, and ending with CRLF. The |
| 1894 | elements are separated by SP characters. No CR or LF are allowed |
| 1895 | except in the final CRLF sequence. |
| 1896 | |
| 1897 | Request-Line = Method SP Request-URI SP HTTP-Version CRLF |
| 1898 | |
| 1899 | |
| 1900 | |
| 1901 | |
| 1902 | |
| 1903 | |
| 1904 | |
| 1905 | |
| 1906 | Fielding, et. al. Standards Track [Page 34] |
| 1907 | \f |
| 1908 | RFC 2068 HTTP/1.1 January 1997 |
| 1909 | |
| 1910 | |
| 1911 | 5.1.1 Method |
| 1912 | |
| 1913 | The Method token indicates the method to be performed on the resource |
| 1914 | identified by the Request-URI. The method is case-sensitive. |
| 1915 | |
| 1916 | Method = "OPTIONS" ; Section 9.2 |
| 1917 | | "GET" ; Section 9.3 |
| 1918 | | "HEAD" ; Section 9.4 |
| 1919 | | "POST" ; Section 9.5 |
| 1920 | | "PUT" ; Section 9.6 |
| 1921 | | "DELETE" ; Section 9.7 |
| 1922 | | "TRACE" ; Section 9.8 |
| 1923 | | extension-method |
| 1924 | |
| 1925 | extension-method = token |
| 1926 | |
| 1927 | The list of methods allowed by a resource can be specified in an |
| 1928 | Allow header field (section 14.7). The return code of the response |
| 1929 | always notifies the client whether a method is currently allowed on a |
| 1930 | resource, since the set of allowed methods can change dynamically. |
| 1931 | Servers SHOULD return the status code 405 (Method Not Allowed) if the |
| 1932 | method is known by the server but not allowed for the requested |
| 1933 | resource, and 501 (Not Implemented) if the method is unrecognized or |
| 1934 | not implemented by the server. The list of methods known by a server |
| 1935 | can be listed in a Public response-header field (section 14.35). |
| 1936 | |
| 1937 | The methods GET and HEAD MUST be supported by all general-purpose |
| 1938 | servers. All other methods are optional; however, if the above |
| 1939 | methods are implemented, they MUST be implemented with the same |
| 1940 | semantics as those specified in section 9. |
| 1941 | |
| 1942 | 5.1.2 Request-URI |
| 1943 | |
| 1944 | The Request-URI is a Uniform Resource Identifier (section 3.2) and |
| 1945 | identifies the resource upon which to apply the request. |
| 1946 | |
| 1947 | Request-URI = "*" | absoluteURI | abs_path |
| 1948 | |
| 1949 | The three options for Request-URI are dependent on the nature of the |
| 1950 | request. The asterisk "*" means that the request does not apply to a |
| 1951 | particular resource, but to the server itself, and is only allowed |
| 1952 | when the method used does not necessarily apply to a resource. One |
| 1953 | example would be |
| 1954 | |
| 1955 | OPTIONS * HTTP/1.1 |
| 1956 | |
| 1957 | The absoluteURI form is required when the request is being made to a |
| 1958 | proxy. The proxy is requested to forward the request or service it |
| 1959 | |
| 1960 | |
| 1961 | |
| 1962 | Fielding, et. al. Standards Track [Page 35] |
| 1963 | \f |
| 1964 | RFC 2068 HTTP/1.1 January 1997 |
| 1965 | |
| 1966 | |
| 1967 | from a valid cache, and return the response. Note that the proxy MAY |
| 1968 | forward the request on to another proxy or directly to the server |
| 1969 | specified by the absoluteURI. In order to avoid request loops, a |
| 1970 | proxy MUST be able to recognize all of its server names, including |
| 1971 | any aliases, local variations, and the numeric IP address. An example |
| 1972 | Request-Line would be: |
| 1973 | |
| 1974 | GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 |
| 1975 | |
| 1976 | To allow for transition to absoluteURIs in all requests in future |
| 1977 | versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI |
| 1978 | form in requests, even though HTTP/1.1 clients will only generate |
| 1979 | them in requests to proxies. |
| 1980 | |
| 1981 | The most common form of Request-URI is that used to identify a |
| 1982 | resource on an origin server or gateway. In this case the absolute |
| 1983 | path of the URI MUST be transmitted (see section 3.2.1, abs_path) as |
| 1984 | the Request-URI, and the network location of the URI (net_loc) MUST |
| 1985 | be transmitted in a Host header field. For example, a client wishing |
| 1986 | to retrieve the resource above directly from the origin server would |
| 1987 | create a TCP connection to port 80 of the host "www.w3.org" and send |
| 1988 | the lines: |
| 1989 | |
| 1990 | GET /pub/WWW/TheProject.html HTTP/1.1 |
| 1991 | Host: www.w3.org |
| 1992 | |
| 1993 | followed by the remainder of the Request. Note that the absolute path |
| 1994 | cannot be empty; if none is present in the original URI, it MUST be |
| 1995 | given as "/" (the server root). |
| 1996 | |
| 1997 | If a proxy receives a request without any path in the Request-URI and |
| 1998 | the method specified is capable of supporting the asterisk form of |
| 1999 | request, then the last proxy on the request chain MUST forward the |
| 2000 | request with "*" as the final Request-URI. For example, the request |
| 2001 | |
| 2002 | OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 |
| 2003 | |
| 2004 | would be forwarded by the proxy as |
| 2005 | |
| 2006 | OPTIONS * HTTP/1.1 |
| 2007 | Host: www.ics.uci.edu:8001 |
| 2008 | |
| 2009 | after connecting to port 8001 of host "www.ics.uci.edu". |
| 2010 | |
| 2011 | The Request-URI is transmitted in the format specified in section |
| 2012 | 3.2.1. The origin server MUST decode the Request-URI in order to |
| 2013 | properly interpret the request. Servers SHOULD respond to invalid |
| 2014 | Request-URIs with an appropriate status code. |
| 2015 | |
| 2016 | |
| 2017 | |
| 2018 | Fielding, et. al. Standards Track [Page 36] |
| 2019 | \f |
| 2020 | RFC 2068 HTTP/1.1 January 1997 |
| 2021 | |
| 2022 | |
| 2023 | In requests that they forward, proxies MUST NOT rewrite the |
| 2024 | "abs_path" part of a Request-URI in any way except as noted above to |
| 2025 | replace a null abs_path with "*", no matter what the proxy does in |
| 2026 | its internal implementation. |
| 2027 | |
| 2028 | Note: The "no rewrite" rule prevents the proxy from changing the |
| 2029 | meaning of the request when the origin server is improperly using a |
| 2030 | non-reserved URL character for a reserved purpose. Implementers |
| 2031 | should be aware that some pre-HTTP/1.1 proxies have been known to |
| 2032 | rewrite the Request-URI. |
| 2033 | |
| 2034 | 5.2 The Resource Identified by a Request |
| 2035 | |
| 2036 | HTTP/1.1 origin servers SHOULD be aware that the exact resource |
| 2037 | identified by an Internet request is determined by examining both the |
| 2038 | Request-URI and the Host header field. |
| 2039 | |
| 2040 | An origin server that does not allow resources to differ by the |
| 2041 | requested host MAY ignore the Host header field value. (But see |
| 2042 | section 19.5.1 for other requirements on Host support in HTTP/1.1.) |
| 2043 | |
| 2044 | An origin server that does differentiate resources based on the host |
| 2045 | requested (sometimes referred to as virtual hosts or vanity |
| 2046 | hostnames) MUST use the following rules for determining the requested |
| 2047 | resource on an HTTP/1.1 request: |
| 2048 | |
| 2049 | 1. If Request-URI is an absoluteURI, the host is part of the |
| 2050 | Request-URI. Any Host header field value in the request MUST be |
| 2051 | ignored. |
| 2052 | |
| 2053 | 2. If the Request-URI is not an absoluteURI, and the request |
| 2054 | includes a Host header field, the host is determined by the Host |
| 2055 | header field value. |
| 2056 | |
| 2057 | 3. If the host as determined by rule 1 or 2 is not a valid host on |
| 2058 | the server, the response MUST be a 400 (Bad Request) error |
| 2059 | message. |
| 2060 | |
| 2061 | Recipients of an HTTP/1.0 request that lacks a Host header field MAY |
| 2062 | attempt to use heuristics (e.g., examination of the URI path for |
| 2063 | something unique to a particular host) in order to determine what |
| 2064 | exact resource is being requested. |
| 2065 | |
| 2066 | 5.3 Request Header Fields |
| 2067 | |
| 2068 | The request-header fields allow the client to pass additional |
| 2069 | information about the request, and about the client itself, to the |
| 2070 | server. These fields act as request modifiers, with semantics |
| 2071 | |
| 2072 | |
| 2073 | |
| 2074 | Fielding, et. al. Standards Track [Page 37] |
| 2075 | \f |
| 2076 | RFC 2068 HTTP/1.1 January 1997 |
| 2077 | |
| 2078 | |
| 2079 | equivalent to the parameters on a programming language method |
| 2080 | invocation. |
| 2081 | |
| 2082 | request-header = Accept ; Section 14.1 |
| 2083 | | Accept-Charset ; Section 14.2 |
| 2084 | | Accept-Encoding ; Section 14.3 |
| 2085 | | Accept-Language ; Section 14.4 |
| 2086 | | Authorization ; Section 14.8 |
| 2087 | | From ; Section 14.22 |
| 2088 | | Host ; Section 14.23 |
| 2089 | | If-Modified-Since ; Section 14.24 |
| 2090 | | If-Match ; Section 14.25 |
| 2091 | | If-None-Match ; Section 14.26 |
| 2092 | | If-Range ; Section 14.27 |
| 2093 | | If-Unmodified-Since ; Section 14.28 |
| 2094 | | Max-Forwards ; Section 14.31 |
| 2095 | | Proxy-Authorization ; Section 14.34 |
| 2096 | | Range ; Section 14.36 |
| 2097 | | Referer ; Section 14.37 |
| 2098 | | User-Agent ; Section 14.42 |
| 2099 | |
| 2100 | Request-header field names can be extended reliably only in |
| 2101 | combination with a change in the protocol version. However, new or |
| 2102 | experimental header fields MAY be given the semantics of request- |
| 2103 | header fields if all parties in the communication recognize them to |
| 2104 | be request-header fields. Unrecognized header fields are treated as |
| 2105 | entity-header fields. |
| 2106 | |
| 2107 | 6 Response |
| 2108 | |
| 2109 | After receiving and interpreting a request message, a server responds |
| 2110 | with an HTTP response message. |
| 2111 | |
| 2112 | Response = Status-Line ; Section 6.1 |
| 2113 | *( general-header ; Section 4.5 |
| 2114 | | response-header ; Section 6.2 |
| 2115 | | entity-header ) ; Section 7.1 |
| 2116 | CRLF |
| 2117 | [ message-body ] ; Section 7.2 |
| 2118 | |
| 2119 | 6.1 Status-Line |
| 2120 | |
| 2121 | The first line of a Response message is the Status-Line, consisting |
| 2122 | of the protocol version followed by a numeric status code and its |
| 2123 | associated textual phrase, with each element separated by SP |
| 2124 | characters. No CR or LF is allowed except in the final CRLF |
| 2125 | sequence. |
| 2126 | |
| 2127 | |
| 2128 | |
| 2129 | |
| 2130 | Fielding, et. al. Standards Track [Page 38] |
| 2131 | \f |
| 2132 | RFC 2068 HTTP/1.1 January 1997 |
| 2133 | |
| 2134 | |
| 2135 | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| 2136 | |
| 2137 | 6.1.1 Status Code and Reason Phrase |
| 2138 | |
| 2139 | The Status-Code element is a 3-digit integer result code of the |
| 2140 | attempt to understand and satisfy the request. These codes are fully |
| 2141 | defined in section 10. The Reason-Phrase is intended to give a short |
| 2142 | textual description of the Status-Code. The Status-Code is intended |
| 2143 | for use by automata and the Reason-Phrase is intended for the human |
| 2144 | user. The client is not required to examine or display the Reason- |
| 2145 | Phrase. |
| 2146 | |
| 2147 | The first digit of the Status-Code defines the class of response. The |
| 2148 | last two digits do not have any categorization role. There are 5 |
| 2149 | values for the first digit: |
| 2150 | |
| 2151 | o 1xx: Informational - Request received, continuing process |
| 2152 | |
| 2153 | o 2xx: Success - The action was successfully received, understood, |
| 2154 | and accepted |
| 2155 | |
| 2156 | o 3xx: Redirection - Further action must be taken in order to |
| 2157 | complete the request |
| 2158 | |
| 2159 | o 4xx: Client Error - The request contains bad syntax or cannot be |
| 2160 | fulfilled |
| 2161 | |
| 2162 | o 5xx: Server Error - The server failed to fulfill an apparently |
| 2163 | valid request |
| 2164 | |
| 2165 | The individual values of the numeric status codes defined for |
| 2166 | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are |
| 2167 | presented below. The reason phrases listed here are only recommended |
| 2168 | -- they may be replaced by local equivalents without affecting the |
| 2169 | protocol. |
| 2170 | |
| 2171 | Status-Code = "100" ; Continue |
| 2172 | | "101" ; Switching Protocols |
| 2173 | | "200" ; OK |
| 2174 | | "201" ; Created |
| 2175 | | "202" ; Accepted |
| 2176 | | "203" ; Non-Authoritative Information |
| 2177 | | "204" ; No Content |
| 2178 | | "205" ; Reset Content |
| 2179 | | "206" ; Partial Content |
| 2180 | | "300" ; Multiple Choices |
| 2181 | | "301" ; Moved Permanently |
| 2182 | | "302" ; Moved Temporarily |
| 2183 | |
| 2184 | |
| 2185 | |
| 2186 | Fielding, et. al. Standards Track [Page 39] |
| 2187 | \f |
| 2188 | RFC 2068 HTTP/1.1 January 1997 |
| 2189 | |
| 2190 | |
| 2191 | | "303" ; See Other |
| 2192 | | "304" ; Not Modified |
| 2193 | | "305" ; Use Proxy |
| 2194 | | "400" ; Bad Request |
| 2195 | | "401" ; Unauthorized |
| 2196 | | "402" ; Payment Required |
| 2197 | | "403" ; Forbidden |
| 2198 | | "404" ; Not Found |
| 2199 | | "405" ; Method Not Allowed |
| 2200 | | "406" ; Not Acceptable |
| 2201 | | "407" ; Proxy Authentication Required |
| 2202 | | "408" ; Request Time-out |
| 2203 | | "409" ; Conflict |
| 2204 | | "410" ; Gone |
| 2205 | | "411" ; Length Required |
| 2206 | | "412" ; Precondition Failed |
| 2207 | | "413" ; Request Entity Too Large |
| 2208 | | "414" ; Request-URI Too Large |
| 2209 | | "415" ; Unsupported Media Type |
| 2210 | | "500" ; Internal Server Error |
| 2211 | | "501" ; Not Implemented |
| 2212 | | "502" ; Bad Gateway |
| 2213 | | "503" ; Service Unavailable |
| 2214 | | "504" ; Gateway Time-out |
| 2215 | | "505" ; HTTP Version not supported |
| 2216 | | extension-code |
| 2217 | |
| 2218 | extension-code = 3DIGIT |
| 2219 | |
| 2220 | Reason-Phrase = *<TEXT, excluding CR, LF> |
| 2221 | |
| 2222 | HTTP status codes are extensible. HTTP applications are not required |
| 2223 | to understand the meaning of all registered status codes, though such |
| 2224 | understanding is obviously desirable. However, applications MUST |
| 2225 | understand the class of any status code, as indicated by the first |
| 2226 | digit, and treat any unrecognized response as being equivalent to the |
| 2227 | x00 status code of that class, with the exception that an |
| 2228 | unrecognized response MUST NOT be cached. For example, if an |
| 2229 | unrecognized status code of 431 is received by the client, it can |
| 2230 | safely assume that there was something wrong with its request and |
| 2231 | treat the response as if it had received a 400 status code. In such |
| 2232 | cases, user agents SHOULD present to the user the entity returned |
| 2233 | with the response, since that entity is likely to include human- |
| 2234 | readable information which will explain the unusual status. |
| 2235 | |
| 2236 | |
| 2237 | |
| 2238 | |
| 2239 | |
| 2240 | |
| 2241 | |
| 2242 | Fielding, et. al. Standards Track [Page 40] |
| 2243 | \f |
| 2244 | RFC 2068 HTTP/1.1 January 1997 |
| 2245 | |
| 2246 | |
| 2247 | 6.2 Response Header Fields |
| 2248 | |
| 2249 | The response-header fields allow the server to pass additional |
| 2250 | information about the response which cannot be placed in the Status- |
| 2251 | Line. These header fields give information about the server and about |
| 2252 | further access to the resource identified by the Request-URI. |
| 2253 | |
| 2254 | response-header = Age ; Section 14.6 |
| 2255 | | Location ; Section 14.30 |
| 2256 | | Proxy-Authenticate ; Section 14.33 |
| 2257 | | Public ; Section 14.35 |
| 2258 | | Retry-After ; Section 14.38 |
| 2259 | | Server ; Section 14.39 |
| 2260 | | Vary ; Section 14.43 |
| 2261 | | Warning ; Section 14.45 |
| 2262 | | WWW-Authenticate ; Section 14.46 |
| 2263 | |
| 2264 | Response-header field names can be extended reliably only in |
| 2265 | combination with a change in the protocol version. However, new or |
| 2266 | experimental header fields MAY be given the semantics of response- |
| 2267 | header fields if all parties in the communication recognize them to |
| 2268 | be response-header fields. Unrecognized header fields are treated as |
| 2269 | entity-header fields. |
| 2270 | |
| 2271 | 7 Entity |
| 2272 | |
| 2273 | Request and Response messages MAY transfer an entity if not otherwise |
| 2274 | restricted by the request method or response status code. An entity |
| 2275 | consists of entity-header fields and an entity-body, although some |
| 2276 | responses will only include the entity-headers. |
| 2277 | |
| 2278 | In this section, both sender and recipient refer to either the client |
| 2279 | or the server, depending on who sends and who receives the entity. |
| 2280 | |
| 2281 | 7.1 Entity Header Fields |
| 2282 | |
| 2283 | Entity-header fields define optional metainformation about the |
| 2284 | entity-body or, if no body is present, about the resource identified |
| 2285 | by the request. |
| 2286 | |
| 2287 | |
| 2288 | |
| 2289 | |
| 2290 | |
| 2291 | |
| 2292 | |
| 2293 | |
| 2294 | |
| 2295 | |
| 2296 | |
| 2297 | |
| 2298 | Fielding, et. al. Standards Track [Page 41] |
| 2299 | \f |
| 2300 | RFC 2068 HTTP/1.1 January 1997 |
| 2301 | |
| 2302 | |
| 2303 | entity-header = Allow ; Section 14.7 |
| 2304 | | Content-Base ; Section 14.11 |
| 2305 | | Content-Encoding ; Section 14.12 |
| 2306 | | Content-Language ; Section 14.13 |
| 2307 | | Content-Length ; Section 14.14 |
| 2308 | | Content-Location ; Section 14.15 |
| 2309 | | Content-MD5 ; Section 14.16 |
| 2310 | | Content-Range ; Section 14.17 |
| 2311 | | Content-Type ; Section 14.18 |
| 2312 | | ETag ; Section 14.20 |
| 2313 | | Expires ; Section 14.21 |
| 2314 | | Last-Modified ; Section 14.29 |
| 2315 | | extension-header |
| 2316 | |
| 2317 | extension-header = message-header |
| 2318 | |
| 2319 | The extension-header mechanism allows additional entity-header fields |
| 2320 | to be defined without changing the protocol, but these fields cannot |
| 2321 | be assumed to be recognizable by the recipient. Unrecognized header |
| 2322 | fields SHOULD be ignored by the recipient and forwarded by proxies. |
| 2323 | |
| 2324 | 7.2 Entity Body |
| 2325 | |
| 2326 | The entity-body (if any) sent with an HTTP request or response is in |
| 2327 | a format and encoding defined by the entity-header fields. |
| 2328 | |
| 2329 | entity-body = *OCTET |
| 2330 | |
| 2331 | An entity-body is only present in a message when a message-body is |
| 2332 | present, as described in section 4.3. The entity-body is obtained |
| 2333 | from the message-body by decoding any Transfer-Encoding that may have |
| 2334 | been applied to ensure safe and proper transfer of the message. |
| 2335 | |
| 2336 | 7.2.1 Type |
| 2337 | |
| 2338 | When an entity-body is included with a message, the data type of that |
| 2339 | body is determined via the header fields Content-Type and Content- |
| 2340 | Encoding. These define a two-layer, ordered encoding model: |
| 2341 | |
| 2342 | entity-body := Content-Encoding( Content-Type( data ) ) |
| 2343 | |
| 2344 | Content-Type specifies the media type of the underlying data. |
| 2345 | Content-Encoding may be used to indicate any additional content |
| 2346 | codings applied to the data, usually for the purpose of data |
| 2347 | compression, that are a property of the requested resource. There is |
| 2348 | no default encoding. |
| 2349 | |
| 2350 | |
| 2351 | |
| 2352 | |
| 2353 | |
| 2354 | Fielding, et. al. Standards Track [Page 42] |
| 2355 | \f |
| 2356 | RFC 2068 HTTP/1.1 January 1997 |
| 2357 | |
| 2358 | |
| 2359 | Any HTTP/1.1 message containing an entity-body SHOULD include a |
| 2360 | Content-Type header field defining the media type of that body. If |
| 2361 | and only if the media type is not given by a Content-Type field, the |
| 2362 | recipient MAY attempt to guess the media type via inspection of its |
| 2363 | content and/or the name extension(s) of the URL used to identify the |
| 2364 | resource. If the media type remains unknown, the recipient SHOULD |
| 2365 | treat it as type "application/octet-stream". |
| 2366 | |
| 2367 | 7.2.2 Length |
| 2368 | |
| 2369 | The length of an entity-body is the length of the message-body after |
| 2370 | any transfer codings have been removed. Section 4.4 defines how the |
| 2371 | length of a message-body is determined. |
| 2372 | |
| 2373 | 8 Connections |
| 2374 | |
| 2375 | 8.1 Persistent Connections |
| 2376 | |
| 2377 | 8.1.1 Purpose |
| 2378 | |
| 2379 | Prior to persistent connections, a separate TCP connection was |
| 2380 | established to fetch each URL, increasing the load on HTTP servers |
| 2381 | and causing congestion on the Internet. The use of inline images and |
| 2382 | other associated data often requires a client to make multiple |
| 2383 | requests of the same server in a short amount of time. Analyses of |
| 2384 | these performance problems are available [30][27]; analysis and |
| 2385 | results from a prototype implementation are in [26]. |
| 2386 | |
| 2387 | Persistent HTTP connections have a number of advantages: |
| 2388 | |
| 2389 | o By opening and closing fewer TCP connections, CPU time is saved, |
| 2390 | and memory used for TCP protocol control blocks is also saved. |
| 2391 | o HTTP requests and responses can be pipelined on a connection. |
| 2392 | Pipelining allows a client to make multiple requests without |
| 2393 | waiting for each response, allowing a single TCP connection to be |
| 2394 | used much more efficiently, with much lower elapsed time. |
| 2395 | o Network congestion is reduced by reducing the number of packets |
| 2396 | caused by TCP opens, and by allowing TCP sufficient time to |
| 2397 | determine the congestion state of the network. |
| 2398 | o HTTP can evolve more gracefully; since errors can be reported |
| 2399 | without the penalty of closing the TCP connection. Clients using |
| 2400 | future versions of HTTP might optimistically try a new feature, but |
| 2401 | if communicating with an older server, retry with old semantics |
| 2402 | after an error is reported. |
| 2403 | |
| 2404 | HTTP implementations SHOULD implement persistent connections. |
| 2405 | |
| 2406 | |
| 2407 | |
| 2408 | |
| 2409 | |
| 2410 | Fielding, et. al. Standards Track [Page 43] |
| 2411 | \f |
| 2412 | RFC 2068 HTTP/1.1 January 1997 |
| 2413 | |
| 2414 | |
| 2415 | 8.1.2 Overall Operation |
| 2416 | |
| 2417 | A significant difference between HTTP/1.1 and earlier versions of |
| 2418 | HTTP is that persistent connections are the default behavior of any |
| 2419 | HTTP connection. That is, unless otherwise indicated, the client may |
| 2420 | assume that the server will maintain a persistent connection. |
| 2421 | |
| 2422 | Persistent connections provide a mechanism by which a client and a |
| 2423 | server can signal the close of a TCP connection. This signaling takes |
| 2424 | place using the Connection header field. Once a close has been |
| 2425 | signaled, the client MUST not send any more requests on that |
| 2426 | connection. |
| 2427 | |
| 2428 | 8.1.2.1 Negotiation |
| 2429 | |
| 2430 | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |
| 2431 | maintain a persistent connection unless a Connection header including |
| 2432 | the connection-token "close" was sent in the request. If the server |
| 2433 | chooses to close the connection immediately after sending the |
| 2434 | response, it SHOULD send a Connection header including the |
| 2435 | connection-token close. |
| 2436 | |
| 2437 | An HTTP/1.1 client MAY expect a connection to remain open, but would |
| 2438 | decide to keep it open based on whether the response from a server |
| 2439 | contains a Connection header with the connection-token close. In case |
| 2440 | the client does not want to maintain a connection for more than that |
| 2441 | request, it SHOULD send a Connection header including the |
| 2442 | connection-token close. |
| 2443 | |
| 2444 | If either the client or the server sends the close token in the |
| 2445 | Connection header, that request becomes the last one for the |
| 2446 | connection. |
| 2447 | |
| 2448 | Clients and servers SHOULD NOT assume that a persistent connection is |
| 2449 | maintained for HTTP versions less than 1.1 unless it is explicitly |
| 2450 | signaled. See section 19.7.1 for more information on backwards |
| 2451 | compatibility with HTTP/1.0 clients. |
| 2452 | |
| 2453 | In order to remain persistent, all messages on the connection must |
| 2454 | have a self-defined message length (i.e., one not defined by closure |
| 2455 | of the connection), as described in section 4.4. |
| 2456 | |
| 2457 | 8.1.2.2 Pipelining |
| 2458 | |
| 2459 | A client that supports persistent connections MAY "pipeline" its |
| 2460 | requests (i.e., send multiple requests without waiting for each |
| 2461 | response). A server MUST send its responses to those requests in the |
| 2462 | same order that the requests were received. |
| 2463 | |
| 2464 | |
| 2465 | |
| 2466 | Fielding, et. al. Standards Track [Page 44] |
| 2467 | \f |
| 2468 | RFC 2068 HTTP/1.1 January 1997 |
| 2469 | |
| 2470 | |
| 2471 | Clients which assume persistent connections and pipeline immediately |
| 2472 | after connection establishment SHOULD be prepared to retry their |
| 2473 | connection if the first pipelined attempt fails. If a client does |
| 2474 | such a retry, it MUST NOT pipeline before it knows the connection is |
| 2475 | persistent. Clients MUST also be prepared to resend their requests if |
| 2476 | the server closes the connection before sending all of the |
| 2477 | corresponding responses. |
| 2478 | |
| 2479 | 8.1.3 Proxy Servers |
| 2480 | |
| 2481 | It is especially important that proxies correctly implement the |
| 2482 | properties of the Connection header field as specified in 14.2.1. |
| 2483 | |
| 2484 | The proxy server MUST signal persistent connections separately with |
| 2485 | its clients and the origin servers (or other proxy servers) that it |
| 2486 | connects to. Each persistent connection applies to only one transport |
| 2487 | link. |
| 2488 | |
| 2489 | A proxy server MUST NOT establish a persistent connection with an |
| 2490 | HTTP/1.0 client. |
| 2491 | |
| 2492 | 8.1.4 Practical Considerations |
| 2493 | |
| 2494 | Servers will usually have some time-out value beyond which they will |
| 2495 | no longer maintain an inactive connection. Proxy servers might make |
| 2496 | this a higher value since it is likely that the client will be making |
| 2497 | more connections through the same server. The use of persistent |
| 2498 | connections places no requirements on the length of this time-out for |
| 2499 | either the client or the server. |
| 2500 | |
| 2501 | When a client or server wishes to time-out it SHOULD issue a graceful |
| 2502 | close on the transport connection. Clients and servers SHOULD both |
| 2503 | constantly watch for the other side of the transport close, and |
| 2504 | respond to it as appropriate. If a client or server does not detect |
| 2505 | the other side's close promptly it could cause unnecessary resource |
| 2506 | drain on the network. |
| 2507 | |
| 2508 | A client, server, or proxy MAY close the transport connection at any |
| 2509 | time. For example, a client MAY have started to send a new request at |
| 2510 | the same time that the server has decided to close the "idle" |
| 2511 | connection. From the server's point of view, the connection is being |
| 2512 | closed while it was idle, but from the client's point of view, a |
| 2513 | request is in progress. |
| 2514 | |
| 2515 | This means that clients, servers, and proxies MUST be able to recover |
| 2516 | from asynchronous close events. Client software SHOULD reopen the |
| 2517 | transport connection and retransmit the aborted request without user |
| 2518 | interaction so long as the request method is idempotent (see section |
| 2519 | |
| 2520 | |
| 2521 | |
| 2522 | Fielding, et. al. Standards Track [Page 45] |
| 2523 | \f |
| 2524 | RFC 2068 HTTP/1.1 January 1997 |
| 2525 | |
| 2526 | |
| 2527 | 9.1.2); other methods MUST NOT be automatically retried, although |
| 2528 | user agents MAY offer a human operator the choice of retrying the |
| 2529 | request. |
| 2530 | |
| 2531 | However, this automatic retry SHOULD NOT be repeated if the second |
| 2532 | request fails. |
| 2533 | |
| 2534 | Servers SHOULD always respond to at least one request per connection, |
| 2535 | if at all possible. Servers SHOULD NOT close a connection in the |
| 2536 | middle of transmitting a response, unless a network or client failure |
| 2537 | is suspected. |
| 2538 | |
| 2539 | Clients that use persistent connections SHOULD limit the number of |
| 2540 | simultaneous connections that they maintain to a given server. A |
| 2541 | single-user client SHOULD maintain AT MOST 2 connections with any |
| 2542 | server or proxy. A proxy SHOULD use up to 2*N connections to another |
| 2543 | server or proxy, where N is the number of simultaneously active |
| 2544 | users. These guidelines are intended to improve HTTP response times |
| 2545 | and avoid congestion of the Internet or other networks. |
| 2546 | |
| 2547 | 8.2 Message Transmission Requirements |
| 2548 | |
| 2549 | General requirements: |
| 2550 | |
| 2551 | o HTTP/1.1 servers SHOULD maintain persistent connections and use |
| 2552 | TCP's flow control mechanisms to resolve temporary overloads, |
| 2553 | rather than terminating connections with the expectation that |
| 2554 | clients will retry. The latter technique can exacerbate network |
| 2555 | congestion. |
| 2556 | |
| 2557 | o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |
| 2558 | the network connection for an error status while it is transmitting |
| 2559 | the request. If the client sees an error status, it SHOULD |
| 2560 | immediately cease transmitting the body. If the body is being sent |
| 2561 | using a "chunked" encoding (section 3.6), a zero length chunk and |
| 2562 | empty footer MAY be used to prematurely mark the end of the |
| 2563 | message. If the body was preceded by a Content-Length header, the |
| 2564 | client MUST close the connection. |
| 2565 | |
| 2566 | o An HTTP/1.1 (or later) client MUST be prepared to accept a 100 |
| 2567 | (Continue) status followed by a regular response. |
| 2568 | |
| 2569 | o An HTTP/1.1 (or later) server that receives a request from a |
| 2570 | HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue) |
| 2571 | response; it SHOULD either wait for the request to be completed |
| 2572 | normally (thus avoiding an interrupted request) or close the |
| 2573 | connection prematurely. |
| 2574 | |
| 2575 | |
| 2576 | |
| 2577 | |
| 2578 | Fielding, et. al. Standards Track [Page 46] |
| 2579 | \f |
| 2580 | RFC 2068 HTTP/1.1 January 1997 |
| 2581 | |
| 2582 | |
| 2583 | Upon receiving a method subject to these requirements from an |
| 2584 | HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either |
| 2585 | respond with 100 (Continue) status and continue to read from the |
| 2586 | input stream, or respond with an error status. If it responds with an |
| 2587 | error status, it MAY close the transport (TCP) connection or it MAY |
| 2588 | continue to read and discard the rest of the request. It MUST NOT |
| 2589 | perform the requested method if it returns an error status. |
| 2590 | |
| 2591 | Clients SHOULD remember the version number of at least the most |
| 2592 | recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or |
| 2593 | later response from the server, and it sees the connection close |
| 2594 | before receiving any status from the server, the client SHOULD retry |
| 2595 | the request without user interaction so long as the request method is |
| 2596 | idempotent (see section 9.1.2); other methods MUST NOT be |
| 2597 | automatically retried, although user agents MAY offer a human |
| 2598 | operator the choice of retrying the request.. If the client does |
| 2599 | retry the request, the client |
| 2600 | |
| 2601 | o MUST first send the request header fields, and then |
| 2602 | |
| 2603 | o MUST wait for the server to respond with either a 100 (Continue) |
| 2604 | response, in which case the client should continue, or with an |
| 2605 | error status. |
| 2606 | |
| 2607 | If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from |
| 2608 | the server, it should assume that the server implements HTTP/1.0 or |
| 2609 | older and will not use the 100 (Continue) response. If in this case |
| 2610 | the client sees the connection close before receiving any status from |
| 2611 | the server, the client SHOULD retry the request. If the client does |
| 2612 | retry the request to this HTTP/1.0 server, it should use the |
| 2613 | following "binary exponential backoff" algorithm to be assured of |
| 2614 | obtaining a reliable response: |
| 2615 | |
| 2616 | 1. Initiate a new connection to the server |
| 2617 | |
| 2618 | 2. Transmit the request-headers |
| 2619 | |
| 2620 | 3. Initialize a variable R to the estimated round-trip time to the |
| 2621 | server (e.g., based on the time it took to establish the |
| 2622 | connection), or to a constant value of 5 seconds if the round-trip |
| 2623 | time is not available. |
| 2624 | |
| 2625 | 4. Compute T = R * (2**N), where N is the number of previous retries |
| 2626 | of this request. |
| 2627 | |
| 2628 | 5. Wait either for an error response from the server, or for T seconds |
| 2629 | (whichever comes first) |
| 2630 | |
| 2631 | |
| 2632 | |
| 2633 | |
| 2634 | Fielding, et. al. Standards Track [Page 47] |
| 2635 | \f |
| 2636 | RFC 2068 HTTP/1.1 January 1997 |
| 2637 | |
| 2638 | |
| 2639 | 6. If no error response is received, after T seconds transmit the body |
| 2640 | of the request. |
| 2641 | |
| 2642 | 7. If client sees that the connection is closed prematurely, repeat |
| 2643 | from step 1 until the request is accepted, an error response is |
| 2644 | received, or the user becomes impatient and terminates the retry |
| 2645 | process. |
| 2646 | |
| 2647 | No matter what the server version, if an error status is received, |
| 2648 | the client |
| 2649 | |
| 2650 | o MUST NOT continue and |
| 2651 | |
| 2652 | o MUST close the connection if it has not completed sending the |
| 2653 | message. |
| 2654 | |
| 2655 | An HTTP/1.1 (or later) client that sees the connection close after |
| 2656 | receiving a 100 (Continue) but before receiving any other status |
| 2657 | SHOULD retry the request, and need not wait for 100 (Continue) |
| 2658 | response (but MAY do so if this simplifies the implementation). |
| 2659 | |
| 2660 | 9 Method Definitions |
| 2661 | |
| 2662 | The set of common methods for HTTP/1.1 is defined below. Although |
| 2663 | this set can be expanded, additional methods cannot be assumed to |
| 2664 | share the same semantics for separately extended clients and servers. |
| 2665 | |
| 2666 | The Host request-header field (section 14.23) MUST accompany all |
| 2667 | HTTP/1.1 requests. |
| 2668 | |
| 2669 | 9.1 Safe and Idempotent Methods |
| 2670 | |
| 2671 | 9.1.1 Safe Methods |
| 2672 | |
| 2673 | Implementers should be aware that the software represents the user in |
| 2674 | their interactions over the Internet, and should be careful to allow |
| 2675 | the user to be aware of any actions they may take which may have an |
| 2676 | unexpected significance to themselves or others. |
| 2677 | |
| 2678 | In particular, the convention has been established that the GET and |
| 2679 | HEAD methods should never have the significance of taking an action |
| 2680 | other than retrieval. These methods should be considered "safe." This |
| 2681 | allows user agents to represent other methods, such as POST, PUT and |
| 2682 | DELETE, in a special way, so that the user is made aware of the fact |
| 2683 | that a possibly unsafe action is being requested. |
| 2684 | |
| 2685 | Naturally, it is not possible to ensure that the server does not |
| 2686 | generate side-effects as a result of performing a GET request; in |
| 2687 | |
| 2688 | |
| 2689 | |
| 2690 | Fielding, et. al. Standards Track [Page 48] |
| 2691 | \f |
| 2692 | RFC 2068 HTTP/1.1 January 1997 |
| 2693 | |
| 2694 | |
| 2695 | fact, some dynamic resources consider that a feature. The important |
| 2696 | distinction here is that the user did not request the side-effects, |
| 2697 | so therefore cannot be held accountable for them. |
| 2698 | |
| 2699 | 9.1.2 Idempotent Methods |
| 2700 | |
| 2701 | Methods may also have the property of "idempotence" in that (aside |
| 2702 | from error or expiration issues) the side-effects of N > 0 identical |
| 2703 | requests is the same as for a single request. The methods GET, HEAD, |
| 2704 | PUT and DELETE share this property. |
| 2705 | |
| 2706 | 9.2 OPTIONS |
| 2707 | |
| 2708 | The OPTIONS method represents a request for information about the |
| 2709 | communication options available on the request/response chain |
| 2710 | identified by the Request-URI. This method allows the client to |
| 2711 | determine the options and/or requirements associated with a resource, |
| 2712 | or the capabilities of a server, without implying a resource action |
| 2713 | or initiating a resource retrieval. |
| 2714 | |
| 2715 | Unless the server's response is an error, the response MUST NOT |
| 2716 | include entity information other than what can be considered as |
| 2717 | communication options (e.g., Allow is appropriate, but Content-Type |
| 2718 | is not). Responses to this method are not cachable. |
| 2719 | |
| 2720 | If the Request-URI is an asterisk ("*"), the OPTIONS request is |
| 2721 | intended to apply to the server as a whole. A 200 response SHOULD |
| 2722 | include any header fields which indicate optional features |
| 2723 | implemented by the server (e.g., Public), including any extensions |
| 2724 | not defined by this specification, in addition to any applicable |
| 2725 | general or response-header fields. As described in section 5.1.2, an |
| 2726 | "OPTIONS *" request can be applied through a proxy by specifying the |
| 2727 | destination server in the Request-URI without any path information. |
| 2728 | |
| 2729 | If the Request-URI is not an asterisk, the OPTIONS request applies |
| 2730 | only to the options that are available when communicating with that |
| 2731 | resource. A 200 response SHOULD include any header fields which |
| 2732 | indicate optional features implemented by the server and applicable |
| 2733 | to that resource (e.g., Allow), including any extensions not defined |
| 2734 | by this specification, in addition to any applicable general or |
| 2735 | response-header fields. If the OPTIONS request passes through a |
| 2736 | proxy, the proxy MUST edit the response to exclude those options |
| 2737 | which apply to a proxy's capabilities and which are known to be |
| 2738 | unavailable through that proxy. |
| 2739 | |
| 2740 | |
| 2741 | |
| 2742 | |
| 2743 | |
| 2744 | |
| 2745 | |
| 2746 | Fielding, et. al. Standards Track [Page 49] |
| 2747 | \f |
| 2748 | RFC 2068 HTTP/1.1 January 1997 |
| 2749 | |
| 2750 | |
| 2751 | 9.3 GET |
| 2752 | |
| 2753 | The GET method means retrieve whatever information (in the form of an |
| 2754 | entity) is identified by the Request-URI. If the Request-URI refers |
| 2755 | to a data-producing process, it is the produced data which shall be |
| 2756 | returned as the entity in the response and not the source text of the |
| 2757 | process, unless that text happens to be the output of the process. |
| 2758 | |
| 2759 | The semantics of the GET method change to a "conditional GET" if the |
| 2760 | request message includes an If-Modified-Since, If-Unmodified-Since, |
| 2761 | If-Match, If-None-Match, or If-Range header field. A conditional GET |
| 2762 | method requests that the entity be transferred only under the |
| 2763 | circumstances described by the conditional header field(s). The |
| 2764 | conditional GET method is intended to reduce unnecessary network |
| 2765 | usage by allowing cached entities to be refreshed without requiring |
| 2766 | multiple requests or transferring data already held by the client. |
| 2767 | |
| 2768 | The semantics of the GET method change to a "partial GET" if the |
| 2769 | request message includes a Range header field. A partial GET requests |
| 2770 | that only part of the entity be transferred, as described in section |
| 2771 | 14.36. The partial GET method is intended to reduce unnecessary |
| 2772 | network usage by allowing partially-retrieved entities to be |
| 2773 | completed without transferring data already held by the client. |
| 2774 | |
| 2775 | The response to a GET request is cachable if and only if it meets the |
| 2776 | requirements for HTTP caching described in section 13. |
| 2777 | |
| 2778 | 9.4 HEAD |
| 2779 | |
| 2780 | The HEAD method is identical to GET except that the server MUST NOT |
| 2781 | return a message-body in the response. The metainformation contained |
| 2782 | in the HTTP headers in response to a HEAD request SHOULD be identical |
| 2783 | to the information sent in response to a GET request. This method can |
| 2784 | be used for obtaining metainformation about the entity implied by the |
| 2785 | request without transferring the entity-body itself. This method is |
| 2786 | often used for testing hypertext links for validity, accessibility, |
| 2787 | and recent modification. |
| 2788 | |
| 2789 | The response to a HEAD request may be cachable in the sense that the |
| 2790 | information contained in the response may be used to update a |
| 2791 | previously cached entity from that resource. If the new field values |
| 2792 | indicate that the cached entity differs from the current entity (as |
| 2793 | would be indicated by a change in Content-Length, Content-MD5, ETag |
| 2794 | or Last-Modified), then the cache MUST treat the cache entry as |
| 2795 | stale. |
| 2796 | |
| 2797 | |
| 2798 | |
| 2799 | |
| 2800 | |
| 2801 | |
| 2802 | Fielding, et. al. Standards Track [Page 50] |
| 2803 | \f |
| 2804 | RFC 2068 HTTP/1.1 January 1997 |
| 2805 | |
| 2806 | |
| 2807 | 9.5 POST |
| 2808 | |
| 2809 | The POST method is used to request that the destination server accept |
| 2810 | the entity enclosed in the request as a new subordinate of the |
| 2811 | resource identified by the Request-URI in the Request-Line. POST is |
| 2812 | designed to allow a uniform method to cover the following functions: |
| 2813 | |
| 2814 | o Annotation of existing resources; |
| 2815 | |
| 2816 | o Posting a message to a bulletin board, newsgroup, mailing list, |
| 2817 | or similar group of articles; |
| 2818 | |
| 2819 | o Providing a block of data, such as the result of submitting a |
| 2820 | form, to a data-handling process; |
| 2821 | |
| 2822 | o Extending a database through an append operation. |
| 2823 | |
| 2824 | The actual function performed by the POST method is determined by the |
| 2825 | server and is usually dependent on the Request-URI. The posted entity |
| 2826 | is subordinate to that URI in the same way that a file is subordinate |
| 2827 | to a directory containing it, a news article is subordinate to a |
| 2828 | newsgroup to which it is posted, or a record is subordinate to a |
| 2829 | database. |
| 2830 | |
| 2831 | The action performed by the POST method might not result in a |
| 2832 | resource that can be identified by a URI. In this case, either 200 |
| 2833 | (OK) or 204 (No Content) is the appropriate response status, |
| 2834 | depending on whether or not the response includes an entity that |
| 2835 | describes the result. |
| 2836 | |
| 2837 | If a resource has been created on the origin server, the response |
| 2838 | SHOULD be 201 (Created) and contain an entity which describes the |
| 2839 | status of the request and refers to the new resource, and a Location |
| 2840 | header (see section 14.30). |
| 2841 | |
| 2842 | Responses to this method are not cachable, unless the response |
| 2843 | includes appropriate Cache-Control or Expires header fields. However, |
| 2844 | the 303 (See Other) response can be used to direct the user agent to |
| 2845 | retrieve a cachable resource. |
| 2846 | |
| 2847 | POST requests must obey the message transmission requirements set out |
| 2848 | in section 8.2. |
| 2849 | |
| 2850 | |
| 2851 | |
| 2852 | |
| 2853 | |
| 2854 | |
| 2855 | |
| 2856 | |
| 2857 | |
| 2858 | Fielding, et. al. Standards Track [Page 51] |
| 2859 | \f |
| 2860 | RFC 2068 HTTP/1.1 January 1997 |
| 2861 | |
| 2862 | |
| 2863 | 9.6 PUT |
| 2864 | |
| 2865 | The PUT method requests that the enclosed entity be stored under the |
| 2866 | supplied Request-URI. If the Request-URI refers to an already |
| 2867 | existing resource, the enclosed entity SHOULD be considered as a |
| 2868 | modified version of the one residing on the origin server. If the |
| 2869 | Request-URI does not point to an existing resource, and that URI is |
| 2870 | capable of being defined as a new resource by the requesting user |
| 2871 | agent, the origin server can create the resource with that URI. If a |
| 2872 | new resource is created, the origin server MUST inform the user agent |
| 2873 | via the 201 (Created) response. If an existing resource is modified, |
| 2874 | either the 200 (OK) or 204 (No Content) response codes SHOULD be sent |
| 2875 | to indicate successful completion of the request. If the resource |
| 2876 | could not be created or modified with the Request-URI, an appropriate |
| 2877 | error response SHOULD be given that reflects the nature of the |
| 2878 | problem. The recipient of the entity MUST NOT ignore any Content-* |
| 2879 | (e.g. Content-Range) headers that it does not understand or implement |
| 2880 | and MUST return a 501 (Not Implemented) response in such cases. |
| 2881 | |
| 2882 | If the request passes through a cache and the Request-URI identifies |
| 2883 | one or more currently cached entities, those entries should be |
| 2884 | treated as stale. Responses to this method are not cachable. |
| 2885 | |
| 2886 | The fundamental difference between the POST and PUT requests is |
| 2887 | reflected in the different meaning of the Request-URI. The URI in a |
| 2888 | POST request identifies the resource that will handle the enclosed |
| 2889 | entity. That resource may be a data-accepting process, a gateway to |
| 2890 | some other protocol, or a separate entity that accepts annotations. |
| 2891 | In contrast, the URI in a PUT request identifies the entity enclosed |
| 2892 | with the request -- the user agent knows what URI is intended and the |
| 2893 | server MUST NOT attempt to apply the request to some other resource. |
| 2894 | If the server desires that the request be applied to a different URI, |
| 2895 | it MUST send a 301 (Moved Permanently) response; the user agent MAY |
| 2896 | then make its own decision regarding whether or not to redirect the |
| 2897 | request. |
| 2898 | |
| 2899 | A single resource MAY be identified by many different URIs. For |
| 2900 | example, an article may have a URI for identifying "the current |
| 2901 | version" which is separate from the URI identifying each particular |
| 2902 | version. In this case, a PUT request on a general URI may result in |
| 2903 | several other URIs being defined by the origin server. |
| 2904 | |
| 2905 | HTTP/1.1 does not define how a PUT method affects the state of an |
| 2906 | origin server. |
| 2907 | |
| 2908 | PUT requests must obey the message transmission requirements set out |
| 2909 | in section 8.2. |
| 2910 | |
| 2911 | |
| 2912 | |
| 2913 | |
| 2914 | Fielding, et. al. Standards Track [Page 52] |
| 2915 | \f |
| 2916 | RFC 2068 HTTP/1.1 January 1997 |
| 2917 | |
| 2918 | |
| 2919 | 9.7 DELETE |
| 2920 | |
| 2921 | The DELETE method requests that the origin server delete the resource |
| 2922 | identified by the Request-URI. This method MAY be overridden by human |
| 2923 | intervention (or other means) on the origin server. The client cannot |
| 2924 | be guaranteed that the operation has been carried out, even if the |
| 2925 | status code returned from the origin server indicates that the action |
| 2926 | has been completed successfully. However, the server SHOULD not |
| 2927 | indicate success unless, at the time the response is given, it |
| 2928 | intends to delete the resource or move it to an inaccessible |
| 2929 | location. |
| 2930 | |
| 2931 | A successful response SHOULD be 200 (OK) if the response includes an |
| 2932 | entity describing the status, 202 (Accepted) if the action has not |
| 2933 | yet been enacted, or 204 (No Content) if the response is OK but does |
| 2934 | not include an entity. |
| 2935 | |
| 2936 | If the request passes through a cache and the Request-URI identifies |
| 2937 | one or more currently cached entities, those entries should be |
| 2938 | treated as stale. Responses to this method are not cachable. |
| 2939 | |
| 2940 | 9.8 TRACE |
| 2941 | |
| 2942 | The TRACE method is used to invoke a remote, application-layer loop- |
| 2943 | back of the request message. The final recipient of the request |
| 2944 | SHOULD reflect the message received back to the client as the |
| 2945 | entity-body of a 200 (OK) response. The final recipient is either the |
| 2946 | origin server or the first proxy or gateway to receive a Max-Forwards |
| 2947 | value of zero (0) in the request (see section 14.31). A TRACE request |
| 2948 | MUST NOT include an entity. |
| 2949 | |
| 2950 | TRACE allows the client to see what is being received at the other |
| 2951 | end of the request chain and use that data for testing or diagnostic |
| 2952 | information. The value of the Via header field (section 14.44) is of |
| 2953 | particular interest, since it acts as a trace of the request chain. |
| 2954 | Use of the Max-Forwards header field allows the client to limit the |
| 2955 | length of the request chain, which is useful for testing a chain of |
| 2956 | proxies forwarding messages in an infinite loop. |
| 2957 | |
| 2958 | If successful, the response SHOULD contain the entire request message |
| 2959 | in the entity-body, with a Content-Type of "message/http". Responses |
| 2960 | to this method MUST NOT be cached. |
| 2961 | |
| 2962 | 10 Status Code Definitions |
| 2963 | |
| 2964 | Each Status-Code is described below, including a description of which |
| 2965 | method(s) it can follow and any metainformation required in the |
| 2966 | response. |
| 2967 | |
| 2968 | |
| 2969 | |
| 2970 | Fielding, et. al. Standards Track [Page 53] |
| 2971 | \f |
| 2972 | RFC 2068 HTTP/1.1 January 1997 |
| 2973 | |
| 2974 | |
| 2975 | 10.1 Informational 1xx |
| 2976 | |
| 2977 | This class of status code indicates a provisional response, |
| 2978 | consisting only of the Status-Line and optional headers, and is |
| 2979 | terminated by an empty line. Since HTTP/1.0 did not define any 1xx |
| 2980 | status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 |
| 2981 | client except under experimental conditions. |
| 2982 | |
| 2983 | 10.1.1 100 Continue |
| 2984 | |
| 2985 | The client may continue with its request. This interim response is |
| 2986 | used to inform the client that the initial part of the request has |
| 2987 | been received and has not yet been rejected by the server. The client |
| 2988 | SHOULD continue by sending the remainder of the request or, if the |
| 2989 | request has already been completed, ignore this response. The server |
| 2990 | MUST send a final response after the request has been completed. |
| 2991 | |
| 2992 | 10.1.2 101 Switching Protocols |
| 2993 | |
| 2994 | The server understands and is willing to comply with the client's |
| 2995 | request, via the Upgrade message header field (section 14.41), for a |
| 2996 | change in the application protocol being used on this connection. The |
| 2997 | server will switch protocols to those defined by the response's |
| 2998 | Upgrade header field immediately after the empty line which |
| 2999 | terminates the 101 response. |
| 3000 | |
| 3001 | The protocol should only be switched when it is advantageous to do |
| 3002 | so. For example, switching to a newer version of HTTP is |
| 3003 | advantageous over older versions, and switching to a real-time, |
| 3004 | synchronous protocol may be advantageous when delivering resources |
| 3005 | that use such features. |
| 3006 | |
| 3007 | 10.2 Successful 2xx |
| 3008 | |
| 3009 | This class of status code indicates that the client's request was |
| 3010 | successfully received, understood, and accepted. |
| 3011 | |
| 3012 | 10.2.1 200 OK |
| 3013 | |
| 3014 | The request has succeeded. The information returned with the response |
| 3015 | is dependent on the method used in the request, for example: |
| 3016 | |
| 3017 | GET an entity corresponding to the requested resource is sent in the |
| 3018 | response; |
| 3019 | |
| 3020 | HEAD the entity-header fields corresponding to the requested resource |
| 3021 | are sent in the response without any message-body; |
| 3022 | |
| 3023 | |
| 3024 | |
| 3025 | |
| 3026 | Fielding, et. al. Standards Track [Page 54] |
| 3027 | \f |
| 3028 | RFC 2068 HTTP/1.1 January 1997 |
| 3029 | |
| 3030 | |
| 3031 | POST an entity describing or containing the result of the action; |
| 3032 | |
| 3033 | TRACE an entity containing the request message as received by the end |
| 3034 | server. |
| 3035 | |
| 3036 | 10.2.2 201 Created |
| 3037 | |
| 3038 | The request has been fulfilled and resulted in a new resource being |
| 3039 | created. The newly created resource can be referenced by the URI(s) |
| 3040 | returned in the entity of the response, with the most specific URL |
| 3041 | for the resource given by a Location header field. The origin server |
| 3042 | MUST create the resource before returning the 201 status code. If the |
| 3043 | action cannot be carried out immediately, the server should respond |
| 3044 | with 202 (Accepted) response instead. |
| 3045 | |
| 3046 | 10.2.3 202 Accepted |
| 3047 | |
| 3048 | The request has been accepted for processing, but the processing has |
| 3049 | not been completed. The request MAY or MAY NOT eventually be acted |
| 3050 | upon, as it MAY be disallowed when processing actually takes place. |
| 3051 | There is no facility for re-sending a status code from an |
| 3052 | asynchronous operation such as this. |
| 3053 | |
| 3054 | The 202 response is intentionally non-committal. Its purpose is to |
| 3055 | allow a server to accept a request for some other process (perhaps a |
| 3056 | batch-oriented process that is only run once per day) without |
| 3057 | requiring that the user agent's connection to the server persist |
| 3058 | until the process is completed. The entity returned with this |
| 3059 | response SHOULD include an indication of the request's current status |
| 3060 | and either a pointer to a status monitor or some estimate of when the |
| 3061 | user can expect the request to be fulfilled. |
| 3062 | |
| 3063 | 10.2.4 203 Non-Authoritative Information |
| 3064 | |
| 3065 | The returned metainformation in the entity-header is not the |
| 3066 | definitive set as available from the origin server, but is gathered |
| 3067 | from a local or a third-party copy. The set presented MAY be a subset |
| 3068 | or superset of the original version. For example, including local |
| 3069 | annotation information about the resource MAY result in a superset of |
| 3070 | the metainformation known by the origin server. Use of this response |
| 3071 | code is not required and is only appropriate when the response would |
| 3072 | otherwise be 200 (OK). |
| 3073 | |
| 3074 | 10.2.5 204 No Content |
| 3075 | |
| 3076 | The server has fulfilled the request but there is no new information |
| 3077 | to send back. If the client is a user agent, it SHOULD NOT change its |
| 3078 | document view from that which caused the request to be sent. This |
| 3079 | |
| 3080 | |
| 3081 | |
| 3082 | Fielding, et. al. Standards Track [Page 55] |
| 3083 | \f |
| 3084 | RFC 2068 HTTP/1.1 January 1997 |
| 3085 | |
| 3086 | |
| 3087 | response is primarily intended to allow input for actions to take |
| 3088 | place without causing a change to the user agent's active document |
| 3089 | view. The response MAY include new metainformation in the form of |
| 3090 | entity-headers, which SHOULD apply to the document currently in the |
| 3091 | user agent's active view. |
| 3092 | |
| 3093 | The 204 response MUST NOT include a message-body, and thus is always |
| 3094 | terminated by the first empty line after the header fields. |
| 3095 | |
| 3096 | 10.2.6 205 Reset Content |
| 3097 | |
| 3098 | The server has fulfilled the request and the user agent SHOULD reset |
| 3099 | the document view which caused the request to be sent. This response |
| 3100 | is primarily intended to allow input for actions to take place via |
| 3101 | user input, followed by a clearing of the form in which the input is |
| 3102 | given so that the user can easily initiate another input action. The |
| 3103 | response MUST NOT include an entity. |
| 3104 | |
| 3105 | 10.2.7 206 Partial Content |
| 3106 | |
| 3107 | The server has fulfilled the partial GET request for the resource. |
| 3108 | The request must have included a Range header field (section 14.36) |
| 3109 | indicating the desired range. The response MUST include either a |
| 3110 | Content-Range header field (section 14.17) indicating the range |
| 3111 | included with this response, or a multipart/byteranges Content-Type |
| 3112 | including Content-Range fields for each part. If multipart/byteranges |
| 3113 | is not used, the Content-Length header field in the response MUST |
| 3114 | match the actual number of OCTETs transmitted in the message-body. |
| 3115 | |
| 3116 | A cache that does not support the Range and Content-Range headers |
| 3117 | MUST NOT cache 206 (Partial) responses. |
| 3118 | |
| 3119 | 10.3 Redirection 3xx |
| 3120 | |
| 3121 | This class of status code indicates that further action needs to be |
| 3122 | taken by the user agent in order to fulfill the request. The action |
| 3123 | required MAY be carried out by the user agent without interaction |
| 3124 | with the user if and only if the method used in the second request is |
| 3125 | GET or HEAD. A user agent SHOULD NOT automatically redirect a request |
| 3126 | more than 5 times, since such redirections usually indicate an |
| 3127 | infinite loop. |
| 3128 | |
| 3129 | |
| 3130 | |
| 3131 | |
| 3132 | |
| 3133 | |
| 3134 | |
| 3135 | |
| 3136 | |
| 3137 | |
| 3138 | Fielding, et. al. Standards Track [Page 56] |
| 3139 | \f |
| 3140 | RFC 2068 HTTP/1.1 January 1997 |
| 3141 | |
| 3142 | |
| 3143 | 10.3.1 300 Multiple Choices |
| 3144 | |
| 3145 | The requested resource corresponds to any one of a set of |
| 3146 | representations, each with its own specific location, and agent- |
| 3147 | driven negotiation information (section 12) is being provided so that |
| 3148 | the user (or user agent) can select a preferred representation and |
| 3149 | redirect its request to that location. |
| 3150 | |
| 3151 | Unless it was a HEAD request, the response SHOULD include an entity |
| 3152 | containing a list of resource characteristics and location(s) from |
| 3153 | which the user or user agent can choose the one most appropriate. The |
| 3154 | entity format is specified by the media type given in the Content- |
| 3155 | Type header field. Depending upon the format and the capabilities of |
| 3156 | the user agent, selection of the most appropriate choice may be |
| 3157 | performed automatically. However, this specification does not define |
| 3158 | any standard for such automatic selection. |
| 3159 | |
| 3160 | If the server has a preferred choice of representation, it SHOULD |
| 3161 | include the specific URL for that representation in the Location |
| 3162 | field; user agents MAY use the Location field value for automatic |
| 3163 | redirection. This response is cachable unless indicated otherwise. |
| 3164 | |
| 3165 | 10.3.2 301 Moved Permanently |
| 3166 | |
| 3167 | The requested resource has been assigned a new permanent URI and any |
| 3168 | future references to this resource SHOULD be done using one of the |
| 3169 | returned URIs. Clients with link editing capabilities SHOULD |
| 3170 | automatically re-link references to the Request-URI to one or more of |
| 3171 | the new references returned by the server, where possible. This |
| 3172 | response is cachable unless indicated otherwise. |
| 3173 | |
| 3174 | If the new URI is a location, its URL SHOULD be given by the Location |
| 3175 | field in the response. Unless the request method was HEAD, the entity |
| 3176 | of the response SHOULD contain a short hypertext note with a |
| 3177 | hyperlink to the new URI(s). |
| 3178 | |
| 3179 | If the 301 status code is received in response to a request other |
| 3180 | than GET or HEAD, the user agent MUST NOT automatically redirect the |
| 3181 | request unless it can be confirmed by the user, since this might |
| 3182 | change the conditions under which the request was issued. |
| 3183 | |
| 3184 | Note: When automatically redirecting a POST request after receiving |
| 3185 | a 301 status code, some existing HTTP/1.0 user agents will |
| 3186 | erroneously change it into a GET request. |
| 3187 | |
| 3188 | |
| 3189 | |
| 3190 | |
| 3191 | |
| 3192 | |
| 3193 | |
| 3194 | Fielding, et. al. Standards Track [Page 57] |
| 3195 | \f |
| 3196 | RFC 2068 HTTP/1.1 January 1997 |
| 3197 | |
| 3198 | |
| 3199 | 10.3.3 302 Moved Temporarily |
| 3200 | |
| 3201 | The requested resource resides temporarily under a different URI. |
| 3202 | Since the redirection may be altered on occasion, the client SHOULD |
| 3203 | continue to use the Request-URI for future requests. This response is |
| 3204 | only cachable if indicated by a Cache-Control or Expires header |
| 3205 | field. |
| 3206 | |
| 3207 | If the new URI is a location, its URL SHOULD be given by the Location |
| 3208 | field in the response. Unless the request method was HEAD, the entity |
| 3209 | of the response SHOULD contain a short hypertext note with a |
| 3210 | hyperlink to the new URI(s). |
| 3211 | |
| 3212 | If the 302 status code is received in response to a request other |
| 3213 | than GET or HEAD, the user agent MUST NOT automatically redirect the |
| 3214 | request unless it can be confirmed by the user, since this might |
| 3215 | change the conditions under which the request was issued. |
| 3216 | |
| 3217 | Note: When automatically redirecting a POST request after receiving |
| 3218 | a 302 status code, some existing HTTP/1.0 user agents will |
| 3219 | erroneously change it into a GET request. |
| 3220 | |
| 3221 | 10.3.4 303 See Other |
| 3222 | |
| 3223 | The response to the request can be found under a different URI and |
| 3224 | SHOULD be retrieved using a GET method on that resource. This method |
| 3225 | exists primarily to allow the output of a POST-activated script to |
| 3226 | redirect the user agent to a selected resource. The new URI is not a |
| 3227 | substitute reference for the originally requested resource. The 303 |
| 3228 | response is not cachable, but the response to the second (redirected) |
| 3229 | request MAY be cachable. |
| 3230 | |
| 3231 | If the new URI is a location, its URL SHOULD be given by the Location |
| 3232 | field in the response. Unless the request method was HEAD, the entity |
| 3233 | of the response SHOULD contain a short hypertext note with a |
| 3234 | hyperlink to the new URI(s). |
| 3235 | |
| 3236 | 10.3.5 304 Not Modified |
| 3237 | |
| 3238 | If the client has performed a conditional GET request and access is |
| 3239 | allowed, but the document has not been modified, the server SHOULD |
| 3240 | respond with this status code. The response MUST NOT contain a |
| 3241 | message-body. |
| 3242 | |
| 3243 | |
| 3244 | |
| 3245 | |
| 3246 | |
| 3247 | |
| 3248 | |
| 3249 | |
| 3250 | Fielding, et. al. Standards Track [Page 58] |
| 3251 | \f |
| 3252 | RFC 2068 HTTP/1.1 January 1997 |
| 3253 | |
| 3254 | |
| 3255 | The response MUST include the following header fields: |
| 3256 | |
| 3257 | o Date |
| 3258 | |
| 3259 | o ETag and/or Content-Location, if the header would have been sent in |
| 3260 | a 200 response to the same request |
| 3261 | |
| 3262 | o Expires, Cache-Control, and/or Vary, if the field-value might |
| 3263 | differ from that sent in any previous response for the same variant |
| 3264 | |
| 3265 | If the conditional GET used a strong cache validator (see section |
| 3266 | 13.3.3), the response SHOULD NOT include other entity-headers. |
| 3267 | Otherwise (i.e., the conditional GET used a weak validator), the |
| 3268 | response MUST NOT include other entity-headers; this prevents |
| 3269 | inconsistencies between cached entity-bodies and updated headers. |
| 3270 | |
| 3271 | If a 304 response indicates an entity not currently cached, then the |
| 3272 | cache MUST disregard the response and repeat the request without the |
| 3273 | conditional. |
| 3274 | |
| 3275 | If a cache uses a received 304 response to update a cache entry, the |
| 3276 | cache MUST update the entry to reflect any new field values given in |
| 3277 | the response. |
| 3278 | |
| 3279 | The 304 response MUST NOT include a message-body, and thus is always |
| 3280 | terminated by the first empty line after the header fields. |
| 3281 | |
| 3282 | 10.3.6 305 Use Proxy |
| 3283 | |
| 3284 | The requested resource MUST be accessed through the proxy given by |
| 3285 | the Location field. The Location field gives the URL of the proxy. |
| 3286 | The recipient is expected to repeat the request via the proxy. |
| 3287 | |
| 3288 | 10.4 Client Error 4xx |
| 3289 | |
| 3290 | The 4xx class of status code is intended for cases in which the |
| 3291 | client seems to have erred. Except when responding to a HEAD request, |
| 3292 | the server SHOULD include an entity containing an explanation of the |
| 3293 | error situation, and whether it is a temporary or permanent |
| 3294 | condition. These status codes are applicable to any request method. |
| 3295 | User agents SHOULD display any included entity to the user. |
| 3296 | |
| 3297 | Note: If the client is sending data, a server implementation using |
| 3298 | TCP should be careful to ensure that the client acknowledges |
| 3299 | receipt of the packet(s) containing the response, before the server |
| 3300 | closes the input connection. If the client continues sending data |
| 3301 | to the server after the close, the server's TCP stack will send a |
| 3302 | reset packet to the client, which may erase the client's |
| 3303 | |
| 3304 | |
| 3305 | |
| 3306 | Fielding, et. al. Standards Track [Page 59] |
| 3307 | \f |
| 3308 | RFC 2068 HTTP/1.1 January 1997 |
| 3309 | |
| 3310 | |
| 3311 | unacknowledged input buffers before they can be read and |
| 3312 | interpreted by the HTTP application. |
| 3313 | |
| 3314 | 10.4.1 400 Bad Request |
| 3315 | |
| 3316 | The request could not be understood by the server due to malformed |
| 3317 | syntax. The client SHOULD NOT repeat the request without |
| 3318 | modifications. |
| 3319 | |
| 3320 | 10.4.2 401 Unauthorized |
| 3321 | |
| 3322 | The request requires user authentication. The response MUST include a |
| 3323 | WWW-Authenticate header field (section 14.46) containing a challenge |
| 3324 | applicable to the requested resource. The client MAY repeat the |
| 3325 | request with a suitable Authorization header field (section 14.8). If |
| 3326 | the request already included Authorization credentials, then the 401 |
| 3327 | response indicates that authorization has been refused for those |
| 3328 | credentials. If the 401 response contains the same challenge as the |
| 3329 | prior response, and the user agent has already attempted |
| 3330 | authentication at least once, then the user SHOULD be presented the |
| 3331 | entity that was given in the response, since that entity MAY include |
| 3332 | relevant diagnostic information. HTTP access authentication is |
| 3333 | explained in section 11. |
| 3334 | |
| 3335 | 10.4.3 402 Payment Required |
| 3336 | |
| 3337 | This code is reserved for future use. |
| 3338 | |
| 3339 | 10.4.4 403 Forbidden |
| 3340 | |
| 3341 | The server understood the request, but is refusing to fulfill it. |
| 3342 | Authorization will not help and the request SHOULD NOT be repeated. |
| 3343 | If the request method was not HEAD and the server wishes to make |
| 3344 | public why the request has not been fulfilled, it SHOULD describe the |
| 3345 | reason for the refusal in the entity. This status code is commonly |
| 3346 | used when the server does not wish to reveal exactly why the request |
| 3347 | has been refused, or when no other response is applicable. |
| 3348 | |
| 3349 | 10.4.5 404 Not Found |
| 3350 | |
| 3351 | The server has not found anything matching the Request-URI. No |
| 3352 | indication is given of whether the condition is temporary or |
| 3353 | permanent. |
| 3354 | |
| 3355 | |
| 3356 | |
| 3357 | |
| 3358 | |
| 3359 | |
| 3360 | |
| 3361 | |
| 3362 | Fielding, et. al. Standards Track [Page 60] |
| 3363 | \f |
| 3364 | RFC 2068 HTTP/1.1 January 1997 |
| 3365 | |
| 3366 | |
| 3367 | If the server does not wish to make this information available to the |
| 3368 | client, the status code 403 (Forbidden) can be used instead. The 410 |
| 3369 | (Gone) status code SHOULD be used if the server knows, through some |
| 3370 | internally configurable mechanism, that an old resource is |
| 3371 | permanently unavailable and has no forwarding address. |
| 3372 | |
| 3373 | 10.4.6 405 Method Not Allowed |
| 3374 | |
| 3375 | The method specified in the Request-Line is not allowed for the |
| 3376 | resource identified by the Request-URI. The response MUST include an |
| 3377 | Allow header containing a list of valid methods for the requested |
| 3378 | resource. |
| 3379 | |
| 3380 | 10.4.7 406 Not Acceptable |
| 3381 | |
| 3382 | The resource identified by the request is only capable of generating |
| 3383 | response entities which have content characteristics not acceptable |
| 3384 | according to the accept headers sent in the request. |
| 3385 | |
| 3386 | Unless it was a HEAD request, the response SHOULD include an entity |
| 3387 | containing a list of available entity characteristics and location(s) |
| 3388 | from which the user or user agent can choose the one most |
| 3389 | appropriate. The entity format is specified by the media type given |
| 3390 | in the Content-Type header field. Depending upon the format and the |
| 3391 | capabilities of the user agent, selection of the most appropriate |
| 3392 | choice may be performed automatically. However, this specification |
| 3393 | does not define any standard for such automatic selection. |
| 3394 | |
| 3395 | Note: HTTP/1.1 servers are allowed to return responses which are |
| 3396 | not acceptable according to the accept headers sent in the request. |
| 3397 | In some cases, this may even be preferable to sending a 406 |
| 3398 | response. User agents are encouraged to inspect the headers of an |
| 3399 | incoming response to determine if it is acceptable. If the response |
| 3400 | could be unacceptable, a user agent SHOULD temporarily stop receipt |
| 3401 | of more data and query the user for a decision on further actions. |
| 3402 | |
| 3403 | 10.4.8 407 Proxy Authentication Required |
| 3404 | |
| 3405 | This code is similar to 401 (Unauthorized), but indicates that the |
| 3406 | client MUST first authenticate itself with the proxy. The proxy MUST |
| 3407 | return a Proxy-Authenticate header field (section 14.33) containing a |
| 3408 | challenge applicable to the proxy for the requested resource. The |
| 3409 | client MAY repeat the request with a suitable Proxy-Authorization |
| 3410 | header field (section 14.34). HTTP access authentication is explained |
| 3411 | in section 11. |
| 3412 | |
| 3413 | |
| 3414 | |
| 3415 | |
| 3416 | |
| 3417 | |
| 3418 | Fielding, et. al. Standards Track [Page 61] |
| 3419 | \f |
| 3420 | RFC 2068 HTTP/1.1 January 1997 |
| 3421 | |
| 3422 | |
| 3423 | 10.4.9 408 Request Timeout |
| 3424 | |
| 3425 | The client did not produce a request within the time that the server |
| 3426 | was prepared to wait. The client MAY repeat the request without |
| 3427 | modifications at any later time. |
| 3428 | |
| 3429 | 10.4.10 409 Conflict |
| 3430 | |
| 3431 | The request could not be completed due to a conflict with the current |
| 3432 | state of the resource. This code is only allowed in situations where |
| 3433 | it is expected that the user might be able to resolve the conflict |
| 3434 | and resubmit the request. The response body SHOULD include enough |
| 3435 | information for the user to recognize the source of the conflict. |
| 3436 | Ideally, the response entity would include enough information for the |
| 3437 | user or user agent to fix the problem; however, that may not be |
| 3438 | possible and is not required. |
| 3439 | |
| 3440 | Conflicts are most likely to occur in response to a PUT request. If |
| 3441 | versioning is being used and the entity being PUT includes changes to |
| 3442 | a resource which conflict with those made by an earlier (third-party) |
| 3443 | request, the server MAY use the 409 response to indicate that it |
| 3444 | can't complete the request. In this case, the response entity SHOULD |
| 3445 | contain a list of the differences between the two versions in a |
| 3446 | format defined by the response Content-Type. |
| 3447 | |
| 3448 | 10.4.11 410 Gone |
| 3449 | |
| 3450 | The requested resource is no longer available at the server and no |
| 3451 | forwarding address is known. This condition SHOULD be considered |
| 3452 | permanent. Clients with link editing capabilities SHOULD delete |
| 3453 | references to the Request-URI after user approval. If the server does |
| 3454 | not know, or has no facility to determine, whether or not the |
| 3455 | condition is permanent, the status code 404 (Not Found) SHOULD be |
| 3456 | used instead. This response is cachable unless indicated otherwise. |
| 3457 | |
| 3458 | The 410 response is primarily intended to assist the task of web |
| 3459 | maintenance by notifying the recipient that the resource is |
| 3460 | intentionally unavailable and that the server owners desire that |
| 3461 | remote links to that resource be removed. Such an event is common for |
| 3462 | limited-time, promotional services and for resources belonging to |
| 3463 | individuals no longer working at the server's site. It is not |
| 3464 | necessary to mark all permanently unavailable resources as "gone" or |
| 3465 | to keep the mark for any length of time -- that is left to the |
| 3466 | discretion of the server owner. |
| 3467 | |
| 3468 | |
| 3469 | |
| 3470 | |
| 3471 | |
| 3472 | |
| 3473 | |
| 3474 | Fielding, et. al. Standards Track [Page 62] |
| 3475 | \f |
| 3476 | RFC 2068 HTTP/1.1 January 1997 |
| 3477 | |
| 3478 | |
| 3479 | 10.4.12 411 Length Required |
| 3480 | |
| 3481 | The server refuses to accept the request without a defined Content- |
| 3482 | Length. The client MAY repeat the request if it adds a valid |
| 3483 | Content-Length header field containing the length of the message-body |
| 3484 | in the request message. |
| 3485 | |
| 3486 | 10.4.13 412 Precondition Failed |
| 3487 | |
| 3488 | The precondition given in one or more of the request-header fields |
| 3489 | evaluated to false when it was tested on the server. This response |
| 3490 | code allows the client to place preconditions on the current resource |
| 3491 | metainformation (header field data) and thus prevent the requested |
| 3492 | method from being applied to a resource other than the one intended. |
| 3493 | |
| 3494 | 10.4.14 413 Request Entity Too Large |
| 3495 | |
| 3496 | The server is refusing to process a request because the request |
| 3497 | entity is larger than the server is willing or able to process. The |
| 3498 | server may close the connection to prevent the client from continuing |
| 3499 | the request. |
| 3500 | |
| 3501 | If the condition is temporary, the server SHOULD include a Retry- |
| 3502 | After header field to indicate that it is temporary and after what |
| 3503 | time the client may try again. |
| 3504 | |
| 3505 | 10.4.15 414 Request-URI Too Long |
| 3506 | |
| 3507 | The server is refusing to service the request because the Request-URI |
| 3508 | is longer than the server is willing to interpret. This rare |
| 3509 | condition is only likely to occur when a client has improperly |
| 3510 | converted a POST request to a GET request with long query |
| 3511 | information, when the client has descended into a URL "black hole" of |
| 3512 | redirection (e.g., a redirected URL prefix that points to a suffix of |
| 3513 | itself), or when the server is under attack by a client attempting to |
| 3514 | exploit security holes present in some servers using fixed-length |
| 3515 | buffers for reading or manipulating the Request-URI. |
| 3516 | |
| 3517 | 10.4.16 415 Unsupported Media Type |
| 3518 | |
| 3519 | The server is refusing to service the request because the entity of |
| 3520 | the request is in a format not supported by the requested resource |
| 3521 | for the requested method. |
| 3522 | |
| 3523 | |
| 3524 | |
| 3525 | |
| 3526 | |
| 3527 | |
| 3528 | |
| 3529 | |
| 3530 | Fielding, et. al. Standards Track [Page 63] |
| 3531 | \f |
| 3532 | RFC 2068 HTTP/1.1 January 1997 |
| 3533 | |
| 3534 | |
| 3535 | 10.5 Server Error 5xx |
| 3536 | |
| 3537 | Response status codes beginning with the digit "5" indicate cases in |
| 3538 | which the server is aware that it has erred or is incapable of |
| 3539 | performing the request. Except when responding to a HEAD request, the |
| 3540 | server SHOULD include an entity containing an explanation of the |
| 3541 | error situation, and whether it is a temporary or permanent |
| 3542 | condition. User agents SHOULD display any included entity to the |
| 3543 | user. These response codes are applicable to any request method. |
| 3544 | |
| 3545 | 10.5.1 500 Internal Server Error |
| 3546 | |
| 3547 | The server encountered an unexpected condition which prevented it |
| 3548 | from fulfilling the request. |
| 3549 | |
| 3550 | 10.5.2 501 Not Implemented |
| 3551 | |
| 3552 | The server does not support the functionality required to fulfill the |
| 3553 | request. This is the appropriate response when the server does not |
| 3554 | recognize the request method and is not capable of supporting it for |
| 3555 | any resource. |
| 3556 | |
| 3557 | 10.5.3 502 Bad Gateway |
| 3558 | |
| 3559 | The server, while acting as a gateway or proxy, received an invalid |
| 3560 | response from the upstream server it accessed in attempting to |
| 3561 | fulfill the request. |
| 3562 | |
| 3563 | 10.5.4 503 Service Unavailable |
| 3564 | |
| 3565 | The server is currently unable to handle the request due to a |
| 3566 | temporary overloading or maintenance of the server. The implication |
| 3567 | is that this is a temporary condition which will be alleviated after |
| 3568 | some delay. If known, the length of the delay may be indicated in a |
| 3569 | Retry-After header. If no Retry-After is given, the client SHOULD |
| 3570 | handle the response as it would for a 500 response. |
| 3571 | |
| 3572 | Note: The existence of the 503 status code does not imply that a |
| 3573 | server must use it when becoming overloaded. Some servers may wish |
| 3574 | to simply refuse the connection. |
| 3575 | |
| 3576 | 10.5.5 504 Gateway Timeout |
| 3577 | |
| 3578 | The server, while acting as a gateway or proxy, did not receive a |
| 3579 | timely response from the upstream server it accessed in attempting to |
| 3580 | complete the request. |
| 3581 | |
| 3582 | |
| 3583 | |
| 3584 | |
| 3585 | |
| 3586 | Fielding, et. al. Standards Track [Page 64] |
| 3587 | \f |
| 3588 | RFC 2068 HTTP/1.1 January 1997 |
| 3589 | |
| 3590 | |
| 3591 | 10.5.6 505 HTTP Version Not Supported |
| 3592 | |
| 3593 | The server does not support, or refuses to support, the HTTP protocol |
| 3594 | version that was used in the request message. The server is |
| 3595 | indicating that it is unable or unwilling to complete the request |
| 3596 | using the same major version as the client, as described in section |
| 3597 | 3.1, other than with this error message. The response SHOULD contain |
| 3598 | an entity describing why that version is not supported and what other |
| 3599 | protocols are supported by that server. |
| 3600 | |
| 3601 | 11 Access Authentication |
| 3602 | |
| 3603 | HTTP provides a simple challenge-response authentication mechanism |
| 3604 | which MAY be used by a server to challenge a client request and by a |
| 3605 | client to provide authentication information. It uses an extensible, |
| 3606 | case-insensitive token to identify the authentication scheme, |
| 3607 | followed by a comma-separated list of attribute-value pairs which |
| 3608 | carry the parameters necessary for achieving authentication via that |
| 3609 | scheme. |
| 3610 | |
| 3611 | auth-scheme = token |
| 3612 | |
| 3613 | auth-param = token "=" quoted-string |
| 3614 | |
| 3615 | The 401 (Unauthorized) response message is used by an origin server |
| 3616 | to challenge the authorization of a user agent. This response MUST |
| 3617 | include a WWW-Authenticate header field containing at least one |
| 3618 | challenge applicable to the requested resource. |
| 3619 | |
| 3620 | challenge = auth-scheme 1*SP realm *( "," auth-param ) |
| 3621 | |
| 3622 | realm = "realm" "=" realm-value |
| 3623 | realm-value = quoted-string |
| 3624 | |
| 3625 | The realm attribute (case-insensitive) is required for all |
| 3626 | authentication schemes which issue a challenge. The realm value |
| 3627 | (case-sensitive), in combination with the canonical root URL (see |
| 3628 | section 5.1.2) of the server being accessed, defines the protection |
| 3629 | space. These realms allow the protected resources on a server to be |
| 3630 | partitioned into a set of protection spaces, each with its own |
| 3631 | authentication scheme and/or authorization database. The realm value |
| 3632 | is a string, generally assigned by the origin server, which may have |
| 3633 | additional semantics specific to the authentication scheme. |
| 3634 | |
| 3635 | A user agent that wishes to authenticate itself with a server-- |
| 3636 | usually, but not necessarily, after receiving a 401 or 411 response- |
| 3637 | -MAY do so by including an Authorization header field with the |
| 3638 | request. The Authorization field value consists of credentials |
| 3639 | |
| 3640 | |
| 3641 | |
| 3642 | Fielding, et. al. Standards Track [Page 65] |
| 3643 | \f |
| 3644 | RFC 2068 HTTP/1.1 January 1997 |
| 3645 | |
| 3646 | |
| 3647 | containing the authentication information of the user agent for the |
| 3648 | realm of the resource being requested. |
| 3649 | |
| 3650 | credentials = basic-credentials |
| 3651 | | auth-scheme #auth-param |
| 3652 | |
| 3653 | The domain over which credentials can be automatically applied by a |
| 3654 | user agent is determined by the protection space. If a prior request |
| 3655 | has been authorized, the same credentials MAY be reused for all other |
| 3656 | requests within that protection space for a period of time determined |
| 3657 | by the authentication scheme, parameters, and/or user preference. |
| 3658 | Unless otherwise defined by the authentication scheme, a single |
| 3659 | protection space cannot extend outside the scope of its server. |
| 3660 | |
| 3661 | If the server does not wish to accept the credentials sent with a |
| 3662 | request, it SHOULD return a 401 (Unauthorized) response. The response |
| 3663 | MUST include a WWW-Authenticate header field containing the (possibly |
| 3664 | new) challenge applicable to the requested resource and an entity |
| 3665 | explaining the refusal. |
| 3666 | |
| 3667 | The HTTP protocol does not restrict applications to this simple |
| 3668 | challenge-response mechanism for access authentication. Additional |
| 3669 | mechanisms MAY be used, such as encryption at the transport level or |
| 3670 | via message encapsulation, and with additional header fields |
| 3671 | specifying authentication information. However, these additional |
| 3672 | mechanisms are not defined by this specification. |
| 3673 | |
| 3674 | Proxies MUST be completely transparent regarding user agent |
| 3675 | authentication. That is, they MUST forward the WWW-Authenticate and |
| 3676 | Authorization headers untouched, and follow the rules found in |
| 3677 | section 14.8. |
| 3678 | |
| 3679 | HTTP/1.1 allows a client to pass authentication information to and |
| 3680 | from a proxy via the Proxy-Authenticate and Proxy-Authorization |
| 3681 | headers. |
| 3682 | |
| 3683 | 11.1 Basic Authentication Scheme |
| 3684 | |
| 3685 | The "basic" authentication scheme is based on the model that the user |
| 3686 | agent must authenticate itself with a user-ID and a password for each |
| 3687 | realm. The realm value should be considered an opaque string which |
| 3688 | can only be compared for equality with other realms on that server. |
| 3689 | The server will service the request only if it can validate the |
| 3690 | user-ID and password for the protection space of the Request-URI. |
| 3691 | There are no optional authentication parameters. |
| 3692 | |
| 3693 | |
| 3694 | |
| 3695 | |
| 3696 | |
| 3697 | |
| 3698 | Fielding, et. al. Standards Track [Page 66] |
| 3699 | \f |
| 3700 | RFC 2068 HTTP/1.1 January 1997 |
| 3701 | |
| 3702 | |
| 3703 | Upon receipt of an unauthorized request for a URI within the |
| 3704 | protection space, the server MAY respond with a challenge like the |
| 3705 | following: |
| 3706 | |
| 3707 | WWW-Authenticate: Basic realm="WallyWorld" |
| 3708 | |
| 3709 | where "WallyWorld" is the string assigned by the server to identify |
| 3710 | the protection space of the Request-URI. |
| 3711 | |
| 3712 | To receive authorization, the client sends the userid and password, |
| 3713 | separated by a single colon (":") character, within a base64 encoded |
| 3714 | string in the credentials. |
| 3715 | |
| 3716 | basic-credentials = "Basic" SP basic-cookie |
| 3717 | |
| 3718 | basic-cookie = <base64 [7] encoding of user-pass, |
| 3719 | except not limited to 76 char/line> |
| 3720 | |
| 3721 | user-pass = userid ":" password |
| 3722 | |
| 3723 | userid = *<TEXT excluding ":"> |
| 3724 | |
| 3725 | password = *TEXT |
| 3726 | |
| 3727 | Userids might be case sensitive. |
| 3728 | |
| 3729 | If the user agent wishes to send the userid "Aladdin" and password |
| 3730 | "open sesame", it would use the following header field: |
| 3731 | |
| 3732 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| 3733 | |
| 3734 | See section 15 for security considerations associated with Basic |
| 3735 | authentication. |
| 3736 | |
| 3737 | 11.2 Digest Authentication Scheme |
| 3738 | |
| 3739 | A digest authentication for HTTP is specified in RFC 2069 [32]. |
| 3740 | |
| 3741 | 12 Content Negotiation |
| 3742 | |
| 3743 | Most HTTP responses include an entity which contains information for |
| 3744 | interpretation by a human user. Naturally, it is desirable to supply |
| 3745 | the user with the "best available" entity corresponding to the |
| 3746 | request. Unfortunately for servers and caches, not all users have |
| 3747 | the same preferences for what is "best," and not all user agents are |
| 3748 | equally capable of rendering all entity types. For that reason, HTTP |
| 3749 | has provisions for several mechanisms for "content negotiation" -- |
| 3750 | the process of selecting the best representation for a given response |
| 3751 | |
| 3752 | |
| 3753 | |
| 3754 | Fielding, et. al. Standards Track [Page 67] |
| 3755 | \f |
| 3756 | RFC 2068 HTTP/1.1 January 1997 |
| 3757 | |
| 3758 | |
| 3759 | when there are multiple representations available. |
| 3760 | |
| 3761 | Note: This is not called "format negotiation" because the alternate |
| 3762 | representations may be of the same media type, but use different |
| 3763 | capabilities of that type, be in different languages, etc. |
| 3764 | |
| 3765 | Any response containing an entity-body MAY be subject to negotiation, |
| 3766 | including error responses. |
| 3767 | |
| 3768 | There are two kinds of content negotiation which are possible in |
| 3769 | HTTP: server-driven and agent-driven negotiation. These two kinds of |
| 3770 | negotiation are orthogonal and thus may be used separately or in |
| 3771 | combination. One method of combination, referred to as transparent |
| 3772 | negotiation, occurs when a cache uses the agent-driven negotiation |
| 3773 | information provided by the origin server in order to provide |
| 3774 | server-driven negotiation for subsequent requests. |
| 3775 | |
| 3776 | 12.1 Server-driven Negotiation |
| 3777 | |
| 3778 | If the selection of the best representation for a response is made by |
| 3779 | an algorithm located at the server, it is called server-driven |
| 3780 | negotiation. Selection is based on the available representations of |
| 3781 | the response (the dimensions over which it can vary; e.g. language, |
| 3782 | content-coding, etc.) and the contents of particular header fields in |
| 3783 | the request message or on other information pertaining to the request |
| 3784 | (such as the network address of the client). |
| 3785 | |
| 3786 | Server-driven negotiation is advantageous when the algorithm for |
| 3787 | selecting from among the available representations is difficult to |
| 3788 | describe to the user agent, or when the server desires to send its |
| 3789 | "best guess" to the client along with the first response (hoping to |
| 3790 | avoid the round-trip delay of a subsequent request if the "best |
| 3791 | guess" is good enough for the user). In order to improve the server's |
| 3792 | guess, the user agent MAY include request header fields (Accept, |
| 3793 | Accept-Language, Accept-Encoding, etc.) which describe its |
| 3794 | preferences for such a response. |
| 3795 | |
| 3796 | Server-driven negotiation has disadvantages: |
| 3797 | |
| 3798 | 1. It is impossible for the server to accurately determine what might be |
| 3799 | "best" for any given user, since that would require complete |
| 3800 | knowledge of both the capabilities of the user agent and the intended |
| 3801 | use for the response (e.g., does the user want to view it on screen |
| 3802 | or print it on paper?). |
| 3803 | |
| 3804 | 2. Having the user agent describe its capabilities in every request can |
| 3805 | be both very inefficient (given that only a small percentage of |
| 3806 | responses have multiple representations) and a potential violation of |
| 3807 | |
| 3808 | |
| 3809 | |
| 3810 | Fielding, et. al. Standards Track [Page 68] |
| 3811 | \f |
| 3812 | RFC 2068 HTTP/1.1 January 1997 |
| 3813 | |
| 3814 | |
| 3815 | the user's privacy. |
| 3816 | |
| 3817 | 3. It complicates the implementation of an origin server and the |
| 3818 | algorithms for generating responses to a request. |
| 3819 | |
| 3820 | 4. It may limit a public cache's ability to use the same response for |
| 3821 | multiple user's requests. |
| 3822 | |
| 3823 | HTTP/1.1 includes the following request-header fields for enabling |
| 3824 | server-driven negotiation through description of user agent |
| 3825 | capabilities and user preferences: Accept (section 14.1), Accept- |
| 3826 | Charset (section 14.2), Accept-Encoding (section 14.3), Accept- |
| 3827 | Language (section 14.4), and User-Agent (section 14.42). However, an |
| 3828 | origin server is not limited to these dimensions and MAY vary the |
| 3829 | response based on any aspect of the request, including information |
| 3830 | outside the request-header fields or within extension header fields |
| 3831 | not defined by this specification. |
| 3832 | |
| 3833 | HTTP/1.1 origin servers MUST include an appropriate Vary header field |
| 3834 | (section 14.43) in any cachable response based on server-driven |
| 3835 | negotiation. The Vary header field describes the dimensions over |
| 3836 | which the response might vary (i.e. the dimensions over which the |
| 3837 | origin server picks its "best guess" response from multiple |
| 3838 | representations). |
| 3839 | |
| 3840 | HTTP/1.1 public caches MUST recognize the Vary header field when it |
| 3841 | is included in a response and obey the requirements described in |
| 3842 | section 13.6 that describes the interactions between caching and |
| 3843 | content negotiation. |
| 3844 | |
| 3845 | 12.2 Agent-driven Negotiation |
| 3846 | |
| 3847 | With agent-driven negotiation, selection of the best representation |
| 3848 | for a response is performed by the user agent after receiving an |
| 3849 | initial response from the origin server. Selection is based on a list |
| 3850 | of the available representations of the response included within the |
| 3851 | header fields (this specification reserves the field-name Alternates, |
| 3852 | as described in appendix 19.6.2.1) or entity-body of the initial |
| 3853 | response, with each representation identified by its own URI. |
| 3854 | Selection from among the representations may be performed |
| 3855 | automatically (if the user agent is capable of doing so) or manually |
| 3856 | by the user selecting from a generated (possibly hypertext) menu. |
| 3857 | |
| 3858 | Agent-driven negotiation is advantageous when the response would vary |
| 3859 | over commonly-used dimensions (such as type, language, or encoding), |
| 3860 | when the origin server is unable to determine a user agent's |
| 3861 | capabilities from examining the request, and generally when public |
| 3862 | caches are used to distribute server load and reduce network usage. |
| 3863 | |
| 3864 | |
| 3865 | |
| 3866 | Fielding, et. al. Standards Track [Page 69] |
| 3867 | \f |
| 3868 | RFC 2068 HTTP/1.1 January 1997 |
| 3869 | |
| 3870 | |
| 3871 | Agent-driven negotiation suffers from the disadvantage of needing a |
| 3872 | second request to obtain the best alternate representation. This |
| 3873 | second request is only efficient when caching is used. In addition, |
| 3874 | this specification does not define any mechanism for supporting |
| 3875 | automatic selection, though it also does not prevent any such |
| 3876 | mechanism from being developed as an extension and used within |
| 3877 | HTTP/1.1. |
| 3878 | |
| 3879 | HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) |
| 3880 | status codes for enabling agent-driven negotiation when the server is |
| 3881 | unwilling or unable to provide a varying response using server-driven |
| 3882 | negotiation. |
| 3883 | |
| 3884 | 12.3 Transparent Negotiation |
| 3885 | |
| 3886 | Transparent negotiation is a combination of both server-driven and |
| 3887 | agent-driven negotiation. When a cache is supplied with a form of the |
| 3888 | list of available representations of the response (as in agent-driven |
| 3889 | negotiation) and the dimensions of variance are completely understood |
| 3890 | by the cache, then the cache becomes capable of performing server- |
| 3891 | driven negotiation on behalf of the origin server for subsequent |
| 3892 | requests on that resource. |
| 3893 | |
| 3894 | Transparent negotiation has the advantage of distributing the |
| 3895 | negotiation work that would otherwise be required of the origin |
| 3896 | server and also removing the second request delay of agent-driven |
| 3897 | negotiation when the cache is able to correctly guess the right |
| 3898 | response. |
| 3899 | |
| 3900 | This specification does not define any mechanism for transparent |
| 3901 | negotiation, though it also does not prevent any such mechanism from |
| 3902 | being developed as an extension and used within HTTP/1.1. An HTTP/1.1 |
| 3903 | cache performing transparent negotiation MUST include a Vary header |
| 3904 | field in the response (defining the dimensions of its variance) if it |
| 3905 | is cachable to ensure correct interoperation with all HTTP/1.1 |
| 3906 | clients. The agent-driven negotiation information supplied by the |
| 3907 | origin server SHOULD be included with the transparently negotiated |
| 3908 | response. |
| 3909 | |
| 3910 | 13 Caching in HTTP |
| 3911 | |
| 3912 | HTTP is typically used for distributed information systems, where |
| 3913 | performance can be improved by the use of response caches. The |
| 3914 | HTTP/1.1 protocol includes a number of elements intended to make |
| 3915 | caching work as well as possible. Because these elements are |
| 3916 | inextricable from other aspects of the protocol, and because they |
| 3917 | interact with each other, it is useful to describe the basic caching |
| 3918 | design of HTTP separately from the detailed descriptions of methods, |
| 3919 | |
| 3920 | |
| 3921 | |
| 3922 | Fielding, et. al. Standards Track [Page 70] |
| 3923 | \f |
| 3924 | RFC 2068 HTTP/1.1 January 1997 |
| 3925 | |
| 3926 | |
| 3927 | headers, response codes, etc. |
| 3928 | |
| 3929 | Caching would be useless if it did not significantly improve |
| 3930 | performance. The goal of caching in HTTP/1.1 is to eliminate the need |
| 3931 | to send requests in many cases, and to eliminate the need to send |
| 3932 | full responses in many other cases. The former reduces the number of |
| 3933 | network round-trips required for many operations; we use an |
| 3934 | "expiration" mechanism for this purpose (see section 13.2). The |
| 3935 | latter reduces network bandwidth requirements; we use a "validation" |
| 3936 | mechanism for this purpose (see section 13.3). |
| 3937 | |
| 3938 | Requirements for performance, availability, and disconnected |
| 3939 | operation require us to be able to relax the goal of semantic |
| 3940 | transparency. The HTTP/1.1 protocol allows origin servers, caches, |
| 3941 | and clients to explicitly reduce transparency when necessary. |
| 3942 | However, because non-transparent operation may confuse non-expert |
| 3943 | users, and may be incompatible with certain server applications (such |
| 3944 | as those for ordering merchandise), the protocol requires that |
| 3945 | transparency be relaxed |
| 3946 | |
| 3947 | o only by an explicit protocol-level request when relaxed by client |
| 3948 | or origin server |
| 3949 | |
| 3950 | o only with an explicit warning to the end user when relaxed by cache |
| 3951 | or client |
| 3952 | |
| 3953 | |
| 3954 | |
| 3955 | |
| 3956 | |
| 3957 | |
| 3958 | |
| 3959 | |
| 3960 | |
| 3961 | |
| 3962 | |
| 3963 | |
| 3964 | |
| 3965 | |
| 3966 | |
| 3967 | |
| 3968 | |
| 3969 | |
| 3970 | |
| 3971 | |
| 3972 | |
| 3973 | |
| 3974 | |
| 3975 | |
| 3976 | |
| 3977 | |
| 3978 | Fielding, et. al. Standards Track [Page 71] |
| 3979 | \f |
| 3980 | RFC 2068 HTTP/1.1 January 1997 |
| 3981 | |
| 3982 | |
| 3983 | Therefore, the HTTP/1.1 protocol provides these important elements: |
| 3984 | |
| 3985 | 1. Protocol features that provide full semantic transparency when this |
| 3986 | is required by all parties. |
| 3987 | |
| 3988 | 2. Protocol features that allow an origin server or user agent to |
| 3989 | explicitly request and control non-transparent operation. |
| 3990 | |
| 3991 | 3. Protocol features that allow a cache to attach warnings to |
| 3992 | responses that do not preserve the requested approximation of |
| 3993 | semantic transparency. |
| 3994 | |
| 3995 | A basic principle is that it must be possible for the clients to |
| 3996 | detect any potential relaxation of semantic transparency. |
| 3997 | |
| 3998 | Note: The server, cache, or client implementer may be faced with |
| 3999 | design decisions not explicitly discussed in this specification. If |
| 4000 | a decision may affect semantic transparency, the implementer ought |
| 4001 | to err on the side of maintaining transparency unless a careful and |
| 4002 | complete analysis shows significant benefits in breaking |
| 4003 | transparency. |
| 4004 | |
| 4005 | 13.1.1 Cache Correctness |
| 4006 | |
| 4007 | A correct cache MUST respond to a request with the most up-to-date |
| 4008 | response held by the cache that is appropriate to the request (see |
| 4009 | sections 13.2.5, 13.2.6, and 13.12) which meets one of the following |
| 4010 | conditions: |
| 4011 | |
| 4012 | 1. It has been checked for equivalence with what the origin server |
| 4013 | would have returned by revalidating the response with the origin |
| 4014 | server (section 13.3); |
| 4015 | |
| 4016 | 2. It is "fresh enough" (see section 13.2). In the default case, this |
| 4017 | means it meets the least restrictive freshness requirement of the |
| 4018 | client, server, and cache (see section 14.9); if the origin server |
| 4019 | so specifies, it is the freshness requirement of the origin server |
| 4020 | alone. |
| 4021 | |
| 4022 | 3. It includes a warning if the freshness demand of the client or the |
| 4023 | origin server is violated (see section 13.1.5 and 14.45). |
| 4024 | |
| 4025 | 4. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or |
| 4026 | error (4xx or 5xx) response message. |
| 4027 | |
| 4028 | If the cache can not communicate with the origin server, then a |
| 4029 | correct cache SHOULD respond as above if the response can be |
| 4030 | correctly served from the cache; if not it MUST return an error or |
| 4031 | |
| 4032 | |
| 4033 | |
| 4034 | Fielding, et. al. Standards Track [Page 72] |
| 4035 | \f |
| 4036 | RFC 2068 HTTP/1.1 January 1997 |
| 4037 | |
| 4038 | |
| 4039 | warning indicating that there was a communication failure. |
| 4040 | |
| 4041 | If a cache receives a response (either an entire response, or a 304 |
| 4042 | (Not Modified) response) that it would normally forward to the |
| 4043 | requesting client, and the received response is no longer fresh, the |
| 4044 | cache SHOULD forward it to the requesting client without adding a new |
| 4045 | Warning (but without removing any existing Warning headers). A cache |
| 4046 | SHOULD NOT attempt to revalidate a response simply because that |
| 4047 | response became stale in transit; this might lead to an infinite |
| 4048 | loop. An user agent that receives a stale response without a Warning |
| 4049 | MAY display a warning indication to the user. |
| 4050 | |
| 4051 | 13.1.2 Warnings |
| 4052 | |
| 4053 | Whenever a cache returns a response that is neither first-hand nor |
| 4054 | "fresh enough" (in the sense of condition 2 in section 13.1.1), it |
| 4055 | must attach a warning to that effect, using a Warning response- |
| 4056 | header. This warning allows clients to take appropriate action. |
| 4057 | |
| 4058 | Warnings may be used for other purposes, both cache-related and |
| 4059 | otherwise. The use of a warning, rather than an error status code, |
| 4060 | distinguish these responses from true failures. |
| 4061 | |
| 4062 | Warnings are always cachable, because they never weaken the |
| 4063 | transparency of a response. This means that warnings can be passed to |
| 4064 | HTTP/1.0 caches without danger; such caches will simply pass the |
| 4065 | warning along as an entity-header in the response. |
| 4066 | |
| 4067 | Warnings are assigned numbers between 0 and 99. This specification |
| 4068 | defines the code numbers and meanings of each currently assigned |
| 4069 | warnings, allowing a client or cache to take automated action in some |
| 4070 | (but not all) cases. |
| 4071 | |
| 4072 | Warnings also carry a warning text. The text may be in any |
| 4073 | appropriate natural language (perhaps based on the client's Accept |
| 4074 | headers), and include an optional indication of what character set is |
| 4075 | used. |
| 4076 | |
| 4077 | Multiple warnings may be attached to a response (either by the origin |
| 4078 | server or by a cache), including multiple warnings with the same code |
| 4079 | number. For example, a server may provide the same warning with texts |
| 4080 | in both English and Basque. |
| 4081 | |
| 4082 | When multiple warnings are attached to a response, it may not be |
| 4083 | practical or reasonable to display all of them to the user. This |
| 4084 | version of HTTP does not specify strict priority rules for deciding |
| 4085 | which warnings to display and in what order, but does suggest some |
| 4086 | heuristics. |
| 4087 | |
| 4088 | |
| 4089 | |
| 4090 | Fielding, et. al. Standards Track [Page 73] |
| 4091 | \f |
| 4092 | RFC 2068 HTTP/1.1 January 1997 |
| 4093 | |
| 4094 | |
| 4095 | The Warning header and the currently defined warnings are described |
| 4096 | in section 14.45. |
| 4097 | |
| 4098 | 13.1.3 Cache-control Mechanisms |
| 4099 | |
| 4100 | The basic cache mechanisms in HTTP/1.1 (server-specified expiration |
| 4101 | times and validators) are implicit directives to caches. In some |
| 4102 | cases, a server or client may need to provide explicit directives to |
| 4103 | the HTTP caches. We use the Cache-Control header for this purpose. |
| 4104 | |
| 4105 | The Cache-Control header allows a client or server to transmit a |
| 4106 | variety of directives in either requests or responses. These |
| 4107 | directives typically override the default caching algorithms. As a |
| 4108 | general rule, if there is any apparent conflict between header |
| 4109 | values, the most restrictive interpretation should be applied (that |
| 4110 | is, the one that is most likely to preserve semantic transparency). |
| 4111 | However, in some cases, Cache-Control directives are explicitly |
| 4112 | specified as weakening the approximation of semantic transparency |
| 4113 | (for example, "max-stale" or "public"). |
| 4114 | |
| 4115 | The Cache-Control directives are described in detail in section 14.9. |
| 4116 | |
| 4117 | 13.1.4 Explicit User Agent Warnings |
| 4118 | |
| 4119 | Many user agents make it possible for users to override the basic |
| 4120 | caching mechanisms. For example, the user agent may allow the user to |
| 4121 | specify that cached entities (even explicitly stale ones) are never |
| 4122 | validated. Or the user agent might habitually add "Cache-Control: |
| 4123 | max-stale=3600" to every request. The user should have to explicitly |
| 4124 | request either non-transparent behavior, or behavior that results in |
| 4125 | abnormally ineffective caching. |
| 4126 | |
| 4127 | If the user has overridden the basic caching mechanisms, the user |
| 4128 | agent should explicitly indicate to the user whenever this results in |
| 4129 | the display of information that might not meet the server's |
| 4130 | transparency requirements (in particular, if the displayed entity is |
| 4131 | known to be stale). Since the protocol normally allows the user agent |
| 4132 | to determine if responses are stale or not, this indication need only |
| 4133 | be displayed when this actually happens. The indication need not be a |
| 4134 | dialog box; it could be an icon (for example, a picture of a rotting |
| 4135 | fish) or some other visual indicator. |
| 4136 | |
| 4137 | If the user has overridden the caching mechanisms in a way that would |
| 4138 | abnormally reduce the effectiveness of caches, the user agent should |
| 4139 | continually display an indication (for example, a picture of currency |
| 4140 | in flames) so that the user does not inadvertently consume excess |
| 4141 | resources or suffer from excessive latency. |
| 4142 | |
| 4143 | |
| 4144 | |
| 4145 | |
| 4146 | Fielding, et. al. Standards Track [Page 74] |
| 4147 | \f |
| 4148 | RFC 2068 HTTP/1.1 January 1997 |
| 4149 | |
| 4150 | |
| 4151 | 13.1.5 Exceptions to the Rules and Warnings |
| 4152 | |
| 4153 | In some cases, the operator of a cache may choose to configure it to |
| 4154 | return stale responses even when not requested by clients. This |
| 4155 | decision should not be made lightly, but may be necessary for reasons |
| 4156 | of availability or performance, especially when the cache is poorly |
| 4157 | connected to the origin server. Whenever a cache returns a stale |
| 4158 | response, it MUST mark it as such (using a Warning header). This |
| 4159 | allows the client software to alert the user that there may be a |
| 4160 | potential problem. |
| 4161 | |
| 4162 | It also allows the user agent to take steps to obtain a first-hand or |
| 4163 | fresh response. For this reason, a cache SHOULD NOT return a stale |
| 4164 | response if the client explicitly requests a first-hand or fresh one, |
| 4165 | unless it is impossible to comply for technical or policy reasons. |
| 4166 | |
| 4167 | 13.1.6 Client-controlled Behavior |
| 4168 | |
| 4169 | While the origin server (and to a lesser extent, intermediate caches, |
| 4170 | by their contribution to the age of a response) are the primary |
| 4171 | source of expiration information, in some cases the client may need |
| 4172 | to control a cache's decision about whether to return a cached |
| 4173 | response without validating it. Clients do this using several |
| 4174 | directives of the Cache-Control header. |
| 4175 | |
| 4176 | A client's request may specify the maximum age it is willing to |
| 4177 | accept of an unvalidated response; specifying a value of zero forces |
| 4178 | the cache(s) to revalidate all responses. A client may also specify |
| 4179 | the minimum time remaining before a response expires. Both of these |
| 4180 | options increase constraints on the behavior of caches, and so cannot |
| 4181 | further relax the cache's approximation of semantic transparency. |
| 4182 | |
| 4183 | A client may also specify that it will accept stale responses, up to |
| 4184 | some maximum amount of staleness. This loosens the constraints on the |
| 4185 | caches, and so may violate the origin server's specified constraints |
| 4186 | on semantic transparency, but may be necessary to support |
| 4187 | disconnected operation, or high availability in the face of poor |
| 4188 | connectivity. |
| 4189 | |
| 4190 | 13.2 Expiration Model |
| 4191 | |
| 4192 | 13.2.1 Server-Specified Expiration |
| 4193 | |
| 4194 | HTTP caching works best when caches can entirely avoid making |
| 4195 | requests to the origin server. The primary mechanism for avoiding |
| 4196 | requests is for an origin server to provide an explicit expiration |
| 4197 | time in the future, indicating that a response may be used to satisfy |
| 4198 | subsequent requests. In other words, a cache can return a fresh |
| 4199 | |
| 4200 | |
| 4201 | |
| 4202 | Fielding, et. al. Standards Track [Page 75] |
| 4203 | \f |
| 4204 | RFC 2068 HTTP/1.1 January 1997 |
| 4205 | |
| 4206 | |
| 4207 | response without first contacting the server. |
| 4208 | |
| 4209 | Our expectation is that servers will assign future explicit |
| 4210 | expiration times to responses in the belief that the entity is not |
| 4211 | likely to change, in a semantically significant way, before the |
| 4212 | expiration time is reached. This normally preserves semantic |
| 4213 | transparency, as long as the server's expiration times are carefully |
| 4214 | chosen. |
| 4215 | |
| 4216 | The expiration mechanism applies only to responses taken from a cache |
| 4217 | and not to first-hand responses forwarded immediately to the |
| 4218 | requesting client. |
| 4219 | |
| 4220 | If an origin server wishes to force a semantically transparent cache |
| 4221 | to validate every request, it may assign an explicit expiration time |
| 4222 | in the past. This means that the response is always stale, and so the |
| 4223 | cache SHOULD validate it before using it for subsequent requests. See |
| 4224 | section 14.9.4 for a more restrictive way to force revalidation. |
| 4225 | |
| 4226 | If an origin server wishes to force any HTTP/1.1 cache, no matter how |
| 4227 | it is configured, to validate every request, it should use the |
| 4228 | "must-revalidate" Cache-Control directive (see section 14.9). |
| 4229 | |
| 4230 | Servers specify explicit expiration times using either the Expires |
| 4231 | header, or the max-age directive of the Cache-Control header. |
| 4232 | |
| 4233 | An expiration time cannot be used to force a user agent to refresh |
| 4234 | its display or reload a resource; its semantics apply only to caching |
| 4235 | mechanisms, and such mechanisms need only check a resource's |
| 4236 | expiration status when a new request for that resource is initiated. |
| 4237 | See section 13.13 for explanation of the difference between caches |
| 4238 | and history mechanisms. |
| 4239 | |
| 4240 | 13.2.2 Heuristic Expiration |
| 4241 | |
| 4242 | Since origin servers do not always provide explicit expiration times, |
| 4243 | HTTP caches typically assign heuristic expiration times, employing |
| 4244 | algorithms that use other header values (such as the Last-Modified |
| 4245 | time) to estimate a plausible expiration time. The HTTP/1.1 |
| 4246 | specification does not provide specific algorithms, but does impose |
| 4247 | worst-case constraints on their results. Since heuristic expiration |
| 4248 | times may compromise semantic transparency, they should be used |
| 4249 | cautiously, and we encourage origin servers to provide explicit |
| 4250 | expiration times as much as possible. |
| 4251 | |
| 4252 | |
| 4253 | |
| 4254 | |
| 4255 | |
| 4256 | |
| 4257 | |
| 4258 | Fielding, et. al. Standards Track [Page 76] |
| 4259 | \f |
| 4260 | RFC 2068 HTTP/1.1 January 1997 |
| 4261 | |
| 4262 | |
| 4263 | 13.2.3 Age Calculations |
| 4264 | |
| 4265 | In order to know if a cached entry is fresh, a cache needs to know if |
| 4266 | its age exceeds its freshness lifetime. We discuss how to calculate |
| 4267 | the latter in section 13.2.4; this section describes how to calculate |
| 4268 | the age of a response or cache entry. |
| 4269 | |
| 4270 | In this discussion, we use the term "now" to mean "the current value |
| 4271 | of the clock at the host performing the calculation." Hosts that use |
| 4272 | HTTP, but especially hosts running origin servers and caches, should |
| 4273 | use NTP [28] or some similar protocol to synchronize their clocks to |
| 4274 | a globally accurate time standard. |
| 4275 | |
| 4276 | Also note that HTTP/1.1 requires origin servers to send a Date header |
| 4277 | with every response, giving the time at which the response was |
| 4278 | generated. We use the term "date_value" to denote the value of the |
| 4279 | Date header, in a form appropriate for arithmetic operations. |
| 4280 | |
| 4281 | HTTP/1.1 uses the Age response-header to help convey age information |
| 4282 | between caches. The Age header value is the sender's estimate of the |
| 4283 | amount of time since the response was generated at the origin server. |
| 4284 | In the case of a cached response that has been revalidated with the |
| 4285 | origin server, the Age value is based on the time of revalidation, |
| 4286 | not of the original response. |
| 4287 | |
| 4288 | In essence, the Age value is the sum of the time that the response |
| 4289 | has been resident in each of the caches along the path from the |
| 4290 | origin server, plus the amount of time it has been in transit along |
| 4291 | network paths. |
| 4292 | |
| 4293 | We use the term "age_value" to denote the value of the Age header, in |
| 4294 | a form appropriate for arithmetic operations. |
| 4295 | |
| 4296 | A response's age can be calculated in two entirely independent ways: |
| 4297 | |
| 4298 | 1. now minus date_value, if the local clock is reasonably well |
| 4299 | synchronized to the origin server's clock. If the result is |
| 4300 | negative, the result is replaced by zero. |
| 4301 | |
| 4302 | 2. age_value, if all of the caches along the response path |
| 4303 | implement HTTP/1.1. |
| 4304 | |
| 4305 | Given that we have two independent ways to compute the age of a |
| 4306 | response when it is received, we can combine these as |
| 4307 | |
| 4308 | corrected_received_age = max(now - date_value, age_value) |
| 4309 | |
| 4310 | and as long as we have either nearly synchronized clocks or all- |
| 4311 | |
| 4312 | |
| 4313 | |
| 4314 | Fielding, et. al. Standards Track [Page 77] |
| 4315 | \f |
| 4316 | RFC 2068 HTTP/1.1 January 1997 |
| 4317 | |
| 4318 | |
| 4319 | HTTP/1.1 paths, one gets a reliable (conservative) result. |
| 4320 | |
| 4321 | Note that this correction is applied at each HTTP/1.1 cache along the |
| 4322 | path, so that if there is an HTTP/1.0 cache in the path, the correct |
| 4323 | received age is computed as long as the receiving cache's clock is |
| 4324 | nearly in sync. We don't need end-to-end clock synchronization |
| 4325 | (although it is good to have), and there is no explicit clock |
| 4326 | synchronization step. |
| 4327 | |
| 4328 | Because of network-imposed delays, some significant interval may pass |
| 4329 | from the time that a server generates a response and the time it is |
| 4330 | received at the next outbound cache or client. If uncorrected, this |
| 4331 | delay could result in improperly low ages. |
| 4332 | |
| 4333 | Because the request that resulted in the returned Age value must have |
| 4334 | been initiated prior to that Age value's generation, we can correct |
| 4335 | for delays imposed by the network by recording the time at which the |
| 4336 | request was initiated. Then, when an Age value is received, it MUST |
| 4337 | be interpreted relative to the time the request was initiated, not |
| 4338 | the time that the response was received. This algorithm results in |
| 4339 | conservative behavior no matter how much delay is experienced. So, we |
| 4340 | compute: |
| 4341 | |
| 4342 | corrected_initial_age = corrected_received_age |
| 4343 | + (now - request_time) |
| 4344 | |
| 4345 | where "request_time" is the time (according to the local clock) when |
| 4346 | the request that elicited this response was sent. |
| 4347 | |
| 4348 | Summary of age calculation algorithm, when a cache receives a |
| 4349 | response: |
| 4350 | |
| 4351 | /* |
| 4352 | * age_value |
| 4353 | * is the value of Age: header received by the cache with |
| 4354 | * this response. |
| 4355 | * date_value |
| 4356 | * is the value of the origin server's Date: header |
| 4357 | * request_time |
| 4358 | * is the (local) time when the cache made the request |
| 4359 | * that resulted in this cached response |
| 4360 | * response_time |
| 4361 | * is the (local) time when the cache received the |
| 4362 | * response |
| 4363 | * now |
| 4364 | * is the current (local) time |
| 4365 | */ |
| 4366 | apparent_age = max(0, response_time - date_value); |
| 4367 | |
| 4368 | |
| 4369 | |
| 4370 | Fielding, et. al. Standards Track [Page 78] |
| 4371 | \f |
| 4372 | RFC 2068 HTTP/1.1 January 1997 |
| 4373 | |
| 4374 | |
| 4375 | corrected_received_age = max(apparent_age, age_value); |
| 4376 | response_delay = response_time - request_time; |
| 4377 | corrected_initial_age = corrected_received_age + response_delay; |
| 4378 | resident_time = now - response_time; |
| 4379 | current_age = corrected_initial_age + resident_time; |
| 4380 | |
| 4381 | When a cache sends a response, it must add to the |
| 4382 | corrected_initial_age the amount of time that the response was |
| 4383 | resident locally. It must then transmit this total age, using the Age |
| 4384 | header, to the next recipient cache. |
| 4385 | |
| 4386 | Note that a client cannot reliably tell that a response is first- |
| 4387 | hand, but the presence of an Age header indicates that a response |
| 4388 | is definitely not first-hand. Also, if the Date in a response is |
| 4389 | earlier than the client's local request time, the response is |
| 4390 | probably not first-hand (in the absence of serious clock skew). |
| 4391 | |
| 4392 | 13.2.4 Expiration Calculations |
| 4393 | |
| 4394 | In order to decide whether a response is fresh or stale, we need to |
| 4395 | compare its freshness lifetime to its age. The age is calculated as |
| 4396 | described in section 13.2.3; this section describes how to calculate |
| 4397 | the freshness lifetime, and to determine if a response has expired. |
| 4398 | In the discussion below, the values can be represented in any form |
| 4399 | appropriate for arithmetic operations. |
| 4400 | |
| 4401 | We use the term "expires_value" to denote the value of the Expires |
| 4402 | header. We use the term "max_age_value" to denote an appropriate |
| 4403 | value of the number of seconds carried by the max-age directive of |
| 4404 | the Cache-Control header in a response (see section 14.10. |
| 4405 | |
| 4406 | The max-age directive takes priority over Expires, so if max-age is |
| 4407 | present in a response, the calculation is simply: |
| 4408 | |
| 4409 | freshness_lifetime = max_age_value |
| 4410 | |
| 4411 | Otherwise, if Expires is present in the response, the calculation is: |
| 4412 | |
| 4413 | freshness_lifetime = expires_value - date_value |
| 4414 | |
| 4415 | Note that neither of these calculations is vulnerable to clock skew, |
| 4416 | since all of the information comes from the origin server. |
| 4417 | |
| 4418 | If neither Expires nor Cache-Control: max-age appears in the |
| 4419 | response, and the response does not include other restrictions on |
| 4420 | caching, the cache MAY compute a freshness lifetime using a |
| 4421 | heuristic. If the value is greater than 24 hours, the cache must |
| 4422 | attach Warning 13 to any response whose age is more than 24 hours if |
| 4423 | |
| 4424 | |
| 4425 | |
| 4426 | Fielding, et. al. Standards Track [Page 79] |
| 4427 | \f |
| 4428 | RFC 2068 HTTP/1.1 January 1997 |
| 4429 | |
| 4430 | |
| 4431 | such warning has not already been added. |
| 4432 | |
| 4433 | Also, if the response does have a Last-Modified time, the heuristic |
| 4434 | expiration value SHOULD be no more than some fraction of the interval |
| 4435 | since that time. A typical setting of this fraction might be 10%. |
| 4436 | |
| 4437 | The calculation to determine if a response has expired is quite |
| 4438 | simple: |
| 4439 | |
| 4440 | response_is_fresh = (freshness_lifetime > current_age) |
| 4441 | |
| 4442 | 13.2.5 Disambiguating Expiration Values |
| 4443 | |
| 4444 | Because expiration values are assigned optimistically, it is possible |
| 4445 | for two caches to contain fresh values for the same resource that are |
| 4446 | different. |
| 4447 | |
| 4448 | If a client performing a retrieval receives a non-first-hand response |
| 4449 | for a request that was already fresh in its own cache, and the Date |
| 4450 | header in its existing cache entry is newer than the Date on the new |
| 4451 | response, then the client MAY ignore the response. If so, it MAY |
| 4452 | retry the request with a "Cache-Control: max-age=0" directive (see |
| 4453 | section 14.9), to force a check with the origin server. |
| 4454 | |
| 4455 | If a cache has two fresh responses for the same representation with |
| 4456 | different validators, it MUST use the one with the more recent Date |
| 4457 | header. This situation may arise because the cache is pooling |
| 4458 | responses from other caches, or because a client has asked for a |
| 4459 | reload or a revalidation of an apparently fresh cache entry. |
| 4460 | |
| 4461 | 13.2.6 Disambiguating Multiple Responses |
| 4462 | |
| 4463 | Because a client may be receiving responses via multiple paths, so |
| 4464 | that some responses flow through one set of caches and other |
| 4465 | responses flow through a different set of caches, a client may |
| 4466 | receive responses in an order different from that in which the origin |
| 4467 | server sent them. We would like the client to use the most recently |
| 4468 | generated response, even if older responses are still apparently |
| 4469 | fresh. |
| 4470 | |
| 4471 | Neither the entity tag nor the expiration value can impose an |
| 4472 | ordering on responses, since it is possible that a later response |
| 4473 | intentionally carries an earlier expiration time. However, the |
| 4474 | HTTP/1.1 specification requires the transmission of Date headers on |
| 4475 | every response, and the Date values are ordered to a granularity of |
| 4476 | one second. |
| 4477 | |
| 4478 | |
| 4479 | |
| 4480 | |
| 4481 | |
| 4482 | Fielding, et. al. Standards Track [Page 80] |
| 4483 | \f |
| 4484 | RFC 2068 HTTP/1.1 January 1997 |
| 4485 | |
| 4486 | |
| 4487 | When a client tries to revalidate a cache entry, and the response it |
| 4488 | receives contains a Date header that appears to be older than the one |
| 4489 | for the existing entry, then the client SHOULD repeat the request |
| 4490 | unconditionally, and include |
| 4491 | |
| 4492 | Cache-Control: max-age=0 |
| 4493 | |
| 4494 | to force any intermediate caches to validate their copies directly |
| 4495 | with the origin server, or |
| 4496 | |
| 4497 | Cache-Control: no-cache |
| 4498 | |
| 4499 | to force any intermediate caches to obtain a new copy from the origin |
| 4500 | server. |
| 4501 | |
| 4502 | If the Date values are equal, then the client may use either response |
| 4503 | (or may, if it is being extremely prudent, request a new response). |
| 4504 | Servers MUST NOT depend on clients being able to choose |
| 4505 | deterministically between responses generated during the same second, |
| 4506 | if their expiration times overlap. |
| 4507 | |
| 4508 | 13.3 Validation Model |
| 4509 | |
| 4510 | When a cache has a stale entry that it would like to use as a |
| 4511 | response to a client's request, it first has to check with the origin |
| 4512 | server (or possibly an intermediate cache with a fresh response) to |
| 4513 | see if its cached entry is still usable. We call this "validating" |
| 4514 | the cache entry. Since we do not want to have to pay the overhead of |
| 4515 | retransmitting the full response if the cached entry is good, and we |
| 4516 | do not want to pay the overhead of an extra round trip if the cached |
| 4517 | entry is invalid, the HTTP/1.1 protocol supports the use of |
| 4518 | conditional methods. |
| 4519 | |
| 4520 | The key protocol features for supporting conditional methods are |
| 4521 | those concerned with "cache validators." When an origin server |
| 4522 | generates a full response, it attaches some sort of validator to it, |
| 4523 | which is kept with the cache entry. When a client (user agent or |
| 4524 | proxy cache) makes a conditional request for a resource for which it |
| 4525 | has a cache entry, it includes the associated validator in the |
| 4526 | request. |
| 4527 | |
| 4528 | The server then checks that validator against the current validator |
| 4529 | for the entity, and, if they match, it responds with a special status |
| 4530 | code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it |
| 4531 | returns a full response (including entity-body). Thus, we avoid |
| 4532 | transmitting the full response if the validator matches, and we avoid |
| 4533 | an extra round trip if it does not match. |
| 4534 | |
| 4535 | |
| 4536 | |
| 4537 | |
| 4538 | Fielding, et. al. Standards Track [Page 81] |
| 4539 | \f |
| 4540 | RFC 2068 HTTP/1.1 January 1997 |
| 4541 | |
| 4542 | |
| 4543 | Note: the comparison functions used to decide if validators match |
| 4544 | are defined in section 13.3.3. |
| 4545 | |
| 4546 | In HTTP/1.1, a conditional request looks exactly the same as a normal |
| 4547 | request for the same resource, except that it carries a special |
| 4548 | header (which includes the validator) that implicitly turns the |
| 4549 | method (usually, GET) into a conditional. |
| 4550 | |
| 4551 | The protocol includes both positive and negative senses of cache- |
| 4552 | validating conditions. That is, it is possible to request either that |
| 4553 | a method be performed if and only if a validator matches or if and |
| 4554 | only if no validators match. |
| 4555 | |
| 4556 | Note: a response that lacks a validator may still be cached, and |
| 4557 | served from cache until it expires, unless this is explicitly |
| 4558 | prohibited by a Cache-Control directive. However, a cache cannot do |
| 4559 | a conditional retrieval if it does not have a validator for the |
| 4560 | entity, which means it will not be refreshable after it expires. |
| 4561 | |
| 4562 | 13.3.1 Last-modified Dates |
| 4563 | |
| 4564 | The Last-Modified entity-header field value is often used as a cache |
| 4565 | validator. In simple terms, a cache entry is considered to be valid |
| 4566 | if the entity has not been modified since the Last-Modified value. |
| 4567 | |
| 4568 | 13.3.2 Entity Tag Cache Validators |
| 4569 | |
| 4570 | The ETag entity-header field value, an entity tag, provides for an |
| 4571 | "opaque" cache validator. This may allow more reliable validation in |
| 4572 | situations where it is inconvenient to store modification dates, |
| 4573 | where the one-second resolution of HTTP date values is not |
| 4574 | sufficient, or where the origin server wishes to avoid certain |
| 4575 | paradoxes that may arise from the use of modification dates. |
| 4576 | |
| 4577 | Entity Tags are described in section 3.11. The headers used with |
| 4578 | entity tags are described in sections 14.20, 14.25, 14.26 and 14.43. |
| 4579 | |
| 4580 | 13.3.3 Weak and Strong Validators |
| 4581 | |
| 4582 | Since both origin servers and caches will compare two validators to |
| 4583 | decide if they represent the same or different entities, one normally |
| 4584 | would expect that if the entity (the entity-body or any entity- |
| 4585 | headers) changes in any way, then the associated validator would |
| 4586 | change as well. If this is true, then we call this validator a |
| 4587 | "strong validator." |
| 4588 | |
| 4589 | However, there may be cases when a server prefers to change the |
| 4590 | validator only on semantically significant changes, and not when |
| 4591 | |
| 4592 | |
| 4593 | |
| 4594 | Fielding, et. al. Standards Track [Page 82] |
| 4595 | \f |
| 4596 | RFC 2068 HTTP/1.1 January 1997 |
| 4597 | |
| 4598 | |
| 4599 | insignificant aspects of the entity change. A validator that does not |
| 4600 | always change when the resource changes is a "weak validator." |
| 4601 | |
| 4602 | Entity tags are normally "strong validators," but the protocol |
| 4603 | provides a mechanism to tag an entity tag as "weak." One can think of |
| 4604 | a strong validator as one that changes whenever the bits of an entity |
| 4605 | changes, while a weak value changes whenever the meaning of an entity |
| 4606 | changes. Alternatively, one can think of a strong validator as part |
| 4607 | of an identifier for a specific entity, while a weak validator is |
| 4608 | part of an identifier for a set of semantically equivalent entities. |
| 4609 | |
| 4610 | Note: One example of a strong validator is an integer that is |
| 4611 | incremented in stable storage every time an entity is changed. |
| 4612 | |
| 4613 | An entity's modification time, if represented with one-second |
| 4614 | resolution, could be a weak validator, since it is possible that |
| 4615 | the resource may be modified twice during a single second. |
| 4616 | |
| 4617 | Support for weak validators is optional; however, weak validators |
| 4618 | allow for more efficient caching of equivalent objects; for |
| 4619 | example, a hit counter on a site is probably good enough if it is |
| 4620 | updated every few days or weeks, and any value during that period |
| 4621 | is likely "good enough" to be equivalent. |
| 4622 | |
| 4623 | A "use" of a validator is either when a client generates a request |
| 4624 | and includes the validator in a validating header field, or when a |
| 4625 | server compares two validators. |
| 4626 | |
| 4627 | Strong validators are usable in any context. Weak validators are only |
| 4628 | usable in contexts that do not depend on exact equality of an entity. |
| 4629 | For example, either kind is usable for a conditional GET of a full |
| 4630 | entity. However, only a strong validator is usable for a sub-range |
| 4631 | retrieval, since otherwise the client may end up with an internally |
| 4632 | inconsistent entity. |
| 4633 | |
| 4634 | The only function that the HTTP/1.1 protocol defines on validators is |
| 4635 | comparison. There are two validator comparison functions, depending |
| 4636 | on whether the comparison context allows the use of weak validators |
| 4637 | or not: |
| 4638 | |
| 4639 | o The strong comparison function: in order to be considered equal, |
| 4640 | both validators must be identical in every way, and neither may be |
| 4641 | weak. |
| 4642 | o The weak comparison function: in order to be considered equal, both |
| 4643 | validators must be identical in every way, but either or both of |
| 4644 | them may be tagged as "weak" without affecting the result. |
| 4645 | |
| 4646 | The weak comparison function MAY be used for simple (non-subrange) |
| 4647 | |
| 4648 | |
| 4649 | |
| 4650 | Fielding, et. al. Standards Track [Page 83] |
| 4651 | \f |
| 4652 | RFC 2068 HTTP/1.1 January 1997 |
| 4653 | |
| 4654 | |
| 4655 | GET requests. The strong comparison function MUST be used in all |
| 4656 | other cases. |
| 4657 | |
| 4658 | An entity tag is strong unless it is explicitly tagged as weak. |
| 4659 | Section 3.11 gives the syntax for entity tags. |
| 4660 | |
| 4661 | A Last-Modified time, when used as a validator in a request, is |
| 4662 | implicitly weak unless it is possible to deduce that it is strong, |
| 4663 | using the following rules: |
| 4664 | |
| 4665 | o The validator is being compared by an origin server to the actual |
| 4666 | current validator for the entity and, |
| 4667 | o That origin server reliably knows that the associated entity did |
| 4668 | not change twice during the second covered by the presented |
| 4669 | validator. |
| 4670 | or |
| 4671 | |
| 4672 | o The validator is about to be used by a client in an If-Modified- |
| 4673 | Since or If-Unmodified-Since header, because the client has a cache |
| 4674 | entry for the associated entity, and |
| 4675 | o That cache entry includes a Date value, which gives the time when |
| 4676 | the origin server sent the original response, and |
| 4677 | o The presented Last-Modified time is at least 60 seconds before the |
| 4678 | Date value. |
| 4679 | or |
| 4680 | |
| 4681 | o The validator is being compared by an intermediate cache to the |
| 4682 | validator stored in its cache entry for the entity, and |
| 4683 | o That cache entry includes a Date value, which gives the time when |
| 4684 | the origin server sent the original response, and |
| 4685 | o The presented Last-Modified time is at least 60 seconds before the |
| 4686 | Date value. |
| 4687 | |
| 4688 | This method relies on the fact that if two different responses were |
| 4689 | sent by the origin server during the same second, but both had the |
| 4690 | same Last-Modified time, then at least one of those responses would |
| 4691 | have a Date value equal to its Last-Modified time. The arbitrary 60- |
| 4692 | second limit guards against the possibility that the Date and Last- |
| 4693 | Modified values are generated from different clocks, or at somewhat |
| 4694 | different times during the preparation of the response. An |
| 4695 | implementation may use a value larger than 60 seconds, if it is |
| 4696 | believed that 60 seconds is too short. |
| 4697 | |
| 4698 | If a client wishes to perform a sub-range retrieval on a value for |
| 4699 | which it has only a Last-Modified time and no opaque validator, it |
| 4700 | may do this only if the Last-Modified time is strong in the sense |
| 4701 | described here. |
| 4702 | |
| 4703 | |
| 4704 | |
| 4705 | |
| 4706 | Fielding, et. al. Standards Track [Page 84] |
| 4707 | \f |
| 4708 | RFC 2068 HTTP/1.1 January 1997 |
| 4709 | |
| 4710 | |
| 4711 | A cache or origin server receiving a cache-conditional request, other |
| 4712 | than a full-body GET request, MUST use the strong comparison function |
| 4713 | to evaluate the condition. |
| 4714 | |
| 4715 | These rules allow HTTP/1.1 caches and clients to safely perform sub- |
| 4716 | range retrievals on values that have been obtained from HTTP/1.0 |
| 4717 | servers. |
| 4718 | |
| 4719 | 13.3.4 Rules for When to Use Entity Tags and Last-modified Dates |
| 4720 | |
| 4721 | We adopt a set of rules and recommendations for origin servers, |
| 4722 | clients, and caches regarding when various validator types should be |
| 4723 | used, and for what purposes. |
| 4724 | |
| 4725 | HTTP/1.1 origin servers: |
| 4726 | |
| 4727 | o SHOULD send an entity tag validator unless it is not feasible to |
| 4728 | generate one. |
| 4729 | o MAY send a weak entity tag instead of a strong entity tag, if |
| 4730 | performance considerations support the use of weak entity tags, or |
| 4731 | if it is unfeasible to send a strong entity tag. |
| 4732 | o SHOULD send a Last-Modified value if it is feasible to send one, |
| 4733 | unless the risk of a breakdown in semantic transparency that could |
| 4734 | result from using this date in an If-Modified-Since header would |
| 4735 | lead to serious problems. |
| 4736 | |
| 4737 | In other words, the preferred behavior for an HTTP/1.1 origin server |
| 4738 | is to send both a strong entity tag and a Last-Modified value. |
| 4739 | |
| 4740 | In order to be legal, a strong entity tag MUST change whenever the |
| 4741 | associated entity value changes in any way. A weak entity tag SHOULD |
| 4742 | change whenever the associated entity changes in a semantically |
| 4743 | significant way. |
| 4744 | |
| 4745 | Note: in order to provide semantically transparent caching, an |
| 4746 | origin server must avoid reusing a specific strong entity tag value |
| 4747 | for two different entities, or reusing a specific weak entity tag |
| 4748 | value for two semantically different entities. Cache entries may |
| 4749 | persist for arbitrarily long periods, regardless of expiration |
| 4750 | times, so it may be inappropriate to expect that a cache will never |
| 4751 | again attempt to validate an entry using a validator that it |
| 4752 | obtained at some point in the past. |
| 4753 | |
| 4754 | HTTP/1.1 clients: |
| 4755 | |
| 4756 | o If an entity tag has been provided by the origin server, MUST |
| 4757 | use that entity tag in any cache-conditional request (using |
| 4758 | If-Match or If-None-Match). |
| 4759 | |
| 4760 | |
| 4761 | |
| 4762 | Fielding, et. al. Standards Track [Page 85] |
| 4763 | \f |
| 4764 | RFC 2068 HTTP/1.1 January 1997 |
| 4765 | |
| 4766 | |
| 4767 | o If only a Last-Modified value has been provided by the origin |
| 4768 | server, SHOULD use that value in non-subrange cache-conditional |
| 4769 | requests (using If-Modified-Since). |
| 4770 | o If only a Last-Modified value has been provided by an HTTP/1.0 |
| 4771 | origin server, MAY use that value in subrange cache-conditional |
| 4772 | requests (using If-Unmodified-Since:). The user agent should |
| 4773 | provide a way to disable this, in case of difficulty. |
| 4774 | o If both an entity tag and a Last-Modified value have been |
| 4775 | provided by the origin server, SHOULD use both validators in |
| 4776 | cache-conditional requests. This allows both HTTP/1.0 and |
| 4777 | HTTP/1.1 caches to respond appropriately. |
| 4778 | |
| 4779 | An HTTP/1.1 cache, upon receiving a request, MUST use the most |
| 4780 | restrictive validator when deciding whether the client's cache entry |
| 4781 | matches the cache's own cache entry. This is only an issue when the |
| 4782 | request contains both an entity tag and a last-modified-date |
| 4783 | validator (If-Modified-Since or If-Unmodified-Since). |
| 4784 | |
| 4785 | A note on rationale: The general principle behind these rules is |
| 4786 | that HTTP/1.1 servers and clients should transmit as much non- |
| 4787 | redundant information as is available in their responses and |
| 4788 | requests. HTTP/1.1 systems receiving this information will make the |
| 4789 | most conservative assumptions about the validators they receive. |
| 4790 | |
| 4791 | HTTP/1.0 clients and caches will ignore entity tags. Generally, |
| 4792 | last-modified values received or used by these systems will support |
| 4793 | transparent and efficient caching, and so HTTP/1.1 origin servers |
| 4794 | should provide Last-Modified values. In those rare cases where the |
| 4795 | use of a Last-Modified value as a validator by an HTTP/1.0 system |
| 4796 | could result in a serious problem, then HTTP/1.1 origin servers |
| 4797 | should not provide one. |
| 4798 | |
| 4799 | 13.3.5 Non-validating Conditionals |
| 4800 | |
| 4801 | The principle behind entity tags is that only the service author |
| 4802 | knows the semantics of a resource well enough to select an |
| 4803 | appropriate cache validation mechanism, and the specification of any |
| 4804 | validator comparison function more complex than byte-equality would |
| 4805 | open up a can of worms. Thus, comparisons of any other headers |
| 4806 | (except Last-Modified, for compatibility with HTTP/1.0) are never |
| 4807 | used for purposes of validating a cache entry. |
| 4808 | |
| 4809 | 13.4 Response Cachability |
| 4810 | |
| 4811 | Unless specifically constrained by a Cache-Control (section 14.9) |
| 4812 | directive, a caching system may always store a successful response |
| 4813 | (see section 13.8) as a cache entry, may return it without validation |
| 4814 | if it is fresh, and may return it after successful validation. If |
| 4815 | |
| 4816 | |
| 4817 | |
| 4818 | Fielding, et. al. Standards Track [Page 86] |
| 4819 | \f |
| 4820 | RFC 2068 HTTP/1.1 January 1997 |
| 4821 | |
| 4822 | |
| 4823 | there is neither a cache validator nor an explicit expiration time |
| 4824 | associated with a response, we do not expect it to be cached, but |
| 4825 | certain caches may violate this expectation (for example, when little |
| 4826 | or no network connectivity is available). A client can usually detect |
| 4827 | that such a response was taken from a cache by comparing the Date |
| 4828 | header to the current time. |
| 4829 | |
| 4830 | Note that some HTTP/1.0 caches are known to violate this |
| 4831 | expectation without providing any Warning. |
| 4832 | |
| 4833 | However, in some cases it may be inappropriate for a cache to retain |
| 4834 | an entity, or to return it in response to a subsequent request. This |
| 4835 | may be because absolute semantic transparency is deemed necessary by |
| 4836 | the service author, or because of security or privacy considerations. |
| 4837 | Certain Cache-Control directives are therefore provided so that the |
| 4838 | server can indicate that certain resource entities, or portions |
| 4839 | thereof, may not be cached regardless of other considerations. |
| 4840 | |
| 4841 | Note that section 14.8 normally prevents a shared cache from saving |
| 4842 | and returning a response to a previous request if that request |
| 4843 | included an Authorization header. |
| 4844 | |
| 4845 | A response received with a status code of 200, 203, 206, 300, 301 or |
| 4846 | 410 may be stored by a cache and used in reply to a subsequent |
| 4847 | request, subject to the expiration mechanism, unless a Cache-Control |
| 4848 | directive prohibits caching. However, a cache that does not support |
| 4849 | the Range and Content-Range headers MUST NOT cache 206 (Partial |
| 4850 | Content) responses. |
| 4851 | |
| 4852 | A response received with any other status code MUST NOT be returned |
| 4853 | in a reply to a subsequent request unless there are Cache-Control |
| 4854 | directives or another header(s) that explicitly allow it. For |
| 4855 | example, these include the following: an Expires header (section |
| 4856 | 14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public" |
| 4857 | or "private" Cache-Control directive (section 14.9). |
| 4858 | |
| 4859 | 13.5 Constructing Responses From Caches |
| 4860 | |
| 4861 | The purpose of an HTTP cache is to store information received in |
| 4862 | response to requests, for use in responding to future requests. In |
| 4863 | many cases, a cache simply returns the appropriate parts of a |
| 4864 | response to the requester. However, if the cache holds a cache entry |
| 4865 | based on a previous response, it may have to combine parts of a new |
| 4866 | response with what is held in the cache entry. |
| 4867 | |
| 4868 | |
| 4869 | |
| 4870 | |
| 4871 | |
| 4872 | |
| 4873 | |
| 4874 | Fielding, et. al. Standards Track [Page 87] |
| 4875 | \f |
| 4876 | RFC 2068 HTTP/1.1 January 1997 |
| 4877 | |
| 4878 | |
| 4879 | 13.5.1 End-to-end and Hop-by-hop Headers |
| 4880 | |
| 4881 | For the purpose of defining the behavior of caches and non-caching |
| 4882 | proxies, we divide HTTP headers into two categories: |
| 4883 | |
| 4884 | o End-to-end headers, which must be transmitted to the |
| 4885 | ultimate recipient of a request or response. End-to-end |
| 4886 | headers in responses must be stored as part of a cache entry |
| 4887 | and transmitted in any response formed from a cache entry. |
| 4888 | o Hop-by-hop headers, which are meaningful only for a single |
| 4889 | transport-level connection, and are not stored by caches or |
| 4890 | forwarded by proxies. |
| 4891 | |
| 4892 | The following HTTP/1.1 headers are hop-by-hop headers: |
| 4893 | |
| 4894 | o Connection |
| 4895 | o Keep-Alive |
| 4896 | o Public |
| 4897 | o Proxy-Authenticate |
| 4898 | o Transfer-Encoding |
| 4899 | o Upgrade |
| 4900 | |
| 4901 | All other headers defined by HTTP/1.1 are end-to-end headers. |
| 4902 | |
| 4903 | Hop-by-hop headers introduced in future versions of HTTP MUST be |
| 4904 | listed in a Connection header, as described in section 14.10. |
| 4905 | |
| 4906 | 13.5.2 Non-modifiable Headers |
| 4907 | |
| 4908 | Some features of the HTTP/1.1 protocol, such as Digest |
| 4909 | Authentication, depend on the value of certain end-to-end headers. A |
| 4910 | cache or non-caching proxy SHOULD NOT modify an end-to-end header |
| 4911 | unless the definition of that header requires or specifically allows |
| 4912 | that. |
| 4913 | |
| 4914 | A cache or non-caching proxy MUST NOT modify any of the following |
| 4915 | fields in a request or response, nor may it add any of these fields |
| 4916 | if not already present: |
| 4917 | |
| 4918 | o Content-Location |
| 4919 | o ETag |
| 4920 | o Expires |
| 4921 | o Last-Modified |
| 4922 | |
| 4923 | |
| 4924 | |
| 4925 | |
| 4926 | |
| 4927 | |
| 4928 | |
| 4929 | |
| 4930 | Fielding, et. al. Standards Track [Page 88] |
| 4931 | \f |
| 4932 | RFC 2068 HTTP/1.1 January 1997 |
| 4933 | |
| 4934 | |
| 4935 | A cache or non-caching proxy MUST NOT modify or add any of the |
| 4936 | following fields in a response that contains the no-transform Cache- |
| 4937 | Control directive, or in any request: |
| 4938 | |
| 4939 | o Content-Encoding |
| 4940 | o Content-Length |
| 4941 | o Content-Range |
| 4942 | o Content-Type |
| 4943 | |
| 4944 | A cache or non-caching proxy MAY modify or add these fields in a |
| 4945 | response that does not include no-transform, but if it does so, it |
| 4946 | MUST add a Warning 14 (Transformation applied) if one does not |
| 4947 | already appear in the response. |
| 4948 | |
| 4949 | Warning: unnecessary modification of end-to-end headers may cause |
| 4950 | authentication failures if stronger authentication mechanisms are |
| 4951 | introduced in later versions of HTTP. Such authentication |
| 4952 | mechanisms may rely on the values of header fields not listed here. |
| 4953 | |
| 4954 | 13.5.3 Combining Headers |
| 4955 | |
| 4956 | When a cache makes a validating request to a server, and the server |
| 4957 | provides a 304 (Not Modified) response, the cache must construct a |
| 4958 | response to send to the requesting client. The cache uses the |
| 4959 | entity-body stored in the cache entry as the entity-body of this |
| 4960 | outgoing response. The end-to-end headers stored in the cache entry |
| 4961 | are used for the constructed response, except that any end-to-end |
| 4962 | headers provided in the 304 response MUST replace the corresponding |
| 4963 | headers from the cache entry. Unless the cache decides to remove the |
| 4964 | cache entry, it MUST also replace the end-to-end headers stored with |
| 4965 | the cache entry with corresponding headers received in the incoming |
| 4966 | response. |
| 4967 | |
| 4968 | In other words, the set of end-to-end headers received in the |
| 4969 | incoming response overrides all corresponding end-to-end headers |
| 4970 | stored with the cache entry. The cache may add Warning headers (see |
| 4971 | section 14.45) to this set. |
| 4972 | |
| 4973 | If a header field-name in the incoming response matches more than one |
| 4974 | header in the cache entry, all such old headers are replaced. |
| 4975 | |
| 4976 | Note: this rule allows an origin server to use a 304 (Not Modified) |
| 4977 | response to update any header associated with a previous response |
| 4978 | for the same entity, although it might not always be meaningful or |
| 4979 | correct to do so. This rule does not allow an origin server to use |
| 4980 | a 304 (not Modified) response to entirely delete a header that it |
| 4981 | had provided with a previous response. |
| 4982 | |
| 4983 | |
| 4984 | |
| 4985 | |
| 4986 | Fielding, et. al. Standards Track [Page 89] |
| 4987 | \f |
| 4988 | RFC 2068 HTTP/1.1 January 1997 |
| 4989 | |
| 4990 | |
| 4991 | 13.5.4 Combining Byte Ranges |
| 4992 | |
| 4993 | A response may transfer only a subrange of the bytes of an entity- |
| 4994 | body, either because the request included one or more Range |
| 4995 | specifications, or because a connection was broken prematurely. After |
| 4996 | several such transfers, a cache may have received several ranges of |
| 4997 | the same entity-body. |
| 4998 | |
| 4999 | If a cache has a stored non-empty set of subranges for an entity, and |
| 5000 | an incoming response transfers another subrange, the cache MAY |
| 5001 | combine the new subrange with the existing set if both the following |
| 5002 | conditions are met: |
| 5003 | |
| 5004 | o Both the incoming response and the cache entry must have a cache |
| 5005 | validator. |
| 5006 | o The two cache validators must match using the strong comparison |
| 5007 | function (see section 13.3.3). |
| 5008 | |
| 5009 | If either requirement is not meant, the cache must use only the most |
| 5010 | recent partial response (based on the Date values transmitted with |
| 5011 | every response, and using the incoming response if these values are |
| 5012 | equal or missing), and must discard the other partial information. |
| 5013 | |
| 5014 | 13.6 Caching Negotiated Responses |
| 5015 | |
| 5016 | Use of server-driven content negotiation (section 12), as indicated |
| 5017 | by the presence of a Vary header field in a response, alters the |
| 5018 | conditions and procedure by which a cache can use the response for |
| 5019 | subsequent requests. |
| 5020 | |
| 5021 | A server MUST use the Vary header field (section 14.43) to inform a |
| 5022 | cache of what header field dimensions are used to select among |
| 5023 | multiple representations of a cachable response. A cache may use the |
| 5024 | selected representation (the entity included with that particular |
| 5025 | response) for replying to subsequent requests on that resource only |
| 5026 | when the subsequent requests have the same or equivalent values for |
| 5027 | all header fields specified in the Vary response-header. Requests |
| 5028 | with a different value for one or more of those header fields would |
| 5029 | be forwarded toward the origin server. |
| 5030 | |
| 5031 | If an entity tag was assigned to the representation, the forwarded |
| 5032 | request SHOULD be conditional and include the entity tags in an If- |
| 5033 | None-Match header field from all its cache entries for the Request- |
| 5034 | URI. This conveys to the server the set of entities currently held by |
| 5035 | the cache, so that if any one of these entities matches the requested |
| 5036 | entity, the server can use the ETag header in its 304 (Not Modified) |
| 5037 | response to tell the cache which entry is appropriate. If the |
| 5038 | entity-tag of the new response matches that of an existing entry, the |
| 5039 | |
| 5040 | |
| 5041 | |
| 5042 | Fielding, et. al. Standards Track [Page 90] |
| 5043 | \f |
| 5044 | RFC 2068 HTTP/1.1 January 1997 |
| 5045 | |
| 5046 | |
| 5047 | new response SHOULD be used to update the header fields of the |
| 5048 | existing entry, and the result MUST be returned to the client. |
| 5049 | |
| 5050 | The Vary header field may also inform the cache that the |
| 5051 | representation was selected using criteria not limited to the |
| 5052 | request-headers; in this case, a cache MUST NOT use the response in a |
| 5053 | reply to a subsequent request unless the cache relays the new request |
| 5054 | to the origin server in a conditional request and the server responds |
| 5055 | with 304 (Not Modified), including an entity tag or Content-Location |
| 5056 | that indicates which entity should be used. |
| 5057 | |
| 5058 | If any of the existing cache entries contains only partial content |
| 5059 | for the associated entity, its entity-tag SHOULD NOT be included in |
| 5060 | the If-None-Match header unless the request is for a range that would |
| 5061 | be fully satisfied by that entry. |
| 5062 | |
| 5063 | If a cache receives a successful response whose Content-Location |
| 5064 | field matches that of an existing cache entry for the same Request- |
| 5065 | URI, whose entity-tag differs from that of the existing entry, and |
| 5066 | whose Date is more recent than that of the existing entry, the |
| 5067 | existing entry SHOULD NOT be returned in response to future requests, |
| 5068 | and should be deleted from the cache. |
| 5069 | |
| 5070 | 13.7 Shared and Non-Shared Caches |
| 5071 | |
| 5072 | For reasons of security and privacy, it is necessary to make a |
| 5073 | distinction between "shared" and "non-shared" caches. A non-shared |
| 5074 | cache is one that is accessible only to a single user. Accessibility |
| 5075 | in this case SHOULD be enforced by appropriate security mechanisms. |
| 5076 | All other caches are considered to be "shared." Other sections of |
| 5077 | this specification place certain constraints on the operation of |
| 5078 | shared caches in order to prevent loss of privacy or failure of |
| 5079 | access controls. |
| 5080 | |
| 5081 | 13.8 Errors or Incomplete Response Cache Behavior |
| 5082 | |
| 5083 | A cache that receives an incomplete response (for example, with fewer |
| 5084 | bytes of data than specified in a Content-Length header) may store |
| 5085 | the response. However, the cache MUST treat this as a partial |
| 5086 | response. Partial responses may be combined as described in section |
| 5087 | 13.5.4; the result might be a full response or might still be |
| 5088 | partial. A cache MUST NOT return a partial response to a client |
| 5089 | without explicitly marking it as such, using the 206 (Partial |
| 5090 | Content) status code. A cache MUST NOT return a partial response |
| 5091 | using a status code of 200 (OK). |
| 5092 | |
| 5093 | If a cache receives a 5xx response while attempting to revalidate an |
| 5094 | entry, it may either forward this response to the requesting client, |
| 5095 | |
| 5096 | |
| 5097 | |
| 5098 | Fielding, et. al. Standards Track [Page 91] |
| 5099 | \f |
| 5100 | RFC 2068 HTTP/1.1 January 1997 |
| 5101 | |
| 5102 | |
| 5103 | or act as if the server failed to respond. In the latter case, it MAY |
| 5104 | return a previously received response unless the cached entry |
| 5105 | includes the "must-revalidate" Cache-Control directive (see section |
| 5106 | 14.9). |
| 5107 | |
| 5108 | 13.9 Side Effects of GET and HEAD |
| 5109 | |
| 5110 | Unless the origin server explicitly prohibits the caching of their |
| 5111 | responses, the application of GET and HEAD methods to any resources |
| 5112 | SHOULD NOT have side effects that would lead to erroneous behavior if |
| 5113 | these responses are taken from a cache. They may still have side |
| 5114 | effects, but a cache is not required to consider such side effects in |
| 5115 | its caching decisions. Caches are always expected to observe an |
| 5116 | origin server's explicit restrictions on caching. |
| 5117 | |
| 5118 | We note one exception to this rule: since some applications have |
| 5119 | traditionally used GETs and HEADs with query URLs (those containing a |
| 5120 | "?" in the rel_path part) to perform operations with significant side |
| 5121 | effects, caches MUST NOT treat responses to such URLs as fresh unless |
| 5122 | the server provides an explicit expiration time. This specifically |
| 5123 | means that responses from HTTP/1.0 servers for such URIs should not |
| 5124 | be taken from a cache. See section 9.1.1 for related information. |
| 5125 | |
| 5126 | 13.10 Invalidation After Updates or Deletions |
| 5127 | |
| 5128 | The effect of certain methods at the origin server may cause one or |
| 5129 | more existing cache entries to become non-transparently invalid. That |
| 5130 | is, although they may continue to be "fresh," they do not accurately |
| 5131 | reflect what the origin server would return for a new request. |
| 5132 | |
| 5133 | There is no way for the HTTP protocol to guarantee that all such |
| 5134 | cache entries are marked invalid. For example, the request that |
| 5135 | caused the change at the origin server may not have gone through the |
| 5136 | proxy where a cache entry is stored. However, several rules help |
| 5137 | reduce the likelihood of erroneous behavior. |
| 5138 | |
| 5139 | In this section, the phrase "invalidate an entity" means that the |
| 5140 | cache should either remove all instances of that entity from its |
| 5141 | storage, or should mark these as "invalid" and in need of a mandatory |
| 5142 | revalidation before they can be returned in response to a subsequent |
| 5143 | request. |
| 5144 | |
| 5145 | |
| 5146 | |
| 5147 | |
| 5148 | |
| 5149 | |
| 5150 | |
| 5151 | |
| 5152 | |
| 5153 | |
| 5154 | Fielding, et. al. Standards Track [Page 92] |
| 5155 | \f |
| 5156 | RFC 2068 HTTP/1.1 January 1997 |
| 5157 | |
| 5158 | |
| 5159 | Some HTTP methods may invalidate an entity. This is either the entity |
| 5160 | referred to by the Request-URI, or by the Location or Content- |
| 5161 | Location response-headers (if present). These methods are: |
| 5162 | |
| 5163 | o PUT |
| 5164 | o DELETE |
| 5165 | o POST |
| 5166 | |
| 5167 | In order to prevent denial of service attacks, an invalidation based |
| 5168 | on the URI in a Location or Content-Location header MUST only be |
| 5169 | performed if the host part is the same as in the Request-URI. |
| 5170 | |
| 5171 | 13.11 Write-Through Mandatory |
| 5172 | |
| 5173 | All methods that may be expected to cause modifications to the origin |
| 5174 | server's resources MUST be written through to the origin server. This |
| 5175 | currently includes all methods except for GET and HEAD. A cache MUST |
| 5176 | NOT reply to such a request from a client before having transmitted |
| 5177 | the request to the inbound server, and having received a |
| 5178 | corresponding response from the inbound server. This does not prevent |
| 5179 | a cache from sending a 100 (Continue) response before the inbound |
| 5180 | server has replied. |
| 5181 | |
| 5182 | The alternative (known as "write-back" or "copy-back" caching) is not |
| 5183 | allowed in HTTP/1.1, due to the difficulty of providing consistent |
| 5184 | updates and the problems arising from server, cache, or network |
| 5185 | failure prior to write-back. |
| 5186 | |
| 5187 | 13.12 Cache Replacement |
| 5188 | |
| 5189 | If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) |
| 5190 | response is received from a resource while any existing responses for |
| 5191 | the same resource are cached, the cache SHOULD use the new response |
| 5192 | to reply to the current request. It may insert it into cache storage |
| 5193 | and may, if it meets all other requirements, use it to respond to any |
| 5194 | future requests that would previously have caused the old response to |
| 5195 | be returned. If it inserts the new response into cache storage it |
| 5196 | should follow the rules in section 13.5.3. |
| 5197 | |
| 5198 | Note: a new response that has an older Date header value than |
| 5199 | existing cached responses is not cachable. |
| 5200 | |
| 5201 | 13.13 History Lists |
| 5202 | |
| 5203 | User agents often have history mechanisms, such as "Back" buttons and |
| 5204 | history lists, which can be used to redisplay an entity retrieved |
| 5205 | earlier in a session. |
| 5206 | |
| 5207 | |
| 5208 | |
| 5209 | |
| 5210 | Fielding, et. al. Standards Track [Page 93] |
| 5211 | \f |
| 5212 | RFC 2068 HTTP/1.1 January 1997 |
| 5213 | |
| 5214 | |
| 5215 | History mechanisms and caches are different. In particular history |
| 5216 | mechanisms SHOULD NOT try to show a semantically transparent view of |
| 5217 | the current state of a resource. Rather, a history mechanism is meant |
| 5218 | to show exactly what the user saw at the time when the resource was |
| 5219 | retrieved. |
| 5220 | |
| 5221 | By default, an expiration time does not apply to history mechanisms. |
| 5222 | If the entity is still in storage, a history mechanism should display |
| 5223 | it even if the entity has expired, unless the user has specifically |
| 5224 | configured the agent to refresh expired history documents. |
| 5225 | |
| 5226 | This should not be construed to prohibit the history mechanism from |
| 5227 | telling the user that a view may be stale. |
| 5228 | |
| 5229 | Note: if history list mechanisms unnecessarily prevent users from |
| 5230 | viewing stale resources, this will tend to force service authors to |
| 5231 | avoid using HTTP expiration controls and cache controls when they |
| 5232 | would otherwise like to. Service authors may consider it important |
| 5233 | that users not be presented with error messages or warning messages |
| 5234 | when they use navigation controls (such as BACK) to view previously |
| 5235 | fetched resources. Even though sometimes such resources ought not |
| 5236 | to cached, or ought to expire quickly, user interface |
| 5237 | considerations may force service authors to resort to other means |
| 5238 | of preventing caching (e.g. "once-only" URLs) in order not to |
| 5239 | suffer the effects of improperly functioning history mechanisms. |
| 5240 | |
| 5241 | 14 Header Field Definitions |
| 5242 | |
| 5243 | This section defines the syntax and semantics of all standard |
| 5244 | HTTP/1.1 header fields. For entity-header fields, both sender and |
| 5245 | recipient refer to either the client or the server, depending on who |
| 5246 | sends and who receives the entity. |
| 5247 | |
| 5248 | |
| 5249 | |
| 5250 | |
| 5251 | |
| 5252 | |
| 5253 | |
| 5254 | |
| 5255 | |
| 5256 | |
| 5257 | |
| 5258 | |
| 5259 | |
| 5260 | |
| 5261 | |
| 5262 | |
| 5263 | |
| 5264 | |
| 5265 | |
| 5266 | Fielding, et. al. Standards Track [Page 94] |
| 5267 | \f |
| 5268 | RFC 2068 HTTP/1.1 January 1997 |
| 5269 | |
| 5270 | |
| 5271 | 14.1 Accept |
| 5272 | |
| 5273 | The Accept request-header field can be used to specify certain media |
| 5274 | types which are acceptable for the response. Accept headers can be |
| 5275 | used to indicate that the request is specifically limited to a small |
| 5276 | set of desired types, as in the case of a request for an in-line |
| 5277 | image. |
| 5278 | |
| 5279 | Accept = "Accept" ":" |
| 5280 | #( media-range [ accept-params ] ) |
| 5281 | |
| 5282 | media-range = ( "*/*" |
| 5283 | | ( type "/" "*" ) |
| 5284 | | ( type "/" subtype ) |
| 5285 | ) *( ";" parameter ) |
| 5286 | |
| 5287 | accept-params = ";" "q" "=" qvalue *( accept-extension ) |
| 5288 | |
| 5289 | accept-extension = ";" token [ "=" ( token | quoted-string ) ] |
| 5290 | |
| 5291 | The asterisk "*" character is used to group media types into ranges, |
| 5292 | with "*/*" indicating all media types and "type/*" indicating all |
| 5293 | subtypes of that type. The media-range MAY include media type |
| 5294 | parameters that are applicable to that range. |
| 5295 | |
| 5296 | Each media-range MAY be followed by one or more accept-params, |
| 5297 | beginning with the "q" parameter for indicating a relative quality |
| 5298 | factor. The first "q" parameter (if any) separates the media-range |
| 5299 | parameter(s) from the accept-params. Quality factors allow the user |
| 5300 | or user agent to indicate the relative degree of preference for that |
| 5301 | media-range, using the qvalue scale from 0 to 1 (section 3.9). The |
| 5302 | default value is q=1. |
| 5303 | |
| 5304 | Note: Use of the "q" parameter name to separate media type |
| 5305 | parameters from Accept extension parameters is due to historical |
| 5306 | practice. Although this prevents any media type parameter named |
| 5307 | "q" from being used with a media range, such an event is believed |
| 5308 | to be unlikely given the lack of any "q" parameters in the IANA |
| 5309 | media type registry and the rare usage of any media type parameters |
| 5310 | in Accept. Future media types should be discouraged from |
| 5311 | registering any parameter named "q". |
| 5312 | |
| 5313 | The example |
| 5314 | |
| 5315 | Accept: audio/*; q=0.2, audio/basic |
| 5316 | |
| 5317 | SHOULD be interpreted as "I prefer audio/basic, but send me any audio |
| 5318 | type if it is the best available after an 80% mark-down in quality." |
| 5319 | |
| 5320 | |
| 5321 | |
| 5322 | Fielding, et. al. Standards Track [Page 95] |
| 5323 | \f |
| 5324 | RFC 2068 HTTP/1.1 January 1997 |
| 5325 | |
| 5326 | |
| 5327 | If no Accept header field is present, then it is assumed that the |
| 5328 | client accepts all media types. If an Accept header field is present, |
| 5329 | and if the server cannot send a response which is acceptable |
| 5330 | according to the combined Accept field value, then the server SHOULD |
| 5331 | send a 406 (not acceptable) response. |
| 5332 | |
| 5333 | A more elaborate example is |
| 5334 | |
| 5335 | Accept: text/plain; q=0.5, text/html, |
| 5336 | text/x-dvi; q=0.8, text/x-c |
| 5337 | |
| 5338 | Verbally, this would be interpreted as "text/html and text/x-c are |
| 5339 | the preferred media types, but if they do not exist, then send the |
| 5340 | text/x-dvi entity, and if that does not exist, send the text/plain |
| 5341 | entity." |
| 5342 | |
| 5343 | Media ranges can be overridden by more specific media ranges or |
| 5344 | specific media types. If more than one media range applies to a given |
| 5345 | type, the most specific reference has precedence. For example, |
| 5346 | |
| 5347 | Accept: text/*, text/html, text/html;level=1, */* |
| 5348 | |
| 5349 | have the following precedence: |
| 5350 | |
| 5351 | 1) text/html;level=1 |
| 5352 | 2) text/html |
| 5353 | 3) text/* |
| 5354 | 4) */* |
| 5355 | |
| 5356 | The media type quality factor associated with a given type is |
| 5357 | determined by finding the media range with the highest precedence |
| 5358 | which matches that type. For example, |
| 5359 | |
| 5360 | Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, |
| 5361 | text/html;level=2;q=0.4, */*;q=0.5 |
| 5362 | |
| 5363 | would cause the following values to be associated: |
| 5364 | |
| 5365 | text/html;level=1 = 1 |
| 5366 | text/html = 0.7 |
| 5367 | text/plain = 0.3 |
| 5368 | image/jpeg = 0.5 |
| 5369 | text/html;level=2 = 0.4 |
| 5370 | text/html;level=3 = 0.7 |
| 5371 | |
| 5372 | Note: A user agent may be provided with a default set of quality |
| 5373 | values for certain media ranges. However, unless the user agent is |
| 5374 | a closed system which cannot interact with other rendering agents, |
| 5375 | |
| 5376 | |
| 5377 | |
| 5378 | Fielding, et. al. Standards Track [Page 96] |
| 5379 | \f |
| 5380 | RFC 2068 HTTP/1.1 January 1997 |
| 5381 | |
| 5382 | |
| 5383 | this default set should be configurable by the user. |
| 5384 | |
| 5385 | 14.2 Accept-Charset |
| 5386 | |
| 5387 | The Accept-Charset request-header field can be used to indicate what |
| 5388 | character sets are acceptable for the response. This field allows |
| 5389 | clients capable of understanding more comprehensive or special- |
| 5390 | purpose character sets to signal that capability to a server which is |
| 5391 | capable of representing documents in those character sets. The ISO- |
| 5392 | 8859-1 character set can be assumed to be acceptable to all user |
| 5393 | agents. |
| 5394 | |
| 5395 | Accept-Charset = "Accept-Charset" ":" |
| 5396 | 1#( charset [ ";" "q" "=" qvalue ] ) |
| 5397 | |
| 5398 | Character set values are described in section 3.4. Each charset may |
| 5399 | be given an associated quality value which represents the user's |
| 5400 | preference for that charset. The default value is q=1. An example is |
| 5401 | |
| 5402 | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
| 5403 | |
| 5404 | If no Accept-Charset header is present, the default is that any |
| 5405 | character set is acceptable. If an Accept-Charset header is present, |
| 5406 | and if the server cannot send a response which is acceptable |
| 5407 | according to the Accept-Charset header, then the server SHOULD send |
| 5408 | an error response with the 406 (not acceptable) status code, though |
| 5409 | the sending of an unacceptable response is also allowed. |
| 5410 | |
| 5411 | 14.3 Accept-Encoding |
| 5412 | |
| 5413 | The Accept-Encoding request-header field is similar to Accept, but |
| 5414 | restricts the content-coding values (section 14.12) which are |
| 5415 | acceptable in the response. |
| 5416 | |
| 5417 | Accept-Encoding = "Accept-Encoding" ":" |
| 5418 | #( content-coding ) |
| 5419 | |
| 5420 | An example of its use is |
| 5421 | |
| 5422 | Accept-Encoding: compress, gzip |
| 5423 | |
| 5424 | If no Accept-Encoding header is present in a request, the server MAY |
| 5425 | assume that the client will accept any content coding. If an Accept- |
| 5426 | Encoding header is present, and if the server cannot send a response |
| 5427 | which is acceptable according to the Accept-Encoding header, then the |
| 5428 | server SHOULD send an error response with the 406 (Not Acceptable) |
| 5429 | status code. |
| 5430 | |
| 5431 | |
| 5432 | |
| 5433 | |
| 5434 | Fielding, et. al. Standards Track [Page 97] |
| 5435 | \f |
| 5436 | RFC 2068 HTTP/1.1 January 1997 |
| 5437 | |
| 5438 | |
| 5439 | An empty Accept-Encoding value indicates none are acceptable. |
| 5440 | |
| 5441 | 14.4 Accept-Language |
| 5442 | |
| 5443 | The Accept-Language request-header field is similar to Accept, but |
| 5444 | restricts the set of natural languages that are preferred as a |
| 5445 | response to the request. |
| 5446 | |
| 5447 | Accept-Language = "Accept-Language" ":" |
| 5448 | 1#( language-range [ ";" "q" "=" qvalue ] ) |
| 5449 | |
| 5450 | language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) |
| 5451 | |
| 5452 | Each language-range MAY be given an associated quality value which |
| 5453 | represents an estimate of the user's preference for the languages |
| 5454 | specified by that range. The quality value defaults to "q=1". For |
| 5455 | example, |
| 5456 | |
| 5457 | Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
| 5458 | |
| 5459 | would mean: "I prefer Danish, but will accept British English and |
| 5460 | other types of English." A language-range matches a language-tag if |
| 5461 | it exactly equals the tag, or if it exactly equals a prefix of the |
| 5462 | tag such that the first tag character following the prefix is "-". |
| 5463 | The special range "*", if present in the Accept-Language field, |
| 5464 | matches every tag not matched by any other range present in the |
| 5465 | Accept-Language field. |
| 5466 | |
| 5467 | Note: This use of a prefix matching rule does not imply that |
| 5468 | language tags are assigned to languages in such a way that it is |
| 5469 | always true that if a user understands a language with a certain |
| 5470 | tag, then this user will also understand all languages with tags |
| 5471 | for which this tag is a prefix. The prefix rule simply allows the |
| 5472 | use of prefix tags if this is the case. |
| 5473 | |
| 5474 | The language quality factor assigned to a language-tag by the |
| 5475 | Accept-Language field is the quality value of the longest language- |
| 5476 | range in the field that matches the language-tag. If no language- |
| 5477 | range in the field matches the tag, the language quality factor |
| 5478 | assigned is 0. If no Accept-Language header is present in the |
| 5479 | request, the server SHOULD assume that all languages are equally |
| 5480 | acceptable. If an Accept-Language header is present, then all |
| 5481 | languages which are assigned a quality factor greater than 0 are |
| 5482 | acceptable. |
| 5483 | |
| 5484 | It may be contrary to the privacy expectations of the user to send an |
| 5485 | Accept-Language header with the complete linguistic preferences of |
| 5486 | the user in every request. For a discussion of this issue, see |
| 5487 | |
| 5488 | |
| 5489 | |
| 5490 | Fielding, et. al. Standards Track [Page 98] |
| 5491 | \f |
| 5492 | RFC 2068 HTTP/1.1 January 1997 |
| 5493 | |
| 5494 | |
| 5495 | section 15.7. |
| 5496 | |
| 5497 | Note: As intelligibility is highly dependent on the individual |
| 5498 | user, it is recommended that client applications make the choice of |
| 5499 | linguistic preference available to the user. If the choice is not |
| 5500 | made available, then the Accept-Language header field must not be |
| 5501 | given in the request. |
| 5502 | |
| 5503 | 14.5 Accept-Ranges |
| 5504 | |
| 5505 | The Accept-Ranges response-header field allows the server to indicate |
| 5506 | its acceptance of range requests for a resource: |
| 5507 | |
| 5508 | Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges |
| 5509 | |
| 5510 | acceptable-ranges = 1#range-unit | "none" |
| 5511 | |
| 5512 | Origin servers that accept byte-range requests MAY send |
| 5513 | |
| 5514 | Accept-Ranges: bytes |
| 5515 | |
| 5516 | but are not required to do so. Clients MAY generate byte-range |
| 5517 | requests without having received this header for the resource |
| 5518 | involved. |
| 5519 | |
| 5520 | Servers that do not accept any kind of range request for a resource |
| 5521 | MAY send |
| 5522 | |
| 5523 | Accept-Ranges: none |
| 5524 | |
| 5525 | to advise the client not to attempt a range request. |
| 5526 | |
| 5527 | 14.6 Age |
| 5528 | |
| 5529 | The Age response-header field conveys the sender's estimate of the |
| 5530 | amount of time since the response (or its revalidation) was generated |
| 5531 | at the origin server. A cached response is "fresh" if its age does |
| 5532 | not exceed its freshness lifetime. Age values are calculated as |
| 5533 | specified in section 13.2.3. |
| 5534 | |
| 5535 | Age = "Age" ":" age-value |
| 5536 | |
| 5537 | age-value = delta-seconds |
| 5538 | |
| 5539 | Age values are non-negative decimal integers, representing time in |
| 5540 | seconds. |
| 5541 | |
| 5542 | |
| 5543 | |
| 5544 | |
| 5545 | |
| 5546 | Fielding, et. al. Standards Track [Page 99] |
| 5547 | \f |
| 5548 | RFC 2068 HTTP/1.1 January 1997 |
| 5549 | |
| 5550 | |
| 5551 | If a cache receives a value larger than the largest positive integer |
| 5552 | it can represent, or if any of its age calculations overflows, it |
| 5553 | MUST transmit an Age header with a value of 2147483648 (2^31). |
| 5554 | HTTP/1.1 caches MUST send an Age header in every response. Caches |
| 5555 | SHOULD use an arithmetic type of at least 31 bits of range. |
| 5556 | |
| 5557 | 14.7 Allow |
| 5558 | |
| 5559 | The Allow entity-header field lists the set of methods supported by |
| 5560 | the resource identified by the Request-URI. The purpose of this field |
| 5561 | is strictly to inform the recipient of valid methods associated with |
| 5562 | the resource. An Allow header field MUST be present in a 405 (Method |
| 5563 | Not Allowed) response. |
| 5564 | |
| 5565 | Allow = "Allow" ":" 1#method |
| 5566 | |
| 5567 | Example of use: |
| 5568 | |
| 5569 | Allow: GET, HEAD, PUT |
| 5570 | |
| 5571 | This field cannot prevent a client from trying other methods. |
| 5572 | However, the indications given by the Allow header field value SHOULD |
| 5573 | be followed. The actual set of allowed methods is defined by the |
| 5574 | origin server at the time of each request. |
| 5575 | |
| 5576 | The Allow header field MAY be provided with a PUT request to |
| 5577 | recommend the methods to be supported by the new or modified |
| 5578 | resource. The server is not required to support these methods and |
| 5579 | SHOULD include an Allow header in the response giving the actual |
| 5580 | supported methods. |
| 5581 | |
| 5582 | A proxy MUST NOT modify the Allow header field even if it does not |
| 5583 | understand all the methods specified, since the user agent MAY have |
| 5584 | other means of communicating with the origin server. |
| 5585 | |
| 5586 | The Allow header field does not indicate what methods are implemented |
| 5587 | at the server level. Servers MAY use the Public response-header field |
| 5588 | (section 14.35) to describe what methods are implemented on the |
| 5589 | server as a whole. |
| 5590 | |
| 5591 | 14.8 Authorization |
| 5592 | |
| 5593 | A user agent that wishes to authenticate itself with a server-- |
| 5594 | usually, but not necessarily, after receiving a 401 response--MAY do |
| 5595 | so by including an Authorization request-header field with the |
| 5596 | request. The Authorization field value consists of credentials |
| 5597 | containing the authentication information of the user agent for the |
| 5598 | realm of the resource being requested. |
| 5599 | |
| 5600 | |
| 5601 | |
| 5602 | Fielding, et. al. Standards Track [Page 100] |
| 5603 | \f |
| 5604 | RFC 2068 HTTP/1.1 January 1997 |
| 5605 | |
| 5606 | |
| 5607 | Authorization = "Authorization" ":" credentials |
| 5608 | |
| 5609 | HTTP access authentication is described in section 11. If a request |
| 5610 | is authenticated and a realm specified, the same credentials SHOULD |
| 5611 | be valid for all other requests within this realm. |
| 5612 | |
| 5613 | When a shared cache (see section 13.7) receives a request containing |
| 5614 | an Authorization field, it MUST NOT return the corresponding response |
| 5615 | as a reply to any other request, unless one of the following specific |
| 5616 | exceptions holds: |
| 5617 | |
| 5618 | 1. If the response includes the "proxy-revalidate" Cache-Control |
| 5619 | directive, the cache MAY use that response in replying to a |
| 5620 | subsequent request, but a proxy cache MUST first revalidate it with |
| 5621 | the origin server, using the request-headers from the new request |
| 5622 | to allow the origin server to authenticate the new request. |
| 5623 | 2. If the response includes the "must-revalidate" Cache-Control |
| 5624 | directive, the cache MAY use that response in replying to a |
| 5625 | subsequent request, but all caches MUST first revalidate it with |
| 5626 | the origin server, using the request-headers from the new request |
| 5627 | to allow the origin server to authenticate the new request. |
| 5628 | 3. If the response includes the "public" Cache-Control directive, it |
| 5629 | may be returned in reply to any subsequent request. |
| 5630 | |
| 5631 | 14.9 Cache-Control |
| 5632 | |
| 5633 | The Cache-Control general-header field is used to specify directives |
| 5634 | that MUST be obeyed by all caching mechanisms along the |
| 5635 | request/response chain. The directives specify behavior intended to |
| 5636 | prevent caches from adversely interfering with the request or |
| 5637 | response. These directives typically override the default caching |
| 5638 | algorithms. Cache directives are unidirectional in that the presence |
| 5639 | of a directive in a request does not imply that the same directive |
| 5640 | should be given in the response. |
| 5641 | |
| 5642 | Note that HTTP/1.0 caches may not implement Cache-Control and may |
| 5643 | only implement Pragma: no-cache (see section 14.32). |
| 5644 | |
| 5645 | Cache directives must be passed through by a proxy or gateway |
| 5646 | application, regardless of their significance to that application, |
| 5647 | since the directives may be applicable to all recipients along the |
| 5648 | request/response chain. It is not possible to specify a cache- |
| 5649 | directive for a specific cache. |
| 5650 | |
| 5651 | Cache-Control = "Cache-Control" ":" 1#cache-directive |
| 5652 | |
| 5653 | cache-directive = cache-request-directive |
| 5654 | | cache-response-directive |
| 5655 | |
| 5656 | |
| 5657 | |
| 5658 | Fielding, et. al. Standards Track [Page 101] |
| 5659 | \f |
| 5660 | RFC 2068 HTTP/1.1 January 1997 |
| 5661 | |
| 5662 | |
| 5663 | cache-request-directive = |
| 5664 | "no-cache" [ "=" <"> 1#field-name <"> ] |
| 5665 | | "no-store" |
| 5666 | | "max-age" "=" delta-seconds |
| 5667 | | "max-stale" [ "=" delta-seconds ] |
| 5668 | | "min-fresh" "=" delta-seconds |
| 5669 | | "only-if-cached" |
| 5670 | | cache-extension |
| 5671 | |
| 5672 | cache-response-directive = |
| 5673 | "public" |
| 5674 | | "private" [ "=" <"> 1#field-name <"> ] |
| 5675 | | "no-cache" [ "=" <"> 1#field-name <"> ] |
| 5676 | | "no-store" |
| 5677 | | "no-transform" |
| 5678 | | "must-revalidate" |
| 5679 | | "proxy-revalidate" |
| 5680 | | "max-age" "=" delta-seconds |
| 5681 | | cache-extension |
| 5682 | |
| 5683 | cache-extension = token [ "=" ( token | quoted-string ) ] |
| 5684 | |
| 5685 | When a directive appears without any 1#field-name parameter, the |
| 5686 | directive applies to the entire request or response. When such a |
| 5687 | directive appears with a 1#field-name parameter, it applies only to |
| 5688 | the named field or fields, and not to the rest of the request or |
| 5689 | response. This mechanism supports extensibility; implementations of |
| 5690 | future versions of the HTTP protocol may apply these directives to |
| 5691 | header fields not defined in HTTP/1.1. |
| 5692 | |
| 5693 | The cache-control directives can be broken down into these general |
| 5694 | categories: |
| 5695 | |
| 5696 | o Restrictions on what is cachable; these may only be imposed by the |
| 5697 | origin server. |
| 5698 | o Restrictions on what may be stored by a cache; these may be imposed |
| 5699 | by either the origin server or the user agent. |
| 5700 | o Modifications of the basic expiration mechanism; these may be |
| 5701 | imposed by either the origin server or the user agent. |
| 5702 | o Controls over cache revalidation and reload; these may only be |
| 5703 | imposed by a user agent. |
| 5704 | o Control over transformation of entities. |
| 5705 | o Extensions to the caching system. |
| 5706 | |
| 5707 | |
| 5708 | |
| 5709 | |
| 5710 | |
| 5711 | |
| 5712 | |
| 5713 | |
| 5714 | Fielding, et. al. Standards Track [Page 102] |
| 5715 | \f |
| 5716 | RFC 2068 HTTP/1.1 January 1997 |
| 5717 | |
| 5718 | |
| 5719 | 14.9.1 What is Cachable |
| 5720 | |
| 5721 | By default, a response is cachable if the requirements of the request |
| 5722 | method, request header fields, and the response status indicate that |
| 5723 | it is cachable. Section 13.4 summarizes these defaults for |
| 5724 | cachability. The following Cache-Control response directives allow an |
| 5725 | origin server to override the default cachability of a response: |
| 5726 | |
| 5727 | public |
| 5728 | Indicates that the response is cachable by any cache, even if it |
| 5729 | would normally be non-cachable or cachable only within a non-shared |
| 5730 | cache. (See also Authorization, section 14.8, for additional |
| 5731 | details.) |
| 5732 | |
| 5733 | private |
| 5734 | Indicates that all or part of the response message is intended for a |
| 5735 | single user and MUST NOT be cached by a shared cache. This allows an |
| 5736 | origin server to state that the specified parts of the response are |
| 5737 | intended for only one user and are not a valid response for requests |
| 5738 | by other users. A private (non-shared) cache may cache the response. |
| 5739 | |
| 5740 | Note: This usage of the word private only controls where the |
| 5741 | response may be cached, and cannot ensure the privacy of the |
| 5742 | message content. |
| 5743 | |
| 5744 | no-cache |
| 5745 | Indicates that all or part of the response message MUST NOT be cached |
| 5746 | anywhere. This allows an origin server to prevent caching even by |
| 5747 | caches that have been configured to return stale responses to client |
| 5748 | requests. |
| 5749 | |
| 5750 | Note: Most HTTP/1.0 caches will not recognize or obey this |
| 5751 | directive. |
| 5752 | |
| 5753 | 14.9.2 What May be Stored by Caches |
| 5754 | |
| 5755 | The purpose of the no-store directive is to prevent the inadvertent |
| 5756 | release or retention of sensitive information (for example, on backup |
| 5757 | tapes). The no-store directive applies to the entire message, and may |
| 5758 | be sent either in a response or in a request. If sent in a request, a |
| 5759 | cache MUST NOT store any part of either this request or any response |
| 5760 | to it. If sent in a response, a cache MUST NOT store any part of |
| 5761 | either this response or the request that elicited it. This directive |
| 5762 | applies to both non-shared and shared caches. "MUST NOT store" in |
| 5763 | this context means that the cache MUST NOT intentionally store the |
| 5764 | information in non-volatile storage, and MUST make a best-effort |
| 5765 | attempt to remove the information from volatile storage as promptly |
| 5766 | as possible after forwarding it. |
| 5767 | |
| 5768 | |
| 5769 | |
| 5770 | Fielding, et. al. Standards Track [Page 103] |
| 5771 | \f |
| 5772 | RFC 2068 HTTP/1.1 January 1997 |
| 5773 | |
| 5774 | |
| 5775 | Even when this directive is associated with a response, users may |
| 5776 | explicitly store such a response outside of the caching system (e.g., |
| 5777 | with a "Save As" dialog). History buffers may store such responses as |
| 5778 | part of their normal operation. |
| 5779 | |
| 5780 | The purpose of this directive is to meet the stated requirements of |
| 5781 | certain users and service authors who are concerned about accidental |
| 5782 | releases of information via unanticipated accesses to cache data |
| 5783 | structures. While the use of this directive may improve privacy in |
| 5784 | some cases, we caution that it is NOT in any way a reliable or |
| 5785 | sufficient mechanism for ensuring privacy. In particular, malicious |
| 5786 | or compromised caches may not recognize or obey this directive; and |
| 5787 | communications networks may be vulnerable to eavesdropping. |
| 5788 | |
| 5789 | 14.9.3 Modifications of the Basic Expiration Mechanism |
| 5790 | |
| 5791 | The expiration time of an entity may be specified by the origin |
| 5792 | server using the Expires header (see section 14.21). Alternatively, |
| 5793 | it may be specified using the max-age directive in a response. |
| 5794 | |
| 5795 | If a response includes both an Expires header and a max-age |
| 5796 | directive, the max-age directive overrides the Expires header, even |
| 5797 | if the Expires header is more restrictive. This rule allows an origin |
| 5798 | server to provide, for a given response, a longer expiration time to |
| 5799 | an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be |
| 5800 | useful if certain HTTP/1.0 caches improperly calculate ages or |
| 5801 | expiration times, perhaps due to desynchronized clocks. |
| 5802 | |
| 5803 | Note: most older caches, not compliant with this specification, do |
| 5804 | not implement any Cache-Control directives. An origin server |
| 5805 | wishing to use a Cache-Control directive that restricts, but does |
| 5806 | not prevent, caching by an HTTP/1.1-compliant cache may exploit the |
| 5807 | requirement that the max-age directive overrides the Expires |
| 5808 | header, and the fact that non-HTTP/1.1-compliant caches do not |
| 5809 | observe the max-age directive. |
| 5810 | |
| 5811 | Other directives allow an user agent to modify the basic expiration |
| 5812 | mechanism. These directives may be specified on a request: |
| 5813 | |
| 5814 | max-age |
| 5815 | Indicates that the client is willing to accept a response whose age |
| 5816 | is no greater than the specified time in seconds. Unless max-stale |
| 5817 | directive is also included, the client is not willing to accept a |
| 5818 | stale response. |
| 5819 | |
| 5820 | min-fresh |
| 5821 | Indicates that the client is willing to accept a response whose |
| 5822 | freshness lifetime is no less than its current age plus the |
| 5823 | |
| 5824 | |
| 5825 | |
| 5826 | Fielding, et. al. Standards Track [Page 104] |
| 5827 | \f |
| 5828 | RFC 2068 HTTP/1.1 January 1997 |
| 5829 | |
| 5830 | |
| 5831 | specified time in seconds. That is, the client wants a response |
| 5832 | that will still be fresh for at least the specified number of |
| 5833 | seconds. |
| 5834 | |
| 5835 | max-stale |
| 5836 | Indicates that the client is willing to accept a response that has |
| 5837 | exceeded its expiration time. If max-stale is assigned a value, |
| 5838 | then the client is willing to accept a response that has exceeded |
| 5839 | its expiration time by no more than the specified number of |
| 5840 | seconds. If no value is assigned to max-stale, then the client is |
| 5841 | willing to accept a stale response of any age. |
| 5842 | |
| 5843 | If a cache returns a stale response, either because of a max-stale |
| 5844 | directive on a request, or because the cache is configured to |
| 5845 | override the expiration time of a response, the cache MUST attach a |
| 5846 | Warning header to the stale response, using Warning 10 (Response is |
| 5847 | stale). |
| 5848 | |
| 5849 | 14.9.4 Cache Revalidation and Reload Controls |
| 5850 | |
| 5851 | Sometimes an user agent may want or need to insist that a cache |
| 5852 | revalidate its cache entry with the origin server (and not just with |
| 5853 | the next cache along the path to the origin server), or to reload its |
| 5854 | cache entry from the origin server. End-to-end revalidation may be |
| 5855 | necessary if either the cache or the origin server has overestimated |
| 5856 | the expiration time of the cached response. End-to-end reload may be |
| 5857 | necessary if the cache entry has become corrupted for some reason. |
| 5858 | |
| 5859 | End-to-end revalidation may be requested either when the client does |
| 5860 | not have its own local cached copy, in which case we call it |
| 5861 | "unspecified end-to-end revalidation", or when the client does have a |
| 5862 | local cached copy, in which case we call it "specific end-to-end |
| 5863 | revalidation." |
| 5864 | |
| 5865 | The client can specify these three kinds of action using Cache- |
| 5866 | Control request directives: |
| 5867 | |
| 5868 | End-to-end reload |
| 5869 | The request includes a "no-cache" Cache-Control directive or, for |
| 5870 | compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field |
| 5871 | names may be included with the no-cache directive in a request. The |
| 5872 | server MUST NOT use a cached copy when responding to such a |
| 5873 | request. |
| 5874 | |
| 5875 | Specific end-to-end revalidation |
| 5876 | The request includes a "max-age=0" Cache-Control directive, which |
| 5877 | forces each cache along the path to the origin server to revalidate |
| 5878 | its own entry, if any, with the next cache or server. The initial |
| 5879 | |
| 5880 | |
| 5881 | |
| 5882 | Fielding, et. al. Standards Track [Page 105] |
| 5883 | \f |
| 5884 | RFC 2068 HTTP/1.1 January 1997 |
| 5885 | |
| 5886 | |
| 5887 | request includes a cache-validating conditional with the client's |
| 5888 | current validator. |
| 5889 | |
| 5890 | Unspecified end-to-end revalidation |
| 5891 | The request includes "max-age=0" Cache-Control directive, which |
| 5892 | forces each cache along the path to the origin server to revalidate |
| 5893 | its own entry, if any, with the next cache or server. The initial |
| 5894 | request does not include a cache-validating conditional; the first |
| 5895 | cache along the path (if any) that holds a cache entry for this |
| 5896 | resource includes a cache-validating conditional with its current |
| 5897 | validator. |
| 5898 | |
| 5899 | When an intermediate cache is forced, by means of a max-age=0 |
| 5900 | directive, to revalidate its own cache entry, and the client has |
| 5901 | supplied its own validator in the request, the supplied validator may |
| 5902 | differ from the validator currently stored with the cache entry. In |
| 5903 | this case, the cache may use either validator in making its own |
| 5904 | request without affecting semantic transparency. |
| 5905 | |
| 5906 | However, the choice of validator may affect performance. The best |
| 5907 | approach is for the intermediate cache to use its own validator when |
| 5908 | making its request. If the server replies with 304 (Not Modified), |
| 5909 | then the cache should return its now validated copy to the client |
| 5910 | with a 200 (OK) response. If the server replies with a new entity and |
| 5911 | cache validator, however, the intermediate cache should compare the |
| 5912 | returned validator with the one provided in the client's request, |
| 5913 | using the strong comparison function. If the client's validator is |
| 5914 | equal to the origin server's, then the intermediate cache simply |
| 5915 | returns 304 (Not Modified). Otherwise, it returns the new entity with |
| 5916 | a 200 (OK) response. |
| 5917 | |
| 5918 | If a request includes the no-cache directive, it should not include |
| 5919 | min-fresh, max-stale, or max-age. |
| 5920 | |
| 5921 | In some cases, such as times of extremely poor network connectivity, |
| 5922 | a client may want a cache to return only those responses that it |
| 5923 | currently has stored, and not to reload or revalidate with the origin |
| 5924 | server. To do this, the client may include the only-if-cached |
| 5925 | directive in a request. If it receives this directive, a cache SHOULD |
| 5926 | either respond using a cached entry that is consistent with the other |
| 5927 | constraints of the request, or respond with a 504 (Gateway Timeout) |
| 5928 | status. However, if a group of caches is being operated as a unified |
| 5929 | system with good internal connectivity, such a request MAY be |
| 5930 | forwarded within that group of caches. |
| 5931 | |
| 5932 | Because a cache may be configured to ignore a server's specified |
| 5933 | expiration time, and because a client request may include a max-stale |
| 5934 | directive (which has a similar effect), the protocol also includes a |
| 5935 | |
| 5936 | |
| 5937 | |
| 5938 | Fielding, et. al. Standards Track [Page 106] |
| 5939 | \f |
| 5940 | RFC 2068 HTTP/1.1 January 1997 |
| 5941 | |
| 5942 | |
| 5943 | mechanism for the origin server to require revalidation of a cache |
| 5944 | entry on any subsequent use. When the must-revalidate directive is |
| 5945 | present in a response received by a cache, that cache MUST NOT use |
| 5946 | the entry after it becomes stale to respond to a subsequent request |
| 5947 | without first revalidating it with the origin server. (I.e., the |
| 5948 | cache must do an end-to-end revalidation every time, if, based solely |
| 5949 | on the origin server's Expires or max-age value, the cached response |
| 5950 | is stale.) |
| 5951 | |
| 5952 | The must-revalidate directive is necessary to support reliable |
| 5953 | operation for certain protocol features. In all circumstances an |
| 5954 | HTTP/1.1 cache MUST obey the must-revalidate directive; in |
| 5955 | particular, if the cache cannot reach the origin server for any |
| 5956 | reason, it MUST generate a 504 (Gateway Timeout) response. |
| 5957 | |
| 5958 | Servers should send the must-revalidate directive if and only if |
| 5959 | failure to revalidate a request on the entity could result in |
| 5960 | incorrect operation, such as a silently unexecuted financial |
| 5961 | transaction. Recipients MUST NOT take any automated action that |
| 5962 | violates this directive, and MUST NOT automatically provide an |
| 5963 | unvalidated copy of the entity if revalidation fails. |
| 5964 | |
| 5965 | Although this is not recommended, user agents operating under severe |
| 5966 | connectivity constraints may violate this directive but, if so, MUST |
| 5967 | explicitly warn the user that an unvalidated response has been |
| 5968 | provided. The warning MUST be provided on each unvalidated access, |
| 5969 | and SHOULD require explicit user confirmation. |
| 5970 | |
| 5971 | The proxy-revalidate directive has the same meaning as the must- |
| 5972 | revalidate directive, except that it does not apply to non-shared |
| 5973 | user agent caches. It can be used on a response to an authenticated |
| 5974 | request to permit the user's cache to store and later return the |
| 5975 | response without needing to revalidate it (since it has already been |
| 5976 | authenticated once by that user), while still requiring proxies that |
| 5977 | service many users to revalidate each time (in order to make sure |
| 5978 | that each user has been authenticated). Note that such authenticated |
| 5979 | responses also need the public cache control directive in order to |
| 5980 | allow them to be cached at all. |
| 5981 | |
| 5982 | 14.9.5 No-Transform Directive |
| 5983 | |
| 5984 | Implementers of intermediate caches (proxies) have found it useful to |
| 5985 | convert the media type of certain entity bodies. A proxy might, for |
| 5986 | example, convert between image formats in order to save cache space |
| 5987 | or to reduce the amount of traffic on a slow link. HTTP has to date |
| 5988 | been silent on these transformations. |
| 5989 | |
| 5990 | |
| 5991 | |
| 5992 | |
| 5993 | |
| 5994 | Fielding, et. al. Standards Track [Page 107] |
| 5995 | \f |
| 5996 | RFC 2068 HTTP/1.1 January 1997 |
| 5997 | |
| 5998 | |
| 5999 | Serious operational problems have already occurred, however, when |
| 6000 | these transformations have been applied to entity bodies intended for |
| 6001 | certain kinds of applications. For example, applications for medical |
| 6002 | imaging, scientific data analysis and those using end-to-end |
| 6003 | authentication, all depend on receiving an entity body that is bit |
| 6004 | for bit identical to the original entity-body. |
| 6005 | |
| 6006 | Therefore, if a response includes the no-transform directive, an |
| 6007 | intermediate cache or proxy MUST NOT change those headers that are |
| 6008 | listed in section 13.5.2 as being subject to the no-transform |
| 6009 | directive. This implies that the cache or proxy must not change any |
| 6010 | aspect of the entity-body that is specified by these headers. |
| 6011 | |
| 6012 | 14.9.6 Cache Control Extensions |
| 6013 | |
| 6014 | The Cache-Control header field can be extended through the use of one |
| 6015 | or more cache-extension tokens, each with an optional assigned value. |
| 6016 | Informational extensions (those which do not require a change in |
| 6017 | cache behavior) may be added without changing the semantics of other |
| 6018 | directives. Behavioral extensions are designed to work by acting as |
| 6019 | modifiers to the existing base of cache directives. Both the new |
| 6020 | directive and the standard directive are supplied, such that |
| 6021 | applications which do not understand the new directive will default |
| 6022 | to the behavior specified by the standard directive, and those that |
| 6023 | understand the new directive will recognize it as modifying the |
| 6024 | requirements associated with the standard directive. In this way, |
| 6025 | extensions to the Cache-Control directives can be made without |
| 6026 | requiring changes to the base protocol. |
| 6027 | |
| 6028 | This extension mechanism depends on a HTTP cache obeying all of the |
| 6029 | cache-control directives defined for its native HTTP-version, obeying |
| 6030 | certain extensions, and ignoring all directives that it does not |
| 6031 | understand. |
| 6032 | |
| 6033 | For example, consider a hypothetical new response directive called |
| 6034 | "community" which acts as a modifier to the "private" directive. We |
| 6035 | define this new directive to mean that, in addition to any non-shared |
| 6036 | cache, any cache which is shared only by members of the community |
| 6037 | named within its value may cache the response. An origin server |
| 6038 | wishing to allow the "UCI" community to use an otherwise private |
| 6039 | response in their shared cache(s) may do so by including |
| 6040 | |
| 6041 | Cache-Control: private, community="UCI" |
| 6042 | |
| 6043 | A cache seeing this header field will act correctly even if the cache |
| 6044 | does not understand the "community" cache-extension, since it will |
| 6045 | also see and understand the "private" directive and thus default to |
| 6046 | the safe behavior. |
| 6047 | |
| 6048 | |
| 6049 | |
| 6050 | Fielding, et. al. Standards Track [Page 108] |
| 6051 | \f |
| 6052 | RFC 2068 HTTP/1.1 January 1997 |
| 6053 | |
| 6054 | |
| 6055 | Unrecognized cache-directives MUST be ignored; it is assumed that any |
| 6056 | cache-directive likely to be unrecognized by an HTTP/1.1 cache will |
| 6057 | be combined with standard directives (or the response's default |
| 6058 | cachability) such that the cache behavior will remain minimally |
| 6059 | correct even if the cache does not understand the extension(s). |
| 6060 | |
| 6061 | 14.10 Connection |
| 6062 | |
| 6063 | The Connection general-header field allows the sender to specify |
| 6064 | options that are desired for that particular connection and MUST NOT |
| 6065 | be communicated by proxies over further connections. |
| 6066 | |
| 6067 | The Connection header has the following grammar: |
| 6068 | |
| 6069 | Connection-header = "Connection" ":" 1#(connection-token) |
| 6070 | connection-token = token |
| 6071 | |
| 6072 | HTTP/1.1 proxies MUST parse the Connection header field before a |
| 6073 | message is forwarded and, for each connection-token in this field, |
| 6074 | remove any header field(s) from the message with the same name as the |
| 6075 | connection-token. Connection options are signaled by the presence of |
| 6076 | a connection-token in the Connection header field, not by any |
| 6077 | corresponding additional header field(s), since the additional header |
| 6078 | field may not be sent if there are no parameters associated with that |
| 6079 | connection option. HTTP/1.1 defines the "close" connection option |
| 6080 | for the sender to signal that the connection will be closed after |
| 6081 | completion of the response. For example, |
| 6082 | |
| 6083 | Connection: close |
| 6084 | |
| 6085 | in either the request or the response header fields indicates that |
| 6086 | the connection should not be considered `persistent' (section 8.1) |
| 6087 | after the current request/response is complete. |
| 6088 | |
| 6089 | HTTP/1.1 applications that do not support persistent connections MUST |
| 6090 | include the "close" connection option in every message. |
| 6091 | |
| 6092 | 14.11 Content-Base |
| 6093 | |
| 6094 | The Content-Base entity-header field may be used to specify the base |
| 6095 | URI for resolving relative URLs within the entity. This header field |
| 6096 | is described as Base in RFC 1808, which is expected to be revised. |
| 6097 | |
| 6098 | Content-Base = "Content-Base" ":" absoluteURI |
| 6099 | |
| 6100 | If no Content-Base field is present, the base URI of an entity is |
| 6101 | defined either by its Content-Location (if that Content-Location URI |
| 6102 | is an absolute URI) or the URI used to initiate the request, in that |
| 6103 | |
| 6104 | |
| 6105 | |
| 6106 | Fielding, et. al. Standards Track [Page 109] |
| 6107 | \f |
| 6108 | RFC 2068 HTTP/1.1 January 1997 |
| 6109 | |
| 6110 | |
| 6111 | order of precedence. Note, however, that the base URI of the contents |
| 6112 | within the entity-body may be redefined within that entity-body. |
| 6113 | |
| 6114 | 14.12 Content-Encoding |
| 6115 | |
| 6116 | The Content-Encoding entity-header field is used as a modifier to the |
| 6117 | media-type. When present, its value indicates what additional content |
| 6118 | codings have been applied to the entity-body, and thus what decoding |
| 6119 | mechanisms MUST be applied in order to obtain the media-type |
| 6120 | referenced by the Content-Type header field. Content-Encoding is |
| 6121 | primarily used to allow a document to be compressed without losing |
| 6122 | the identity of its underlying media type. |
| 6123 | |
| 6124 | Content-Encoding = "Content-Encoding" ":" 1#content-coding |
| 6125 | |
| 6126 | Content codings are defined in section 3.5. An example of its use is |
| 6127 | |
| 6128 | Content-Encoding: gzip |
| 6129 | |
| 6130 | The Content-Encoding is a characteristic of the entity identified by |
| 6131 | the Request-URI. Typically, the entity-body is stored with this |
| 6132 | encoding and is only decoded before rendering or analogous usage. |
| 6133 | |
| 6134 | If multiple encodings have been applied to an entity, the content |
| 6135 | codings MUST be listed in the order in which they were applied. |
| 6136 | |
| 6137 | Additional information about the encoding parameters MAY be provided |
| 6138 | by other entity-header fields not defined by this specification. |
| 6139 | |
| 6140 | 14.13 Content-Language |
| 6141 | |
| 6142 | The Content-Language entity-header field describes the natural |
| 6143 | language(s) of the intended audience for the enclosed entity. Note |
| 6144 | that this may not be equivalent to all the languages used within the |
| 6145 | entity-body. |
| 6146 | |
| 6147 | Content-Language = "Content-Language" ":" 1#language-tag |
| 6148 | |
| 6149 | Language tags are defined in section 3.10. The primary purpose of |
| 6150 | Content-Language is to allow a user to identify and differentiate |
| 6151 | entities according to the user's own preferred language. Thus, if the |
| 6152 | body content is intended only for a Danish-literate audience, the |
| 6153 | appropriate field is |
| 6154 | |
| 6155 | Content-Language: da |
| 6156 | |
| 6157 | If no Content-Language is specified, the default is that the content |
| 6158 | is intended for all language audiences. This may mean that the sender |
| 6159 | |
| 6160 | |
| 6161 | |
| 6162 | Fielding, et. al. Standards Track [Page 110] |
| 6163 | \f |
| 6164 | RFC 2068 HTTP/1.1 January 1997 |
| 6165 | |
| 6166 | |
| 6167 | does not consider it to be specific to any natural language, or that |
| 6168 | the sender does not know for which language it is intended. |
| 6169 | |
| 6170 | Multiple languages MAY be listed for content that is intended for |
| 6171 | multiple audiences. For example, a rendition of the "Treaty of |
| 6172 | Waitangi," presented simultaneously in the original Maori and English |
| 6173 | versions, would call for |
| 6174 | |
| 6175 | Content-Language: mi, en |
| 6176 | |
| 6177 | However, just because multiple languages are present within an entity |
| 6178 | does not mean that it is intended for multiple linguistic audiences. |
| 6179 | An example would be a beginner's language primer, such as "A First |
| 6180 | Lesson in Latin," which is clearly intended to be used by an |
| 6181 | English-literate audience. In this case, the Content-Language should |
| 6182 | only include "en". |
| 6183 | |
| 6184 | Content-Language may be applied to any media type -- it is not |
| 6185 | limited to textual documents. |
| 6186 | |
| 6187 | 14.14 Content-Length |
| 6188 | |
| 6189 | The Content-Length entity-header field indicates the size of the |
| 6190 | message-body, in decimal number of octets, sent to the recipient or, |
| 6191 | in the case of the HEAD method, the size of the entity-body that |
| 6192 | would have been sent had the request been a GET. |
| 6193 | |
| 6194 | Content-Length = "Content-Length" ":" 1*DIGIT |
| 6195 | |
| 6196 | An example is |
| 6197 | |
| 6198 | Content-Length: 3495 |
| 6199 | |
| 6200 | Applications SHOULD use this field to indicate the size of the |
| 6201 | message-body to be transferred, regardless of the media type of the |
| 6202 | entity. It must be possible for the recipient to reliably determine |
| 6203 | the end of HTTP/1.1 requests containing an entity-body, e.g., because |
| 6204 | the request has a valid Content-Length field, uses Transfer-Encoding: |
| 6205 | chunked or a multipart body. |
| 6206 | |
| 6207 | Any Content-Length greater than or equal to zero is a valid value. |
| 6208 | Section 4.4 describes how to determine the length of a message-body |
| 6209 | if a Content-Length is not given. |
| 6210 | |
| 6211 | |
| 6212 | |
| 6213 | |
| 6214 | |
| 6215 | |
| 6216 | |
| 6217 | |
| 6218 | Fielding, et. al. Standards Track [Page 111] |
| 6219 | \f |
| 6220 | RFC 2068 HTTP/1.1 January 1997 |
| 6221 | |
| 6222 | |
| 6223 | Note: The meaning of this field is significantly different from the |
| 6224 | corresponding definition in MIME, where it is an optional field |
| 6225 | used within the "message/external-body" content-type. In HTTP, it |
| 6226 | SHOULD be sent whenever the message's length can be determined |
| 6227 | prior to being transferred. |
| 6228 | |
| 6229 | 14.15 Content-Location |
| 6230 | |
| 6231 | The Content-Location entity-header field may be used to supply the |
| 6232 | resource location for the entity enclosed in the message. In the case |
| 6233 | where a resource has multiple entities associated with it, and those |
| 6234 | entities actually have separate locations by which they might be |
| 6235 | individually accessed, the server should provide a Content-Location |
| 6236 | for the particular variant which is returned. In addition, a server |
| 6237 | SHOULD provide a Content-Location for the resource corresponding to |
| 6238 | the response entity. |
| 6239 | |
| 6240 | Content-Location = "Content-Location" ":" |
| 6241 | ( absoluteURI | relativeURI ) |
| 6242 | |
| 6243 | If no Content-Base header field is present, the value of Content- |
| 6244 | Location also defines the base URL for the entity (see section |
| 6245 | 14.11). |
| 6246 | |
| 6247 | The Content-Location value is not a replacement for the original |
| 6248 | requested URI; it is only a statement of the location of the resource |
| 6249 | corresponding to this particular entity at the time of the request. |
| 6250 | Future requests MAY use the Content-Location URI if the desire is to |
| 6251 | identify the source of that particular entity. |
| 6252 | |
| 6253 | A cache cannot assume that an entity with a Content-Location |
| 6254 | different from the URI used to retrieve it can be used to respond to |
| 6255 | later requests on that Content-Location URI. However, the Content- |
| 6256 | Location can be used to differentiate between multiple entities |
| 6257 | retrieved from a single requested resource, as described in section |
| 6258 | 13.6. |
| 6259 | |
| 6260 | If the Content-Location is a relative URI, the URI is interpreted |
| 6261 | relative to any Content-Base URI provided in the response. If no |
| 6262 | Content-Base is provided, the relative URI is interpreted relative to |
| 6263 | the Request-URI. |
| 6264 | |
| 6265 | |
| 6266 | |
| 6267 | |
| 6268 | |
| 6269 | |
| 6270 | |
| 6271 | |
| 6272 | |
| 6273 | |
| 6274 | Fielding, et. al. Standards Track [Page 112] |
| 6275 | \f |
| 6276 | RFC 2068 HTTP/1.1 January 1997 |
| 6277 | |
| 6278 | |
| 6279 | 14.16 Content-MD5 |
| 6280 | |
| 6281 | The Content-MD5 entity-header field, as defined in RFC 1864 [23], is |
| 6282 | an MD5 digest of the entity-body for the purpose of providing an |
| 6283 | end-to-end message integrity check (MIC) of the entity-body. (Note: a |
| 6284 | MIC is good for detecting accidental modification of the entity-body |
| 6285 | in transit, but is not proof against malicious attacks.) |
| 6286 | |
| 6287 | Content-MD5 = "Content-MD5" ":" md5-digest |
| 6288 | |
| 6289 | md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> |
| 6290 | |
| 6291 | The Content-MD5 header field may be generated by an origin server to |
| 6292 | function as an integrity check of the entity-body. Only origin |
| 6293 | servers may generate the Content-MD5 header field; proxies and |
| 6294 | gateways MUST NOT generate it, as this would defeat its value as an |
| 6295 | end-to-end integrity check. Any recipient of the entity-body, |
| 6296 | including gateways and proxies, MAY check that the digest value in |
| 6297 | this header field matches that of the entity-body as received. |
| 6298 | |
| 6299 | The MD5 digest is computed based on the content of the entity-body, |
| 6300 | including any Content-Encoding that has been applied, but not |
| 6301 | including any Transfer-Encoding that may have been applied to the |
| 6302 | message-body. If the message is received with a Transfer-Encoding, |
| 6303 | that encoding must be removed prior to checking the Content-MD5 value |
| 6304 | against the received entity. |
| 6305 | |
| 6306 | This has the result that the digest is computed on the octets of the |
| 6307 | entity-body exactly as, and in the order that, they would be sent if |
| 6308 | no Transfer-Encoding were being applied. |
| 6309 | |
| 6310 | HTTP extends RFC 1864 to permit the digest to be computed for MIME |
| 6311 | composite media-types (e.g., multipart/* and message/rfc822), but |
| 6312 | this does not change how the digest is computed as defined in the |
| 6313 | preceding paragraph. |
| 6314 | |
| 6315 | Note: There are several consequences of this. The entity-body for |
| 6316 | composite types may contain many body-parts, each with its own MIME |
| 6317 | and HTTP headers (including Content-MD5, Content-Transfer-Encoding, |
| 6318 | and Content-Encoding headers). If a body-part has a Content- |
| 6319 | Transfer-Encoding or Content-Encoding header, it is assumed that |
| 6320 | the content of the body-part has had the encoding applied, and the |
| 6321 | body-part is included in the Content-MD5 digest as is -- i.e., |
| 6322 | after the application. The Transfer-Encoding header field is not |
| 6323 | allowed within body-parts. |
| 6324 | |
| 6325 | Note: while the definition of Content-MD5 is exactly the same for |
| 6326 | HTTP as in RFC 1864 for MIME entity-bodies, there are several ways |
| 6327 | |
| 6328 | |
| 6329 | |
| 6330 | Fielding, et. al. Standards Track [Page 113] |
| 6331 | \f |
| 6332 | RFC 2068 HTTP/1.1 January 1997 |
| 6333 | |
| 6334 | |
| 6335 | in which the application of Content-MD5 to HTTP entity-bodies |
| 6336 | differs from its application to MIME entity-bodies. One is that |
| 6337 | HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does |
| 6338 | use Transfer-Encoding and Content-Encoding. Another is that HTTP |
| 6339 | more frequently uses binary content types than MIME, so it is worth |
| 6340 | noting that, in such cases, the byte order used to compute the |
| 6341 | digest is the transmission byte order defined for the type. Lastly, |
| 6342 | HTTP allows transmission of text types with any of several line |
| 6343 | break conventions and not just the canonical form using CRLF. |
| 6344 | Conversion of all line breaks to CRLF should not be done before |
| 6345 | computing or checking the digest: the line break convention used in |
| 6346 | the text actually transmitted should be left unaltered when |
| 6347 | computing the digest. |
| 6348 | |
| 6349 | 14.17 Content-Range |
| 6350 | |
| 6351 | The Content-Range entity-header is sent with a partial entity-body to |
| 6352 | specify where in the full entity-body the partial body should be |
| 6353 | inserted. It also indicates the total size of the full entity-body. |
| 6354 | When a server returns a partial response to a client, it must |
| 6355 | describe both the extent of the range covered by the response, and |
| 6356 | the length of the entire entity-body. |
| 6357 | |
| 6358 | Content-Range = "Content-Range" ":" content-range-spec |
| 6359 | |
| 6360 | content-range-spec = byte-content-range-spec |
| 6361 | |
| 6362 | byte-content-range-spec = bytes-unit SP first-byte-pos "-" |
| 6363 | last-byte-pos "/" entity-length |
| 6364 | |
| 6365 | entity-length = 1*DIGIT |
| 6366 | |
| 6367 | Unlike byte-ranges-specifier values, a byte-content-range-spec may |
| 6368 | only specify one range, and must contain absolute byte positions for |
| 6369 | both the first and last byte of the range. |
| 6370 | |
| 6371 | A byte-content-range-spec whose last-byte-pos value is less than its |
| 6372 | first-byte-pos value, or whose entity-length value is less than or |
| 6373 | equal to its last-byte-pos value, is invalid. The recipient of an |
| 6374 | invalid byte-content-range-spec MUST ignore it and any content |
| 6375 | transferred along with it. |
| 6376 | |
| 6377 | |
| 6378 | |
| 6379 | |
| 6380 | |
| 6381 | |
| 6382 | |
| 6383 | |
| 6384 | |
| 6385 | |
| 6386 | Fielding, et. al. Standards Track [Page 114] |
| 6387 | \f |
| 6388 | RFC 2068 HTTP/1.1 January 1997 |
| 6389 | |
| 6390 | |
| 6391 | Examples of byte-content-range-spec values, assuming that the entity |
| 6392 | contains a total of 1234 bytes: |
| 6393 | |
| 6394 | o The first 500 bytes: |
| 6395 | |
| 6396 | bytes 0-499/1234 |
| 6397 | |
| 6398 | o The second 500 bytes: |
| 6399 | |
| 6400 | bytes 500-999/1234 |
| 6401 | |
| 6402 | o All except for the first 500 bytes: |
| 6403 | |
| 6404 | bytes 500-1233/1234 |
| 6405 | |
| 6406 | o The last 500 bytes: |
| 6407 | |
| 6408 | bytes 734-1233/1234 |
| 6409 | |
| 6410 | When an HTTP message includes the content of a single range (for |
| 6411 | example, a response to a request for a single range, or to a request |
| 6412 | for a set of ranges that overlap without any holes), this content is |
| 6413 | transmitted with a Content-Range header, and a Content-Length header |
| 6414 | showing the number of bytes actually transferred. For example, |
| 6415 | |
| 6416 | HTTP/1.1 206 Partial content |
| 6417 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
| 6418 | Last-modified: Wed, 15 Nov 1995 04:58:08 GMT |
| 6419 | Content-Range: bytes 21010-47021/47022 |
| 6420 | Content-Length: 26012 |
| 6421 | Content-Type: image/gif |
| 6422 | |
| 6423 | When an HTTP message includes the content of multiple ranges (for |
| 6424 | example, a response to a request for multiple non-overlapping |
| 6425 | ranges), these are transmitted as a multipart MIME message. The |
| 6426 | multipart MIME content-type used for this purpose is defined in this |
| 6427 | specification to be "multipart/byteranges". See appendix 19.2 for its |
| 6428 | definition. |
| 6429 | |
| 6430 | A client that cannot decode a MIME multipart/byteranges message |
| 6431 | should not ask for multiple byte-ranges in a single request. |
| 6432 | |
| 6433 | When a client requests multiple byte-ranges in one request, the |
| 6434 | server SHOULD return them in the order that they appeared in the |
| 6435 | request. |
| 6436 | |
| 6437 | If the server ignores a byte-range-spec because it is invalid, the |
| 6438 | server should treat the request as if the invalid Range header field |
| 6439 | |
| 6440 | |
| 6441 | |
| 6442 | Fielding, et. al. Standards Track [Page 115] |
| 6443 | \f |
| 6444 | RFC 2068 HTTP/1.1 January 1997 |
| 6445 | |
| 6446 | |
| 6447 | did not exist. (Normally, this means return a 200 response containing |
| 6448 | the full entity). The reason is that the only time a client will make |
| 6449 | such an invalid request is when the entity is smaller than the entity |
| 6450 | retrieved by a prior request. |
| 6451 | |
| 6452 | 14.18 Content-Type |
| 6453 | |
| 6454 | The Content-Type entity-header field indicates the media type of the |
| 6455 | entity-body sent to the recipient or, in the case of the HEAD method, |
| 6456 | the media type that would have been sent had the request been a GET. |
| 6457 | |
| 6458 | Content-Type = "Content-Type" ":" media-type |
| 6459 | Media types are defined in section 3.7. An example of the field is |
| 6460 | |
| 6461 | Content-Type: text/html; charset=ISO-8859-4 |
| 6462 | |
| 6463 | Further discussion of methods for identifying the media type of an |
| 6464 | entity is provided in section 7.2.1. |
| 6465 | |
| 6466 | 14.19 Date |
| 6467 | |
| 6468 | The Date general-header field represents the date and time at which |
| 6469 | the message was originated, having the same semantics as orig-date in |
| 6470 | RFC 822. The field value is an HTTP-date, as described in section |
| 6471 | 3.3.1. |
| 6472 | |
| 6473 | Date = "Date" ":" HTTP-date |
| 6474 | |
| 6475 | An example is |
| 6476 | |
| 6477 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| 6478 | |
| 6479 | If a message is received via direct connection with the user agent |
| 6480 | (in the case of requests) or the origin server (in the case of |
| 6481 | responses), then the date can be assumed to be the current date at |
| 6482 | the receiving end. However, since the date--as it is believed by the |
| 6483 | origin--is important for evaluating cached responses, origin servers |
| 6484 | MUST include a Date header field in all responses. Clients SHOULD |
| 6485 | only send a Date header field in messages that include an entity- |
| 6486 | body, as in the case of the PUT and POST requests, and even then it |
| 6487 | is optional. A received message which does not have a Date header |
| 6488 | field SHOULD be assigned one by the recipient if the message will be |
| 6489 | cached by that recipient or gatewayed via a protocol which requires a |
| 6490 | Date. |
| 6491 | |
| 6492 | |
| 6493 | |
| 6494 | |
| 6495 | |
| 6496 | |
| 6497 | |
| 6498 | Fielding, et. al. Standards Track [Page 116] |
| 6499 | \f |
| 6500 | RFC 2068 HTTP/1.1 January 1997 |
| 6501 | |
| 6502 | |
| 6503 | In theory, the date SHOULD represent the moment just before the |
| 6504 | entity is generated. In practice, the date can be generated at any |
| 6505 | time during the message origination without affecting its semantic |
| 6506 | value. |
| 6507 | |
| 6508 | The format of the Date is an absolute date and time as defined by |
| 6509 | HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format. |
| 6510 | |
| 6511 | 14.20 ETag |
| 6512 | |
| 6513 | The ETag entity-header field defines the entity tag for the |
| 6514 | associated entity. The headers used with entity tags are described in |
| 6515 | sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used |
| 6516 | for comparison with other entities from the same resource (see |
| 6517 | section 13.3.2). |
| 6518 | |
| 6519 | ETag = "ETag" ":" entity-tag |
| 6520 | |
| 6521 | Examples: |
| 6522 | |
| 6523 | ETag: "xyzzy" |
| 6524 | ETag: W/"xyzzy" |
| 6525 | ETag: "" |
| 6526 | |
| 6527 | 14.21 Expires |
| 6528 | |
| 6529 | The Expires entity-header field gives the date/time after which the |
| 6530 | response should be considered stale. A stale cache entry may not |
| 6531 | normally be returned by a cache (either a proxy cache or an user |
| 6532 | agent cache) unless it is first validated with the origin server (or |
| 6533 | with an intermediate cache that has a fresh copy of the entity). See |
| 6534 | section 13.2 for further discussion of the expiration model. |
| 6535 | |
| 6536 | The presence of an Expires field does not imply that the original |
| 6537 | resource will change or cease to exist at, before, or after that |
| 6538 | time. |
| 6539 | |
| 6540 | The format is an absolute date and time as defined by HTTP-date in |
| 6541 | section 3.3; it MUST be in RFC1123-date format: |
| 6542 | |
| 6543 | Expires = "Expires" ":" HTTP-date |
| 6544 | |
| 6545 | |
| 6546 | |
| 6547 | |
| 6548 | |
| 6549 | |
| 6550 | |
| 6551 | |
| 6552 | |
| 6553 | |
| 6554 | Fielding, et. al. Standards Track [Page 117] |
| 6555 | \f |
| 6556 | RFC 2068 HTTP/1.1 January 1997 |
| 6557 | |
| 6558 | |
| 6559 | An example of its use is |
| 6560 | |
| 6561 | Expires: Thu, 01 Dec 1994 16:00:00 GMT |
| 6562 | |
| 6563 | Note: if a response includes a Cache-Control field with the max-age |
| 6564 | directive, that directive overrides the Expires field. |
| 6565 | |
| 6566 | HTTP/1.1 clients and caches MUST treat other invalid date formats, |
| 6567 | especially including the value "0", as in the past (i.e., "already |
| 6568 | expired"). |
| 6569 | |
| 6570 | To mark a response as "already expired," an origin server should use |
| 6571 | an Expires date that is equal to the Date header value. (See the |
| 6572 | rules for expiration calculations in section 13.2.4.) |
| 6573 | |
| 6574 | To mark a response as "never expires," an origin server should use an |
| 6575 | Expires date approximately one year from the time the response is |
| 6576 | sent. HTTP/1.1 servers should not send Expires dates more than one |
| 6577 | year in the future. |
| 6578 | |
| 6579 | The presence of an Expires header field with a date value of some |
| 6580 | time in the future on an response that otherwise would by default be |
| 6581 | non-cacheable indicates that the response is cachable, unless |
| 6582 | indicated otherwise by a Cache-Control header field (section 14.9). |
| 6583 | |
| 6584 | 14.22 From |
| 6585 | |
| 6586 | The From request-header field, if given, SHOULD contain an Internet |
| 6587 | e-mail address for the human user who controls the requesting user |
| 6588 | agent. The address SHOULD be machine-usable, as defined by mailbox |
| 6589 | in RFC 822 (as updated by RFC 1123 ): |
| 6590 | |
| 6591 | From = "From" ":" mailbox |
| 6592 | |
| 6593 | An example is: |
| 6594 | |
| 6595 | From: webmaster@w3.org |
| 6596 | |
| 6597 | This header field MAY be used for logging purposes and as a means for |
| 6598 | identifying the source of invalid or unwanted requests. It SHOULD NOT |
| 6599 | be used as an insecure form of access protection. The interpretation |
| 6600 | of this field is that the request is being performed on behalf of the |
| 6601 | person given, who accepts responsibility for the method performed. In |
| 6602 | particular, robot agents SHOULD include this header so that the |
| 6603 | person responsible for running the robot can be contacted if problems |
| 6604 | occur on the receiving end. |
| 6605 | |
| 6606 | |
| 6607 | |
| 6608 | |
| 6609 | |
| 6610 | Fielding, et. al. Standards Track [Page 118] |
| 6611 | \f |
| 6612 | RFC 2068 HTTP/1.1 January 1997 |
| 6613 | |
| 6614 | |
| 6615 | The Internet e-mail address in this field MAY be separate from the |
| 6616 | Internet host which issued the request. For example, when a request |
| 6617 | is passed through a proxy the original issuer's address SHOULD be |
| 6618 | used. |
| 6619 | |
| 6620 | Note: The client SHOULD not send the From header field without the |
| 6621 | user's approval, as it may conflict with the user's privacy |
| 6622 | interests or their site's security policy. It is strongly |
| 6623 | recommended that the user be able to disable, enable, and modify |
| 6624 | the value of this field at any time prior to a request. |
| 6625 | |
| 6626 | 14.23 Host |
| 6627 | |
| 6628 | The Host request-header field specifies the Internet host and port |
| 6629 | number of the resource being requested, as obtained from the original |
| 6630 | URL given by the user or referring resource (generally an HTTP URL, |
| 6631 | as described in section 3.2.2). The Host field value MUST represent |
| 6632 | the network location of the origin server or gateway given by the |
| 6633 | original URL. This allows the origin server or gateway to |
| 6634 | differentiate between internally-ambiguous URLs, such as the root "/" |
| 6635 | URL of a server for multiple host names on a single IP address. |
| 6636 | |
| 6637 | Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 |
| 6638 | |
| 6639 | A "host" without any trailing port information implies the default |
| 6640 | port for the service requested (e.g., "80" for an HTTP URL). For |
| 6641 | example, a request on the origin server for |
| 6642 | <http://www.w3.org/pub/WWW/> MUST include: |
| 6643 | |
| 6644 | GET /pub/WWW/ HTTP/1.1 |
| 6645 | Host: www.w3.org |
| 6646 | |
| 6647 | A client MUST include a Host header field in all HTTP/1.1 request |
| 6648 | messages on the Internet (i.e., on any message corresponding to a |
| 6649 | request for a URL which includes an Internet host address for the |
| 6650 | service being requested). If the Host field is not already present, |
| 6651 | an HTTP/1.1 proxy MUST add a Host field to the request message prior |
| 6652 | to forwarding it on the Internet. All Internet-based HTTP/1.1 servers |
| 6653 | MUST respond with a 400 status code to any HTTP/1.1 request message |
| 6654 | which lacks a Host header field. |
| 6655 | |
| 6656 | See sections 5.2 and 19.5.1 for other requirements relating to Host. |
| 6657 | |
| 6658 | 14.24 If-Modified-Since |
| 6659 | |
| 6660 | The If-Modified-Since request-header field is used with the GET |
| 6661 | method to make it conditional: if the requested variant has not been |
| 6662 | modified since the time specified in this field, an entity will not |
| 6663 | |
| 6664 | |
| 6665 | |
| 6666 | Fielding, et. al. Standards Track [Page 119] |
| 6667 | \f |
| 6668 | RFC 2068 HTTP/1.1 January 1997 |
| 6669 | |
| 6670 | |
| 6671 | be returned from the server; instead, a 304 (not modified) response |
| 6672 | will be returned without any message-body. |
| 6673 | |
| 6674 | If-Modified-Since = "If-Modified-Since" ":" HTTP-date |
| 6675 | |
| 6676 | An example of the field is: |
| 6677 | |
| 6678 | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| 6679 | |
| 6680 | A GET method with an If-Modified-Since header and no Range header |
| 6681 | requests that the identified entity be transferred only if it has |
| 6682 | been modified since the date given by the If-Modified-Since header. |
| 6683 | The algorithm for determining this includes the following cases: |
| 6684 | |
| 6685 | a)If the request would normally result in anything other than a 200 |
| 6686 | (OK) status, or if the passed If-Modified-Since date is invalid, the |
| 6687 | response is exactly the same as for a normal GET. A date which is |
| 6688 | later than the server's current time is invalid. |
| 6689 | |
| 6690 | b)If the variant has been modified since the If-Modified-Since date, |
| 6691 | the response is exactly the same as for a normal GET. |
| 6692 | |
| 6693 | c)If the variant has not been modified since a valid If-Modified-Since |
| 6694 | date, the server MUST return a 304 (Not Modified) response. |
| 6695 | |
| 6696 | The purpose of this feature is to allow efficient updates of cached |
| 6697 | information with a minimum amount of transaction overhead. |
| 6698 | |
| 6699 | Note that the Range request-header field modifies the meaning of |
| 6700 | If-Modified-Since; see section 14.36 for full details. |
| 6701 | |
| 6702 | Note that If-Modified-Since times are interpreted by the server, |
| 6703 | whose clock may not be synchronized with the client. |
| 6704 | |
| 6705 | Note that if a client uses an arbitrary date in the If-Modified-Since |
| 6706 | header instead of a date taken from the Last-Modified header for the |
| 6707 | same request, the client should be aware of the fact that this date |
| 6708 | is interpreted in the server's understanding of time. The client |
| 6709 | should consider unsynchronized clocks and rounding problems due to |
| 6710 | the different encodings of time between the client and server. This |
| 6711 | includes the possibility of race conditions if the document has |
| 6712 | changed between the time it was first requested and the If-Modified- |
| 6713 | Since date of a subsequent request, and the possibility of clock- |
| 6714 | skew-related problems if the If-Modified-Since date is derived from |
| 6715 | the client's clock without correction to the server's clock. |
| 6716 | Corrections for different time bases between client and server are at |
| 6717 | best approximate due to network latency. |
| 6718 | |
| 6719 | |
| 6720 | |
| 6721 | |
| 6722 | Fielding, et. al. Standards Track [Page 120] |
| 6723 | \f |
| 6724 | RFC 2068 HTTP/1.1 January 1997 |
| 6725 | |
| 6726 | |
| 6727 | 14.25 If-Match |
| 6728 | |
| 6729 | The If-Match request-header field is used with a method to make it |
| 6730 | conditional. A client that has one or more entities previously |
| 6731 | obtained from the resource can verify that one of those entities is |
| 6732 | current by including a list of their associated entity tags in the |
| 6733 | If-Match header field. The purpose of this feature is to allow |
| 6734 | efficient updates of cached information with a minimum amount of |
| 6735 | transaction overhead. It is also used, on updating requests, to |
| 6736 | prevent inadvertent modification of the wrong version of a resource. |
| 6737 | As a special case, the value "*" matches any current entity of the |
| 6738 | resource. |
| 6739 | |
| 6740 | If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) |
| 6741 | |
| 6742 | If any of the entity tags match the entity tag of the entity that |
| 6743 | would have been returned in the response to a similar GET request |
| 6744 | (without the If-Match header) on that resource, or if "*" is given |
| 6745 | and any current entity exists for that resource, then the server MAY |
| 6746 | perform the requested method as if the If-Match header field did not |
| 6747 | exist. |
| 6748 | |
| 6749 | A server MUST use the strong comparison function (see section 3.11) |
| 6750 | to compare the entity tags in If-Match. |
| 6751 | |
| 6752 | If none of the entity tags match, or if "*" is given and no current |
| 6753 | entity exists, the server MUST NOT perform the requested method, and |
| 6754 | MUST return a 412 (Precondition Failed) response. This behavior is |
| 6755 | most useful when the client wants to prevent an updating method, such |
| 6756 | as PUT, from modifying a resource that has changed since the client |
| 6757 | last retrieved it. |
| 6758 | |
| 6759 | If the request would, without the If-Match header field, result in |
| 6760 | anything other than a 2xx status, then the If-Match header MUST be |
| 6761 | ignored. |
| 6762 | |
| 6763 | The meaning of "If-Match: *" is that the method SHOULD be performed |
| 6764 | if the representation selected by the origin server (or by a cache, |
| 6765 | possibly using the Vary mechanism, see section 14.43) exists, and |
| 6766 | MUST NOT be performed if the representation does not exist. |
| 6767 | |
| 6768 | |
| 6769 | |
| 6770 | |
| 6771 | |
| 6772 | |
| 6773 | |
| 6774 | |
| 6775 | |
| 6776 | |
| 6777 | |
| 6778 | Fielding, et. al. Standards Track [Page 121] |
| 6779 | \f |
| 6780 | RFC 2068 HTTP/1.1 January 1997 |
| 6781 | |
| 6782 | |
| 6783 | A request intended to update a resource (e.g., a PUT) MAY include an |
| 6784 | If-Match header field to signal that the request method MUST NOT be |
| 6785 | applied if the entity corresponding to the If-Match value (a single |
| 6786 | entity tag) is no longer a representation of that resource. This |
| 6787 | allows the user to indicate that they do not wish the request to be |
| 6788 | successful if the resource has been changed without their knowledge. |
| 6789 | Examples: |
| 6790 | |
| 6791 | If-Match: "xyzzy" |
| 6792 | If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
| 6793 | If-Match: * |
| 6794 | |
| 6795 | 14.26 If-None-Match |
| 6796 | |
| 6797 | The If-None-Match request-header field is used with a method to make |
| 6798 | it conditional. A client that has one or more entities previously |
| 6799 | obtained from the resource can verify that none of those entities is |
| 6800 | current by including a list of their associated entity tags in the |
| 6801 | If-None-Match header field. The purpose of this feature is to allow |
| 6802 | efficient updates of cached information with a minimum amount of |
| 6803 | transaction overhead. It is also used, on updating requests, to |
| 6804 | prevent inadvertent modification of a resource which was not known to |
| 6805 | exist. |
| 6806 | |
| 6807 | As a special case, the value "*" matches any current entity of the |
| 6808 | resource. |
| 6809 | |
| 6810 | If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) |
| 6811 | |
| 6812 | If any of the entity tags match the entity tag of the entity that |
| 6813 | would have been returned in the response to a similar GET request |
| 6814 | (without the If-None-Match header) on that resource, or if "*" is |
| 6815 | given and any current entity exists for that resource, then the |
| 6816 | server MUST NOT perform the requested method. Instead, if the request |
| 6817 | method was GET or HEAD, the server SHOULD respond with a 304 (Not |
| 6818 | Modified) response, including the cache-related entity-header fields |
| 6819 | (particularly ETag) of one of the entities that matched. For all |
| 6820 | other request methods, the server MUST respond with a status of 412 |
| 6821 | (Precondition Failed). |
| 6822 | |
| 6823 | See section 13.3.3 for rules on how to determine if two entity tags |
| 6824 | match. The weak comparison function can only be used with GET or HEAD |
| 6825 | requests. |
| 6826 | |
| 6827 | If none of the entity tags match, or if "*" is given and no current |
| 6828 | entity exists, then the server MAY perform the requested method as if |
| 6829 | the If-None-Match header field did not exist. |
| 6830 | |
| 6831 | |
| 6832 | |
| 6833 | |
| 6834 | Fielding, et. al. Standards Track [Page 122] |
| 6835 | \f |
| 6836 | RFC 2068 HTTP/1.1 January 1997 |
| 6837 | |
| 6838 | |
| 6839 | If the request would, without the If-None-Match header field, result |
| 6840 | in anything other than a 2xx status, then the If-None-Match header |
| 6841 | MUST be ignored. |
| 6842 | |
| 6843 | The meaning of "If-None-Match: *" is that the method MUST NOT be |
| 6844 | performed if the representation selected by the origin server (or by |
| 6845 | a cache, possibly using the Vary mechanism, see section 14.43) |
| 6846 | exists, and SHOULD be performed if the representation does not exist. |
| 6847 | This feature may be useful in preventing races between PUT |
| 6848 | operations. |
| 6849 | |
| 6850 | Examples: |
| 6851 | |
| 6852 | If-None-Match: "xyzzy" |
| 6853 | If-None-Match: W/"xyzzy" |
| 6854 | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
| 6855 | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
| 6856 | If-None-Match: * |
| 6857 | |
| 6858 | 14.27 If-Range |
| 6859 | |
| 6860 | If a client has a partial copy of an entity in its cache, and wishes |
| 6861 | to have an up-to-date copy of the entire entity in its cache, it |
| 6862 | could use the Range request-header with a conditional GET (using |
| 6863 | either or both of If-Unmodified-Since and If-Match.) However, if the |
| 6864 | condition fails because the entity has been modified, the client |
| 6865 | would then have to make a second request to obtain the entire current |
| 6866 | entity-body. |
| 6867 | |
| 6868 | The If-Range header allows a client to "short-circuit" the second |
| 6869 | request. Informally, its meaning is `if the entity is unchanged, send |
| 6870 | me the part(s) that I am missing; otherwise, send me the entire new |
| 6871 | entity.' |
| 6872 | |
| 6873 | If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) |
| 6874 | |
| 6875 | If the client has no entity tag for an entity, but does have a Last- |
| 6876 | Modified date, it may use that date in a If-Range header. (The server |
| 6877 | can distinguish between a valid HTTP-date and any form of entity-tag |
| 6878 | by examining no more than two characters.) The If-Range header should |
| 6879 | only be used together with a Range header, and must be ignored if the |
| 6880 | request does not include a Range header, or if the server does not |
| 6881 | support the sub-range operation. |
| 6882 | |
| 6883 | |
| 6884 | |
| 6885 | |
| 6886 | |
| 6887 | |
| 6888 | |
| 6889 | |
| 6890 | Fielding, et. al. Standards Track [Page 123] |
| 6891 | \f |
| 6892 | RFC 2068 HTTP/1.1 January 1997 |
| 6893 | |
| 6894 | |
| 6895 | If the entity tag given in the If-Range header matches the current |
| 6896 | entity tag for the entity, then the server should provide the |
| 6897 | specified sub-range of the entity using a 206 (Partial content) |
| 6898 | response. If the entity tag does not match, then the server should |
| 6899 | return the entire entity using a 200 (OK) response. |
| 6900 | |
| 6901 | 14.28 If-Unmodified-Since |
| 6902 | |
| 6903 | The If-Unmodified-Since request-header field is used with a method to |
| 6904 | make it conditional. If the requested resource has not been modified |
| 6905 | since the time specified in this field, the server should perform the |
| 6906 | requested operation as if the If-Unmodified-Since header were not |
| 6907 | present. |
| 6908 | |
| 6909 | If the requested variant has been modified since the specified time, |
| 6910 | the server MUST NOT perform the requested operation, and MUST return |
| 6911 | a 412 (Precondition Failed). |
| 6912 | |
| 6913 | If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date |
| 6914 | |
| 6915 | An example of the field is: |
| 6916 | |
| 6917 | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| 6918 | |
| 6919 | If the request normally (i.e., without the If-Unmodified-Since |
| 6920 | header) would result in anything other than a 2xx status, the If- |
| 6921 | Unmodified-Since header should be ignored. |
| 6922 | |
| 6923 | If the specified date is invalid, the header is ignored. |
| 6924 | |
| 6925 | 14.29 Last-Modified |
| 6926 | |
| 6927 | The Last-Modified entity-header field indicates the date and time at |
| 6928 | which the origin server believes the variant was last modified. |
| 6929 | |
| 6930 | Last-Modified = "Last-Modified" ":" HTTP-date |
| 6931 | |
| 6932 | An example of its use is |
| 6933 | |
| 6934 | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
| 6935 | |
| 6936 | The exact meaning of this header field depends on the implementation |
| 6937 | of the origin server and the nature of the original resource. For |
| 6938 | files, it may be just the file system last-modified time. For |
| 6939 | entities with dynamically included parts, it may be the most recent |
| 6940 | of the set of last-modify times for its component parts. For database |
| 6941 | gateways, it may be the last-update time stamp of the record. For |
| 6942 | virtual objects, it may be the last time the internal state changed. |
| 6943 | |
| 6944 | |
| 6945 | |
| 6946 | Fielding, et. al. Standards Track [Page 124] |
| 6947 | \f |
| 6948 | RFC 2068 HTTP/1.1 January 1997 |
| 6949 | |
| 6950 | |
| 6951 | An origin server MUST NOT send a Last-Modified date which is later |
| 6952 | than the server's time of message origination. In such cases, where |
| 6953 | the resource's last modification would indicate some time in the |
| 6954 | future, the server MUST replace that date with the message |
| 6955 | origination date. |
| 6956 | |
| 6957 | An origin server should obtain the Last-Modified value of the entity |
| 6958 | as close as possible to the time that it generates the Date value of |
| 6959 | its response. This allows a recipient to make an accurate assessment |
| 6960 | of the entity's modification time, especially if the entity changes |
| 6961 | near the time that the response is generated. |
| 6962 | |
| 6963 | HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. |
| 6964 | |
| 6965 | 14.30 Location |
| 6966 | |
| 6967 | The Location response-header field is used to redirect the recipient |
| 6968 | to a location other than the Request-URI for completion of the |
| 6969 | request or identification of a new resource. For 201 (Created) |
| 6970 | responses, the Location is that of the new resource which was created |
| 6971 | by the request. For 3xx responses, the location SHOULD indicate the |
| 6972 | server's preferred URL for automatic redirection to the resource. The |
| 6973 | field value consists of a single absolute URL. |
| 6974 | |
| 6975 | Location = "Location" ":" absoluteURI |
| 6976 | |
| 6977 | An example is |
| 6978 | |
| 6979 | Location: http://www.w3.org/pub/WWW/People.html |
| 6980 | |
| 6981 | Note: The Content-Location header field (section 14.15) differs |
| 6982 | from Location in that the Content-Location identifies the original |
| 6983 | location of the entity enclosed in the request. It is therefore |
| 6984 | possible for a response to contain header fields for both Location |
| 6985 | and Content-Location. Also see section 13.10 for cache requirements |
| 6986 | of some methods. |
| 6987 | |
| 6988 | 14.31 Max-Forwards |
| 6989 | |
| 6990 | The Max-Forwards request-header field may be used with the TRACE |
| 6991 | method (section 14.31) to limit the number of proxies or gateways |
| 6992 | that can forward the request to the next inbound server. This can be |
| 6993 | useful when the client is attempting to trace a request chain which |
| 6994 | appears to be failing or looping in mid-chain. |
| 6995 | |
| 6996 | Max-Forwards = "Max-Forwards" ":" 1*DIGIT |
| 6997 | |
| 6998 | |
| 6999 | |
| 7000 | |
| 7001 | |
| 7002 | Fielding, et. al. Standards Track [Page 125] |
| 7003 | \f |
| 7004 | RFC 2068 HTTP/1.1 January 1997 |
| 7005 | |
| 7006 | |
| 7007 | The Max-Forwards value is a decimal integer indicating the remaining |
| 7008 | number of times this request message may be forwarded. |
| 7009 | |
| 7010 | Each proxy or gateway recipient of a TRACE request containing a Max- |
| 7011 | Forwards header field SHOULD check and update its value prior to |
| 7012 | forwarding the request. If the received value is zero (0), the |
| 7013 | recipient SHOULD NOT forward the request; instead, it SHOULD respond |
| 7014 | as the final recipient with a 200 (OK) response containing the |
| 7015 | received request message as the response entity-body (as described in |
| 7016 | section 9.8). If the received Max-Forwards value is greater than |
| 7017 | zero, then the forwarded message SHOULD contain an updated Max- |
| 7018 | Forwards field with a value decremented by one (1). |
| 7019 | |
| 7020 | The Max-Forwards header field SHOULD be ignored for all other methods |
| 7021 | defined by this specification and for any extension methods for which |
| 7022 | it is not explicitly referred to as part of that method definition. |
| 7023 | |
| 7024 | 14.32 Pragma |
| 7025 | |
| 7026 | The Pragma general-header field is used to include implementation- |
| 7027 | specific directives that may apply to any recipient along the |
| 7028 | request/response chain. All pragma directives specify optional |
| 7029 | behavior from the viewpoint of the protocol; however, some systems |
| 7030 | MAY require that behavior be consistent with the directives. |
| 7031 | |
| 7032 | Pragma = "Pragma" ":" 1#pragma-directive |
| 7033 | |
| 7034 | pragma-directive = "no-cache" | extension-pragma |
| 7035 | extension-pragma = token [ "=" ( token | quoted-string ) ] |
| 7036 | |
| 7037 | When the no-cache directive is present in a request message, an |
| 7038 | application SHOULD forward the request toward the origin server even |
| 7039 | if it has a cached copy of what is being requested. This pragma |
| 7040 | directive has the same semantics as the no-cache cache-directive (see |
| 7041 | section 14.9) and is defined here for backwards compatibility with |
| 7042 | HTTP/1.0. Clients SHOULD include both header fields when a no-cache |
| 7043 | request is sent to a server not known to be HTTP/1.1 compliant. |
| 7044 | |
| 7045 | Pragma directives MUST be passed through by a proxy or gateway |
| 7046 | application, regardless of their significance to that application, |
| 7047 | since the directives may be applicable to all recipients along the |
| 7048 | request/response chain. It is not possible to specify a pragma for a |
| 7049 | specific recipient; however, any pragma directive not relevant to a |
| 7050 | recipient SHOULD be ignored by that recipient. |
| 7051 | |
| 7052 | |
| 7053 | |
| 7054 | |
| 7055 | |
| 7056 | |
| 7057 | |
| 7058 | Fielding, et. al. Standards Track [Page 126] |
| 7059 | \f |
| 7060 | RFC 2068 HTTP/1.1 January 1997 |
| 7061 | |
| 7062 | |
| 7063 | HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1 |
| 7064 | caches SHOULD treat "Pragma: no-cache" as if the client had sent |
| 7065 | "Cache-Control: no-cache". No new Pragma directives will be defined |
| 7066 | in HTTP. |
| 7067 | |
| 7068 | 14.33 Proxy-Authenticate |
| 7069 | |
| 7070 | The Proxy-Authenticate response-header field MUST be included as part |
| 7071 | of a 407 (Proxy Authentication Required) response. The field value |
| 7072 | consists of a challenge that indicates the authentication scheme and |
| 7073 | parameters applicable to the proxy for this Request-URI. |
| 7074 | |
| 7075 | Proxy-Authenticate = "Proxy-Authenticate" ":" challenge |
| 7076 | |
| 7077 | The HTTP access authentication process is described in section 11. |
| 7078 | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |
| 7079 | only to the current connection and SHOULD NOT be passed on to |
| 7080 | downstream clients. However, an intermediate proxy may need to obtain |
| 7081 | its own credentials by requesting them from the downstream client, |
| 7082 | which in some circumstances will appear as if the proxy is forwarding |
| 7083 | the Proxy-Authenticate header field. |
| 7084 | |
| 7085 | 14.34 Proxy-Authorization |
| 7086 | |
| 7087 | The Proxy-Authorization request-header field allows the client to |
| 7088 | identify itself (or its user) to a proxy which requires |
| 7089 | authentication. The Proxy-Authorization field value consists of |
| 7090 | credentials containing the authentication information of the user |
| 7091 | agent for the proxy and/or realm of the resource being requested. |
| 7092 | |
| 7093 | Proxy-Authorization = "Proxy-Authorization" ":" credentials |
| 7094 | |
| 7095 | The HTTP access authentication process is described in section 11. |
| 7096 | Unlike Authorization, the Proxy-Authorization header field applies |
| 7097 | only to the next outbound proxy that demanded authentication using |
| 7098 | the Proxy-Authenticate field. When multiple proxies are used in a |
| 7099 | chain, the Proxy-Authorization header field is consumed by the first |
| 7100 | outbound proxy that was expecting to receive credentials. A proxy MAY |
| 7101 | relay the credentials from the client request to the next proxy if |
| 7102 | that is the mechanism by which the proxies cooperatively authenticate |
| 7103 | a given request. |
| 7104 | |
| 7105 | 14.35 Public |
| 7106 | |
| 7107 | The Public response-header field lists the set of methods supported |
| 7108 | by the server. The purpose of this field is strictly to inform the |
| 7109 | recipient of the capabilities of the server regarding unusual |
| 7110 | methods. The methods listed may or may not be applicable to the |
| 7111 | |
| 7112 | |
| 7113 | |
| 7114 | Fielding, et. al. Standards Track [Page 127] |
| 7115 | \f |
| 7116 | RFC 2068 HTTP/1.1 January 1997 |
| 7117 | |
| 7118 | |
| 7119 | Request-URI; the Allow header field (section 14.7) MAY be used to |
| 7120 | indicate methods allowed for a particular URI. |
| 7121 | |
| 7122 | Public = "Public" ":" 1#method |
| 7123 | |
| 7124 | Example of use: |
| 7125 | |
| 7126 | Public: OPTIONS, MGET, MHEAD, GET, HEAD |
| 7127 | |
| 7128 | This header field applies only to the server directly connected to |
| 7129 | the client (i.e., the nearest neighbor in a chain of connections). If |
| 7130 | the response passes through a proxy, the proxy MUST either remove the |
| 7131 | Public header field or replace it with one applicable to its own |
| 7132 | capabilities. |
| 7133 | |
| 7134 | 14.36 Range |
| 7135 | |
| 7136 | 14.36.1 Byte Ranges |
| 7137 | |
| 7138 | Since all HTTP entities are represented in HTTP messages as sequences |
| 7139 | of bytes, the concept of a byte range is meaningful for any HTTP |
| 7140 | entity. (However, not all clients and servers need to support byte- |
| 7141 | range operations.) |
| 7142 | |
| 7143 | Byte range specifications in HTTP apply to the sequence of bytes in |
| 7144 | the entity-body (not necessarily the same as the message-body). |
| 7145 | |
| 7146 | A byte range operation may specify a single range of bytes, or a set |
| 7147 | of ranges within a single entity. |
| 7148 | |
| 7149 | ranges-specifier = byte-ranges-specifier |
| 7150 | |
| 7151 | byte-ranges-specifier = bytes-unit "=" byte-range-set |
| 7152 | |
| 7153 | byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) |
| 7154 | |
| 7155 | byte-range-spec = first-byte-pos "-" [last-byte-pos] |
| 7156 | |
| 7157 | first-byte-pos = 1*DIGIT |
| 7158 | |
| 7159 | last-byte-pos = 1*DIGIT |
| 7160 | |
| 7161 | The first-byte-pos value in a byte-range-spec gives the byte-offset |
| 7162 | of the first byte in a range. The last-byte-pos value gives the |
| 7163 | byte-offset of the last byte in the range; that is, the byte |
| 7164 | positions specified are inclusive. Byte offsets start at zero. |
| 7165 | |
| 7166 | |
| 7167 | |
| 7168 | |
| 7169 | |
| 7170 | Fielding, et. al. Standards Track [Page 128] |
| 7171 | \f |
| 7172 | RFC 2068 HTTP/1.1 January 1997 |
| 7173 | |
| 7174 | |
| 7175 | If the last-byte-pos value is present, it must be greater than or |
| 7176 | equal to the first-byte-pos in that byte-range-spec, or the byte- |
| 7177 | range-spec is invalid. The recipient of an invalid byte-range-spec |
| 7178 | must ignore it. |
| 7179 | |
| 7180 | If the last-byte-pos value is absent, or if the value is greater than |
| 7181 | or equal to the current length of the entity-body, last-byte-pos is |
| 7182 | taken to be equal to one less than the current length of the entity- |
| 7183 | body in bytes. |
| 7184 | |
| 7185 | By its choice of last-byte-pos, a client can limit the number of |
| 7186 | bytes retrieved without knowing the size of the entity. |
| 7187 | |
| 7188 | suffix-byte-range-spec = "-" suffix-length |
| 7189 | |
| 7190 | suffix-length = 1*DIGIT |
| 7191 | |
| 7192 | A suffix-byte-range-spec is used to specify the suffix of the |
| 7193 | entity-body, of a length given by the suffix-length value. (That is, |
| 7194 | this form specifies the last N bytes of an entity-body.) If the |
| 7195 | entity is shorter than the specified suffix-length, the entire |
| 7196 | entity-body is used. |
| 7197 | |
| 7198 | Examples of byte-ranges-specifier values (assuming an entity-body of |
| 7199 | length 10000): |
| 7200 | |
| 7201 | o The first 500 bytes (byte offsets 0-499, inclusive): |
| 7202 | |
| 7203 | bytes=0-499 |
| 7204 | |
| 7205 | o The second 500 bytes (byte offsets 500-999, inclusive): |
| 7206 | |
| 7207 | bytes=500-999 |
| 7208 | |
| 7209 | o The final 500 bytes (byte offsets 9500-9999, inclusive): |
| 7210 | |
| 7211 | bytes=-500 |
| 7212 | |
| 7213 | o Or |
| 7214 | |
| 7215 | bytes=9500- |
| 7216 | |
| 7217 | o The first and last bytes only (bytes 0 and 9999): |
| 7218 | |
| 7219 | bytes=0-0,-1 |
| 7220 | |
| 7221 | |
| 7222 | |
| 7223 | |
| 7224 | |
| 7225 | |
| 7226 | Fielding, et. al. Standards Track [Page 129] |
| 7227 | \f |
| 7228 | RFC 2068 HTTP/1.1 January 1997 |
| 7229 | |
| 7230 | |
| 7231 | o Several legal but not canonical specifications of the second |
| 7232 | 500 bytes (byte offsets 500-999, inclusive): |
| 7233 | |
| 7234 | bytes=500-600,601-999 |
| 7235 | |
| 7236 | bytes=500-700,601-999 |
| 7237 | |
| 7238 | 14.36.2 Range Retrieval Requests |
| 7239 | |
| 7240 | HTTP retrieval requests using conditional or unconditional GET |
| 7241 | methods may request one or more sub-ranges of the entity, instead of |
| 7242 | the entire entity, using the Range request header, which applies to |
| 7243 | the entity returned as the result of the request: |
| 7244 | |
| 7245 | Range = "Range" ":" ranges-specifier |
| 7246 | |
| 7247 | A server MAY ignore the Range header. However, HTTP/1.1 origin |
| 7248 | servers and intermediate caches SHOULD support byte ranges when |
| 7249 | possible, since Range supports efficient recovery from partially |
| 7250 | failed transfers, and supports efficient partial retrieval of large |
| 7251 | entities. |
| 7252 | |
| 7253 | If the server supports the Range header and the specified range or |
| 7254 | ranges are appropriate for the entity: |
| 7255 | |
| 7256 | o The presence of a Range header in an unconditional GET modifies |
| 7257 | what is returned if the GET is otherwise successful. In other |
| 7258 | words, the response carries a status code of 206 (Partial |
| 7259 | Content) instead of 200 (OK). |
| 7260 | |
| 7261 | o The presence of a Range header in a conditional GET (a request |
| 7262 | using one or both of If-Modified-Since and If-None-Match, or |
| 7263 | one or both of If-Unmodified-Since and If-Match) modifies what |
| 7264 | is returned if the GET is otherwise successful and the condition |
| 7265 | is true. It does not affect the 304 (Not Modified) response |
| 7266 | returned if the conditional is false. |
| 7267 | |
| 7268 | In some cases, it may be more appropriate to use the If-Range header |
| 7269 | (see section 14.27) in addition to the Range header. |
| 7270 | |
| 7271 | If a proxy that supports ranges receives a Range request, forwards |
| 7272 | the request to an inbound server, and receives an entire entity in |
| 7273 | reply, it SHOULD only return the requested range to its client. It |
| 7274 | SHOULD store the entire received response in its cache, if that is |
| 7275 | consistent with its cache allocation policies. |
| 7276 | |
| 7277 | |
| 7278 | |
| 7279 | |
| 7280 | |
| 7281 | |
| 7282 | Fielding, et. al. Standards Track [Page 130] |
| 7283 | \f |
| 7284 | RFC 2068 HTTP/1.1 January 1997 |
| 7285 | |
| 7286 | |
| 7287 | 14.37 Referer |
| 7288 | |
| 7289 | The Referer[sic] request-header field allows the client to specify, |
| 7290 | for the server's benefit, the address (URI) of the resource from |
| 7291 | which the Request-URI was obtained (the "referrer", although the |
| 7292 | header field is misspelled.) The Referer request-header allows a |
| 7293 | server to generate lists of back-links to resources for interest, |
| 7294 | logging, optimized caching, etc. It also allows obsolete or mistyped |
| 7295 | links to be traced for maintenance. The Referer field MUST NOT be |
| 7296 | sent if the Request-URI was obtained from a source that does not have |
| 7297 | its own URI, such as input from the user keyboard. |
| 7298 | |
| 7299 | Referer = "Referer" ":" ( absoluteURI | relativeURI ) |
| 7300 | |
| 7301 | Example: |
| 7302 | |
| 7303 | Referer: http://www.w3.org/hypertext/DataSources/Overview.html |
| 7304 | |
| 7305 | If the field value is a partial URI, it SHOULD be interpreted |
| 7306 | relative to the Request-URI. The URI MUST NOT include a fragment. |
| 7307 | |
| 7308 | Note: Because the source of a link may be private information or |
| 7309 | may reveal an otherwise private information source, it is strongly |
| 7310 | recommended that the user be able to select whether or not the |
| 7311 | Referer field is sent. For example, a browser client could have a |
| 7312 | toggle switch for browsing openly/anonymously, which would |
| 7313 | respectively enable/disable the sending of Referer and From |
| 7314 | information. |
| 7315 | |
| 7316 | 14.38 Retry-After |
| 7317 | |
| 7318 | The Retry-After response-header field can be used with a 503 (Service |
| 7319 | Unavailable) response to indicate how long the service is expected to |
| 7320 | be unavailable to the requesting client. The value of this field can |
| 7321 | be either an HTTP-date or an integer number of seconds (in decimal) |
| 7322 | after the time of the response. |
| 7323 | |
| 7324 | Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |
| 7325 | |
| 7326 | Two examples of its use are |
| 7327 | |
| 7328 | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
| 7329 | Retry-After: 120 |
| 7330 | |
| 7331 | In the latter example, the delay is 2 minutes. |
| 7332 | |
| 7333 | |
| 7334 | |
| 7335 | |
| 7336 | |
| 7337 | |
| 7338 | Fielding, et. al. Standards Track [Page 131] |
| 7339 | \f |
| 7340 | RFC 2068 HTTP/1.1 January 1997 |
| 7341 | |
| 7342 | |
| 7343 | 14.39 Server |
| 7344 | |
| 7345 | The Server response-header field contains information about the |
| 7346 | software used by the origin server to handle the request. The field |
| 7347 | can contain multiple product tokens (section 3.8) and comments |
| 7348 | identifying the server and any significant subproducts. The product |
| 7349 | tokens are listed in order of their significance for identifying the |
| 7350 | application. |
| 7351 | |
| 7352 | Server = "Server" ":" 1*( product | comment ) |
| 7353 | |
| 7354 | Example: |
| 7355 | |
| 7356 | Server: CERN/3.0 libwww/2.17 |
| 7357 | |
| 7358 | If the response is being forwarded through a proxy, the proxy |
| 7359 | application MUST NOT modify the Server response-header. Instead, it |
| 7360 | SHOULD include a Via field (as described in section 14.44). |
| 7361 | |
| 7362 | Note: Revealing the specific software version of the server may |
| 7363 | allow the server machine to become more vulnerable to attacks |
| 7364 | against software that is known to contain security holes. Server |
| 7365 | implementers are encouraged to make this field a configurable |
| 7366 | option. |
| 7367 | |
| 7368 | 14.40 Transfer-Encoding |
| 7369 | |
| 7370 | The Transfer-Encoding general-header field indicates what (if any) |
| 7371 | type of transformation has been applied to the message body in order |
| 7372 | to safely transfer it between the sender and the recipient. This |
| 7373 | differs from the Content-Encoding in that the transfer coding is a |
| 7374 | property of the message, not of the entity. |
| 7375 | |
| 7376 | Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer- |
| 7377 | coding |
| 7378 | |
| 7379 | Transfer codings are defined in section 3.6. An example is: |
| 7380 | |
| 7381 | Transfer-Encoding: chunked |
| 7382 | |
| 7383 | Many older HTTP/1.0 applications do not understand the Transfer- |
| 7384 | Encoding header. |
| 7385 | |
| 7386 | 14.41 Upgrade |
| 7387 | |
| 7388 | The Upgrade general-header allows the client to specify what |
| 7389 | additional communication protocols it supports and would like to use |
| 7390 | if the server finds it appropriate to switch protocols. The server |
| 7391 | |
| 7392 | |
| 7393 | |
| 7394 | Fielding, et. al. Standards Track [Page 132] |
| 7395 | \f |
| 7396 | RFC 2068 HTTP/1.1 January 1997 |
| 7397 | |
| 7398 | |
| 7399 | MUST use the Upgrade header field within a 101 (Switching Protocols) |
| 7400 | response to indicate which protocol(s) are being switched. |
| 7401 | |
| 7402 | Upgrade = "Upgrade" ":" 1#product |
| 7403 | |
| 7404 | For example, |
| 7405 | |
| 7406 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| 7407 | |
| 7408 | The Upgrade header field is intended to provide a simple mechanism |
| 7409 | for transition from HTTP/1.1 to some other, incompatible protocol. It |
| 7410 | does so by allowing the client to advertise its desire to use another |
| 7411 | protocol, such as a later version of HTTP with a higher major version |
| 7412 | number, even though the current request has been made using HTTP/1.1. |
| 7413 | This eases the difficult transition between incompatible protocols by |
| 7414 | allowing the client to initiate a request in the more commonly |
| 7415 | supported protocol while indicating to the server that it would like |
| 7416 | to use a "better" protocol if available (where "better" is determined |
| 7417 | by the server, possibly according to the nature of the method and/or |
| 7418 | resource being requested). |
| 7419 | |
| 7420 | The Upgrade header field only applies to switching application-layer |
| 7421 | protocols upon the existing transport-layer connection. Upgrade |
| 7422 | cannot be used to insist on a protocol change; its acceptance and use |
| 7423 | by the server is optional. The capabilities and nature of the |
| 7424 | application-layer communication after the protocol change is entirely |
| 7425 | dependent upon the new protocol chosen, although the first action |
| 7426 | after changing the protocol MUST be a response to the initial HTTP |
| 7427 | request containing the Upgrade header field. |
| 7428 | |
| 7429 | The Upgrade header field only applies to the immediate connection. |
| 7430 | Therefore, the upgrade keyword MUST be supplied within a Connection |
| 7431 | header field (section 14.10) whenever Upgrade is present in an |
| 7432 | HTTP/1.1 message. |
| 7433 | |
| 7434 | The Upgrade header field cannot be used to indicate a switch to a |
| 7435 | protocol on a different connection. For that purpose, it is more |
| 7436 | appropriate to use a 301, 302, 303, or 305 redirection response. |
| 7437 | |
| 7438 | This specification only defines the protocol name "HTTP" for use by |
| 7439 | the family of Hypertext Transfer Protocols, as defined by the HTTP |
| 7440 | version rules of section 3.1 and future updates to this |
| 7441 | specification. Any token can be used as a protocol name; however, it |
| 7442 | will only be useful if both the client and server associate the name |
| 7443 | with the same protocol. |
| 7444 | |
| 7445 | |
| 7446 | |
| 7447 | |
| 7448 | |
| 7449 | |
| 7450 | Fielding, et. al. Standards Track [Page 133] |
| 7451 | \f |
| 7452 | RFC 2068 HTTP/1.1 January 1997 |
| 7453 | |
| 7454 | |
| 7455 | 14.42 User-Agent |
| 7456 | |
| 7457 | The User-Agent request-header field contains information about the |
| 7458 | user agent originating the request. This is for statistical purposes, |
| 7459 | the tracing of protocol violations, and automated recognition of user |
| 7460 | agents for the sake of tailoring responses to avoid particular user |
| 7461 | agent limitations. User agents SHOULD include this field with |
| 7462 | requests. The field can contain multiple product tokens (section 3.8) |
| 7463 | and comments identifying the agent and any subproducts which form a |
| 7464 | significant part of the user agent. By convention, the product tokens |
| 7465 | are listed in order of their significance for identifying the |
| 7466 | application. |
| 7467 | |
| 7468 | User-Agent = "User-Agent" ":" 1*( product | comment ) |
| 7469 | |
| 7470 | Example: |
| 7471 | |
| 7472 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| 7473 | |
| 7474 | 14.43 Vary |
| 7475 | |
| 7476 | The Vary response-header field is used by a server to signal that the |
| 7477 | response entity was selected from the available representations of |
| 7478 | the response using server-driven negotiation (section 12). Field- |
| 7479 | names listed in Vary headers are those of request-headers. The Vary |
| 7480 | field value indicates either that the given set of header fields |
| 7481 | encompass the dimensions over which the representation might vary, or |
| 7482 | that the dimensions of variance are unspecified ("*") and thus may |
| 7483 | vary over any aspect of future requests. |
| 7484 | |
| 7485 | Vary = "Vary" ":" ( "*" | 1#field-name ) |
| 7486 | |
| 7487 | An HTTP/1.1 server MUST include an appropriate Vary header field with |
| 7488 | any cachable response that is subject to server-driven negotiation. |
| 7489 | Doing so allows a cache to properly interpret future requests on that |
| 7490 | resource and informs the user agent about the presence of negotiation |
| 7491 | on that resource. A server SHOULD include an appropriate Vary header |
| 7492 | field with a non-cachable response that is subject to server-driven |
| 7493 | negotiation, since this might provide the user agent with useful |
| 7494 | information about the dimensions over which the response might vary. |
| 7495 | |
| 7496 | The set of header fields named by the Vary field value is known as |
| 7497 | the "selecting" request-headers. |
| 7498 | |
| 7499 | When the cache receives a subsequent request whose Request-URI |
| 7500 | specifies one or more cache entries including a Vary header, the |
| 7501 | cache MUST NOT use such a cache entry to construct a response to the |
| 7502 | new request unless all of the headers named in the cached Vary header |
| 7503 | |
| 7504 | |
| 7505 | |
| 7506 | Fielding, et. al. Standards Track [Page 134] |
| 7507 | \f |
| 7508 | RFC 2068 HTTP/1.1 January 1997 |
| 7509 | |
| 7510 | |
| 7511 | are present in the new request, and all of the stored selecting |
| 7512 | request-headers from the previous request match the corresponding |
| 7513 | headers in the new request. |
| 7514 | |
| 7515 | The selecting request-headers from two requests are defined to match |
| 7516 | if and only if the selecting request-headers in the first request can |
| 7517 | be transformed to the selecting request-headers in the second request |
| 7518 | by adding or removing linear whitespace (LWS) at places where this is |
| 7519 | allowed by the corresponding BNF, and/or combining multiple message- |
| 7520 | header fields with the same field name following the rules about |
| 7521 | message headers in section 4.2. |
| 7522 | |
| 7523 | A Vary field value of "*" signals that unspecified parameters, |
| 7524 | possibly other than the contents of request-header fields (e.g., the |
| 7525 | network address of the client), play a role in the selection of the |
| 7526 | response representation. Subsequent requests on that resource can |
| 7527 | only be properly interpreted by the origin server, and thus a cache |
| 7528 | MUST forward a (possibly conditional) request even when it has a |
| 7529 | fresh response cached for the resource. See section 13.6 for use of |
| 7530 | the Vary header by caches. |
| 7531 | |
| 7532 | A Vary field value consisting of a list of field-names signals that |
| 7533 | the representation selected for the response is based on a selection |
| 7534 | algorithm which considers ONLY the listed request-header field values |
| 7535 | in selecting the most appropriate representation. A cache MAY assume |
| 7536 | that the same selection will be made for future requests with the |
| 7537 | same values for the listed field names, for the duration of time in |
| 7538 | which the response is fresh. |
| 7539 | |
| 7540 | The field-names given are not limited to the set of standard |
| 7541 | request-header fields defined by this specification. Field names are |
| 7542 | case-insensitive. |
| 7543 | |
| 7544 | 14.44 Via |
| 7545 | |
| 7546 | The Via general-header field MUST be used by gateways and proxies to |
| 7547 | indicate the intermediate protocols and recipients between the user |
| 7548 | agent and the server on requests, and between the origin server and |
| 7549 | the client on responses. It is analogous to the "Received" field of |
| 7550 | RFC 822 and is intended to be used for tracking message forwards, |
| 7551 | avoiding request loops, and identifying the protocol capabilities of |
| 7552 | all senders along the request/response chain. |
| 7553 | |
| 7554 | |
| 7555 | |
| 7556 | |
| 7557 | |
| 7558 | |
| 7559 | |
| 7560 | |
| 7561 | |
| 7562 | Fielding, et. al. Standards Track [Page 135] |
| 7563 | \f |
| 7564 | RFC 2068 HTTP/1.1 January 1997 |
| 7565 | |
| 7566 | |
| 7567 | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) |
| 7568 | |
| 7569 | received-protocol = [ protocol-name "/" ] protocol-version |
| 7570 | protocol-name = token |
| 7571 | protocol-version = token |
| 7572 | received-by = ( host [ ":" port ] ) | pseudonym |
| 7573 | pseudonym = token |
| 7574 | |
| 7575 | The received-protocol indicates the protocol version of the message |
| 7576 | received by the server or client along each segment of the |
| 7577 | request/response chain. The received-protocol version is appended to |
| 7578 | the Via field value when the message is forwarded so that information |
| 7579 | about the protocol capabilities of upstream applications remains |
| 7580 | visible to all recipients. |
| 7581 | |
| 7582 | The protocol-name is optional if and only if it would be "HTTP". The |
| 7583 | received-by field is normally the host and optional port number of a |
| 7584 | recipient server or client that subsequently forwarded the message. |
| 7585 | However, if the real host is considered to be sensitive information, |
| 7586 | it MAY be replaced by a pseudonym. If the port is not given, it MAY |
| 7587 | be assumed to be the default port of the received-protocol. |
| 7588 | |
| 7589 | Multiple Via field values represent each proxy or gateway that has |
| 7590 | forwarded the message. Each recipient MUST append its information |
| 7591 | such that the end result is ordered according to the sequence of |
| 7592 | forwarding applications. |
| 7593 | |
| 7594 | Comments MAY be used in the Via header field to identify the software |
| 7595 | of the recipient proxy or gateway, analogous to the User-Agent and |
| 7596 | Server header fields. However, all comments in the Via field are |
| 7597 | optional and MAY be removed by any recipient prior to forwarding the |
| 7598 | message. |
| 7599 | |
| 7600 | For example, a request message could be sent from an HTTP/1.0 user |
| 7601 | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
| 7602 | forward the request to a public proxy at nowhere.com, which completes |
| 7603 | the request by forwarding it to the origin server at www.ics.uci.edu. |
| 7604 | The request received by www.ics.uci.edu would then have the following |
| 7605 | Via header field: |
| 7606 | |
| 7607 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| 7608 | |
| 7609 | Proxies and gateways used as a portal through a network firewall |
| 7610 | SHOULD NOT, by default, forward the names and ports of hosts within |
| 7611 | the firewall region. This information SHOULD only be propagated if |
| 7612 | explicitly enabled. If not enabled, the received-by host of any host |
| 7613 | behind the firewall SHOULD be replaced by an appropriate pseudonym |
| 7614 | for that host. |
| 7615 | |
| 7616 | |
| 7617 | |
| 7618 | Fielding, et. al. Standards Track [Page 136] |
| 7619 | \f |
| 7620 | RFC 2068 HTTP/1.1 January 1997 |
| 7621 | |
| 7622 | |
| 7623 | For organizations that have strong privacy requirements for hiding |
| 7624 | internal structures, a proxy MAY combine an ordered subsequence of |
| 7625 | Via header field entries with identical received-protocol values into |
| 7626 | a single such entry. For example, |
| 7627 | |
| 7628 | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
| 7629 | |
| 7630 | could be collapsed to |
| 7631 | |
| 7632 | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
| 7633 | |
| 7634 | Applications SHOULD NOT combine multiple entries unless they are all |
| 7635 | under the same organizational control and the hosts have already been |
| 7636 | replaced by pseudonyms. Applications MUST NOT combine entries which |
| 7637 | have different received-protocol values. |
| 7638 | |
| 7639 | 14.45 Warning |
| 7640 | |
| 7641 | The Warning response-header field is used to carry additional |
| 7642 | information about the status of a response which may not be reflected |
| 7643 | by the response status code. This information is typically, though |
| 7644 | not exclusively, used to warn about a possible lack of semantic |
| 7645 | transparency from caching operations. |
| 7646 | |
| 7647 | Warning headers are sent with responses using: |
| 7648 | |
| 7649 | Warning = "Warning" ":" 1#warning-value |
| 7650 | |
| 7651 | warning-value = warn-code SP warn-agent SP warn-text |
| 7652 | warn-code = 2DIGIT |
| 7653 | warn-agent = ( host [ ":" port ] ) | pseudonym |
| 7654 | ; the name or pseudonym of the server adding |
| 7655 | ; the Warning header, for use in debugging |
| 7656 | warn-text = quoted-string |
| 7657 | |
| 7658 | A response may carry more than one Warning header. |
| 7659 | |
| 7660 | The warn-text should be in a natural language and character set that |
| 7661 | is most likely to be intelligible to the human user receiving the |
| 7662 | response. This decision may be based on any available knowledge, |
| 7663 | such as the location of the cache or user, the Accept-Language field |
| 7664 | in a request, the Content-Language field in a response, etc. The |
| 7665 | default language is English and the default character set is ISO- |
| 7666 | 8859-1. |
| 7667 | |
| 7668 | If a character set other than ISO-8859-1 is used, it MUST be encoded |
| 7669 | in the warn-text using the method described in RFC 1522 [14]. |
| 7670 | |
| 7671 | |
| 7672 | |
| 7673 | |
| 7674 | Fielding, et. al. Standards Track [Page 137] |
| 7675 | \f |
| 7676 | RFC 2068 HTTP/1.1 January 1997 |
| 7677 | |
| 7678 | |
| 7679 | Any server or cache may add Warning headers to a response. New |
| 7680 | Warning headers should be added after any existing Warning headers. A |
| 7681 | cache MUST NOT delete any Warning header that it received with a |
| 7682 | response. However, if a cache successfully validates a cache entry, |
| 7683 | it SHOULD remove any Warning headers previously attached to that |
| 7684 | entry except as specified for specific Warning codes. It MUST then |
| 7685 | add any Warning headers received in the validating response. In other |
| 7686 | words, Warning headers are those that would be attached to the most |
| 7687 | recent relevant response. |
| 7688 | |
| 7689 | When multiple Warning headers are attached to a response, the user |
| 7690 | agent SHOULD display as many of them as possible, in the order that |
| 7691 | they appear in the response. If it is not possible to display all of |
| 7692 | the warnings, the user agent should follow these heuristics: |
| 7693 | |
| 7694 | o Warnings that appear early in the response take priority over those |
| 7695 | appearing later in the response. |
| 7696 | o Warnings in the user's preferred character set take priority over |
| 7697 | warnings in other character sets but with identical warn-codes and |
| 7698 | warn-agents. |
| 7699 | |
| 7700 | Systems that generate multiple Warning headers should order them with |
| 7701 | this user agent behavior in mind. |
| 7702 | |
| 7703 | This is a list of the currently-defined warn-codes, each with a |
| 7704 | recommended warn-text in English, and a description of its meaning. |
| 7705 | |
| 7706 | 10 Response is stale |
| 7707 | MUST be included whenever the returned response is stale. A cache may |
| 7708 | add this warning to any response, but may never remove it until the |
| 7709 | response is known to be fresh. |
| 7710 | |
| 7711 | 11 Revalidation failed |
| 7712 | MUST be included if a cache returns a stale response because an |
| 7713 | attempt to revalidate the response failed, due to an inability to |
| 7714 | reach the server. A cache may add this warning to any response, but |
| 7715 | may never remove it until the response is successfully revalidated. |
| 7716 | |
| 7717 | 12 Disconnected operation |
| 7718 | SHOULD be included if the cache is intentionally disconnected from |
| 7719 | the rest of the network for a period of time. |
| 7720 | |
| 7721 | 13 Heuristic expiration |
| 7722 | MUST be included if the cache heuristically chose a freshness |
| 7723 | lifetime greater than 24 hours and the response's age is greater than |
| 7724 | 24 hours. |
| 7725 | |
| 7726 | |
| 7727 | |
| 7728 | |
| 7729 | |
| 7730 | Fielding, et. al. Standards Track [Page 138] |
| 7731 | \f |
| 7732 | RFC 2068 HTTP/1.1 January 1997 |
| 7733 | |
| 7734 | |
| 7735 | 14 Transformation applied |
| 7736 | MUST be added by an intermediate cache or proxy if it applies any |
| 7737 | transformation changing the content-coding (as specified in the |
| 7738 | Content-Encoding header) or media-type (as specified in the |
| 7739 | Content-Type header) of the response, unless this Warning code |
| 7740 | already appears in the response. MUST NOT be deleted from a response |
| 7741 | even after revalidation. |
| 7742 | |
| 7743 | 99 Miscellaneous warning |
| 7744 | The warning text may include arbitrary information to be presented to |
| 7745 | a human user, or logged. A system receiving this warning MUST NOT |
| 7746 | take any automated action. |
| 7747 | |
| 7748 | 14.46 WWW-Authenticate |
| 7749 | |
| 7750 | The WWW-Authenticate response-header field MUST be included in 401 |
| 7751 | (Unauthorized) response messages. The field value consists of at |
| 7752 | least one challenge that indicates the authentication scheme(s) and |
| 7753 | parameters applicable to the Request-URI. |
| 7754 | |
| 7755 | WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge |
| 7756 | |
| 7757 | The HTTP access authentication process is described in section 11. |
| 7758 | User agents MUST take special care in parsing the WWW-Authenticate |
| 7759 | field value if it contains more than one challenge, or if more than |
| 7760 | one WWW-Authenticate header field is provided, since the contents of |
| 7761 | a challenge may itself contain a comma-separated list of |
| 7762 | authentication parameters. |
| 7763 | |
| 7764 | 15 Security Considerations |
| 7765 | |
| 7766 | This section is meant to inform application developers, information |
| 7767 | providers, and users of the security limitations in HTTP/1.1 as |
| 7768 | described by this document. The discussion does not include |
| 7769 | definitive solutions to the problems revealed, though it does make |
| 7770 | some suggestions for reducing security risks. |
| 7771 | |
| 7772 | 15.1 Authentication of Clients |
| 7773 | |
| 7774 | The Basic authentication scheme is not a secure method of user |
| 7775 | authentication, nor does it in any way protect the entity, which is |
| 7776 | transmitted in clear text across the physical network used as the |
| 7777 | carrier. HTTP does not prevent additional authentication schemes and |
| 7778 | encryption mechanisms from being employed to increase security or the |
| 7779 | addition of enhancements (such as schemes to use one-time passwords) |
| 7780 | to Basic authentication. |
| 7781 | |
| 7782 | |
| 7783 | |
| 7784 | |
| 7785 | |
| 7786 | Fielding, et. al. Standards Track [Page 139] |
| 7787 | \f |
| 7788 | RFC 2068 HTTP/1.1 January 1997 |
| 7789 | |
| 7790 | |
| 7791 | The most serious flaw in Basic authentication is that it results in |
| 7792 | the essentially clear text transmission of the user's password over |
| 7793 | the physical network. It is this problem which Digest Authentication |
| 7794 | attempts to address. |
| 7795 | |
| 7796 | Because Basic authentication involves the clear text transmission of |
| 7797 | passwords it SHOULD never be used (without enhancements) to protect |
| 7798 | sensitive or valuable information. |
| 7799 | |
| 7800 | A common use of Basic authentication is for identification purposes |
| 7801 | -- requiring the user to provide a user name and password as a means |
| 7802 | of identification, for example, for purposes of gathering accurate |
| 7803 | usage statistics on a server. When used in this way it is tempting to |
| 7804 | think that there is no danger in its use if illicit access to the |
| 7805 | protected documents is not a major concern. This is only correct if |
| 7806 | the server issues both user name and password to the users and in |
| 7807 | particular does not allow the user to choose his or her own password. |
| 7808 | The danger arises because naive users frequently reuse a single |
| 7809 | password to avoid the task of maintaining multiple passwords. |
| 7810 | |
| 7811 | If a server permits users to select their own passwords, then the |
| 7812 | threat is not only illicit access to documents on the server but also |
| 7813 | illicit access to the accounts of all users who have chosen to use |
| 7814 | their account password. If users are allowed to choose their own |
| 7815 | password that also means the server must maintain files containing |
| 7816 | the (presumably encrypted) passwords. Many of these may be the |
| 7817 | account passwords of users perhaps at distant sites. The owner or |
| 7818 | administrator of such a system could conceivably incur liability if |
| 7819 | this information is not maintained in a secure fashion. |
| 7820 | |
| 7821 | Basic Authentication is also vulnerable to spoofing by counterfeit |
| 7822 | servers. If a user can be led to believe that he is connecting to a |
| 7823 | host containing information protected by basic authentication when in |
| 7824 | fact he is connecting to a hostile server or gateway then the |
| 7825 | attacker can request a password, store it for later use, and feign an |
| 7826 | error. This type of attack is not possible with Digest Authentication |
| 7827 | [32]. Server implementers SHOULD guard against the possibility of |
| 7828 | this sort of counterfeiting by gateways or CGI scripts. In particular |
| 7829 | it is very dangerous for a server to simply turn over a connection to |
| 7830 | a gateway since that gateway can then use the persistent connection |
| 7831 | mechanism to engage in multiple transactions with the client while |
| 7832 | impersonating the original server in a way that is not detectable by |
| 7833 | the client. |
| 7834 | |
| 7835 | 15.2 Offering a Choice of Authentication Schemes |
| 7836 | |
| 7837 | An HTTP/1.1 server may return multiple challenges with a 401 |
| 7838 | (Authenticate) response, and each challenge may use a different |
| 7839 | |
| 7840 | |
| 7841 | |
| 7842 | Fielding, et. al. Standards Track [Page 140] |
| 7843 | \f |
| 7844 | RFC 2068 HTTP/1.1 January 1997 |
| 7845 | |
| 7846 | |
| 7847 | scheme. The order of the challenges returned to the user agent is in |
| 7848 | the order that the server would prefer they be chosen. The server |
| 7849 | should order its challenges with the "most secure" authentication |
| 7850 | scheme first. A user agent should choose as the challenge to be made |
| 7851 | to the user the first one that the user agent understands. |
| 7852 | |
| 7853 | When the server offers choices of authentication schemes using the |
| 7854 | WWW-Authenticate header, the "security" of the authentication is only |
| 7855 | as malicious user could capture the set of challenges and try to |
| 7856 | authenticate him/herself using the weakest of the authentication |
| 7857 | schemes. Thus, the ordering serves more to protect the user's |
| 7858 | credentials than the server's information. |
| 7859 | |
| 7860 | A possible man-in-the-middle (MITM) attack would be to add a weak |
| 7861 | authentication scheme to the set of choices, hoping that the client |
| 7862 | will use one that exposes the user's credentials (e.g. password). For |
| 7863 | this reason, the client should always use the strongest scheme that |
| 7864 | it understands from the choices accepted. |
| 7865 | |
| 7866 | An even better MITM attack would be to remove all offered choices, |
| 7867 | and to insert a challenge that requests Basic authentication. For |
| 7868 | this reason, user agents that are concerned about this kind of attack |
| 7869 | could remember the strongest authentication scheme ever requested by |
| 7870 | a server and produce a warning message that requires user |
| 7871 | confirmation before using a weaker one. A particularly insidious way |
| 7872 | to mount such a MITM attack would be to offer a "free" proxy caching |
| 7873 | service to gullible users. |
| 7874 | |
| 7875 | 15.3 Abuse of Server Log Information |
| 7876 | |
| 7877 | A server is in the position to save personal data about a user's |
| 7878 | requests which may identify their reading patterns or subjects of |
| 7879 | interest. This information is clearly confidential in nature and its |
| 7880 | handling may be constrained by law in certain countries. People using |
| 7881 | the HTTP protocol to provide data are responsible for ensuring that |
| 7882 | such material is not distributed without the permission of any |
| 7883 | individuals that are identifiable by the published results. |
| 7884 | |
| 7885 | 15.4 Transfer of Sensitive Information |
| 7886 | |
| 7887 | Like any generic data transfer protocol, HTTP cannot regulate the |
| 7888 | content of the data that is transferred, nor is there any a priori |
| 7889 | method of determining the sensitivity of any particular piece of |
| 7890 | information within the context of any given request. Therefore, |
| 7891 | applications SHOULD supply as much control over this information as |
| 7892 | possible to the provider of that information. Four header fields are |
| 7893 | worth special mention in this context: Server, Via, Referer and From. |
| 7894 | |
| 7895 | |
| 7896 | |
| 7897 | |
| 7898 | Fielding, et. al. Standards Track [Page 141] |
| 7899 | \f |
| 7900 | RFC 2068 HTTP/1.1 January 1997 |
| 7901 | |
| 7902 | |
| 7903 | Revealing the specific software version of the server may allow the |
| 7904 | server machine to become more vulnerable to attacks against software |
| 7905 | that is known to contain security holes. Implementers SHOULD make the |
| 7906 | Server header field a configurable option. |
| 7907 | |
| 7908 | Proxies which serve as a portal through a network firewall SHOULD |
| 7909 | take special precautions regarding the transfer of header information |
| 7910 | that identifies the hosts behind the firewall. In particular, they |
| 7911 | SHOULD remove, or replace with sanitized versions, any Via fields |
| 7912 | generated behind the firewall. |
| 7913 | |
| 7914 | The Referer field allows reading patterns to be studied and reverse |
| 7915 | links drawn. Although it can be very useful, its power can be abused |
| 7916 | if user details are not separated from the information contained in |
| 7917 | the Referer. Even when the personal information has been removed, the |
| 7918 | Referer field may indicate a private document's URI whose publication |
| 7919 | would be inappropriate. |
| 7920 | |
| 7921 | The information sent in the From field might conflict with the user's |
| 7922 | privacy interests or their site's security policy, and hence it |
| 7923 | SHOULD NOT be transmitted without the user being able to disable, |
| 7924 | enable, and modify the contents of the field. The user MUST be able |
| 7925 | to set the contents of this field within a user preference or |
| 7926 | application defaults configuration. |
| 7927 | |
| 7928 | We suggest, though do not require, that a convenient toggle interface |
| 7929 | be provided for the user to enable or disable the sending of From and |
| 7930 | Referer information. |
| 7931 | |
| 7932 | 15.5 Attacks Based On File and Path Names |
| 7933 | |
| 7934 | Implementations of HTTP origin servers SHOULD be careful to restrict |
| 7935 | the documents returned by HTTP requests to be only those that were |
| 7936 | intended by the server administrators. If an HTTP server translates |
| 7937 | HTTP URIs directly into file system calls, the server MUST take |
| 7938 | special care not to serve files that were not intended to be |
| 7939 | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |
| 7940 | other operating systems use ".." as a path component to indicate a |
| 7941 | directory level above the current one. On such a system, an HTTP |
| 7942 | server MUST disallow any such construct in the Request-URI if it |
| 7943 | would otherwise allow access to a resource outside those intended to |
| 7944 | be accessible via the HTTP server. Similarly, files intended for |
| 7945 | reference only internally to the server (such as access control |
| 7946 | files, configuration files, and script code) MUST be protected from |
| 7947 | inappropriate retrieval, since they might contain sensitive |
| 7948 | information. Experience has shown that minor bugs in such HTTP server |
| 7949 | implementations have turned into security risks. |
| 7950 | |
| 7951 | |
| 7952 | |
| 7953 | |
| 7954 | Fielding, et. al. Standards Track [Page 142] |
| 7955 | \f |
| 7956 | RFC 2068 HTTP/1.1 January 1997 |
| 7957 | |
| 7958 | |
| 7959 | 15.6 Personal Information |
| 7960 | |
| 7961 | HTTP clients are often privy to large amounts of personal information |
| 7962 | (e.g. the user's name, location, mail address, passwords, encryption |
| 7963 | keys, etc.), and SHOULD be very careful to prevent unintentional |
| 7964 | leakage of this information via the HTTP protocol to other sources. |
| 7965 | We very strongly recommend that a convenient interface be provided |
| 7966 | for the user to control dissemination of such information, and that |
| 7967 | designers and implementers be particularly careful in this area. |
| 7968 | History shows that errors in this area are often both serious |
| 7969 | security and/or privacy problems, and often generate highly adverse |
| 7970 | publicity for the implementer's company. |
| 7971 | |
| 7972 | 15.7 Privacy Issues Connected to Accept Headers |
| 7973 | |
| 7974 | Accept request-headers can reveal information about the user to all |
| 7975 | servers which are accessed. The Accept-Language header in particular |
| 7976 | can reveal information the user would consider to be of a private |
| 7977 | nature, because the understanding of particular languages is often |
| 7978 | strongly correlated to the membership of a particular ethnic group. |
| 7979 | User agents which offer the option to configure the contents of an |
| 7980 | Accept-Language header to be sent in every request are strongly |
| 7981 | encouraged to let the configuration process include a message which |
| 7982 | makes the user aware of the loss of privacy involved. |
| 7983 | |
| 7984 | An approach that limits the loss of privacy would be for a user agent |
| 7985 | to omit the sending of Accept-Language headers by default, and to ask |
| 7986 | the user whether it should start sending Accept-Language headers to a |
| 7987 | server if it detects, by looking for any Vary response-header fields |
| 7988 | generated by the server, that such sending could improve the quality |
| 7989 | of service. |
| 7990 | |
| 7991 | Elaborate user-customized accept header fields sent in every request, |
| 7992 | in particular if these include quality values, can be used by servers |
| 7993 | as relatively reliable and long-lived user identifiers. Such user |
| 7994 | identifiers would allow content providers to do click-trail tracking, |
| 7995 | and would allow collaborating content providers to match cross-server |
| 7996 | click-trails or form submissions of individual users. Note that for |
| 7997 | many users not behind a proxy, the network address of the host |
| 7998 | running the user agent will also serve as a long-lived user |
| 7999 | identifier. In environments where proxies are used to enhance |
| 8000 | privacy, user agents should be conservative in offering accept header |
| 8001 | configuration options to end users. As an extreme privacy measure, |
| 8002 | proxies could filter the accept headers in relayed requests. General |
| 8003 | purpose user agents which provide a high degree of header |
| 8004 | configurability should warn users about the loss of privacy which can |
| 8005 | be involved. |
| 8006 | |
| 8007 | |
| 8008 | |
| 8009 | |
| 8010 | Fielding, et. al. Standards Track [Page 143] |
| 8011 | \f |
| 8012 | RFC 2068 HTTP/1.1 January 1997 |
| 8013 | |
| 8014 | |
| 8015 | 15.8 DNS Spoofing |
| 8016 | |
| 8017 | Clients using HTTP rely heavily on the Domain Name Service, and are |
| 8018 | thus generally prone to security attacks based on the deliberate |
| 8019 | mis-association of IP addresses and DNS names. Clients need to be |
| 8020 | cautious in assuming the continuing validity of an IP number/DNS name |
| 8021 | association. |
| 8022 | |
| 8023 | In particular, HTTP clients SHOULD rely on their name resolver for |
| 8024 | confirmation of an IP number/DNS name association, rather than |
| 8025 | caching the result of previous host name lookups. Many platforms |
| 8026 | already can cache host name lookups locally when appropriate, and |
| 8027 | they SHOULD be configured to do so. These lookups should be cached, |
| 8028 | however, only when the TTL (Time To Live) information reported by the |
| 8029 | name server makes it likely that the cached information will remain |
| 8030 | useful. |
| 8031 | |
| 8032 | If HTTP clients cache the results of host name lookups in order to |
| 8033 | achieve a performance improvement, they MUST observe the TTL |
| 8034 | information reported by DNS. |
| 8035 | |
| 8036 | If HTTP clients do not observe this rule, they could be spoofed when |
| 8037 | a previously-accessed server's IP address changes. As network |
| 8038 | renumbering is expected to become increasingly common, the |
| 8039 | possibility of this form of attack will grow. Observing this |
| 8040 | requirement thus reduces this potential security vulnerability. |
| 8041 | |
| 8042 | This requirement also improves the load-balancing behavior of clients |
| 8043 | for replicated servers using the same DNS name and reduces the |
| 8044 | likelihood of a user's experiencing failure in accessing sites which |
| 8045 | use that strategy. |
| 8046 | |
| 8047 | 15.9 Location Headers and Spoofing |
| 8048 | |
| 8049 | If a single server supports multiple organizations that do not trust |
| 8050 | one another, then it must check the values of Location and Content- |
| 8051 | Location headers in responses that are generated under control of |
| 8052 | said organizations to make sure that they do not attempt to |
| 8053 | invalidate resources over which they have no authority. |
| 8054 | |
| 8055 | 16 Acknowledgments |
| 8056 | |
| 8057 | This specification makes heavy use of the augmented BNF and generic |
| 8058 | constructs defined by David H. Crocker for RFC 822. Similarly, it |
| 8059 | reuses many of the definitions provided by Nathaniel Borenstein and |
| 8060 | Ned Freed for MIME. We hope that their inclusion in this |
| 8061 | specification will help reduce past confusion over the relationship |
| 8062 | between HTTP and Internet mail message formats. |
| 8063 | |
| 8064 | |
| 8065 | |
| 8066 | Fielding, et. al. Standards Track [Page 144] |
| 8067 | \f |
| 8068 | RFC 2068 HTTP/1.1 January 1997 |
| 8069 | |
| 8070 | |
| 8071 | The HTTP protocol has evolved considerably over the past four years. |
| 8072 | It has benefited from a large and active developer community--the |
| 8073 | many people who have participated on the www-talk mailing list--and |
| 8074 | it is that community which has been most responsible for the success |
| 8075 | of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |
| 8076 | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |
| 8077 | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |
| 8078 | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |
| 8079 | VanHeyningen deserve special recognition for their efforts in |
| 8080 | defining early aspects of the protocol. |
| 8081 | |
| 8082 | This document has benefited greatly from the comments of all those |
| 8083 | participating in the HTTP-WG. In addition to those already mentioned, |
| 8084 | the following individuals have contributed to this specification: |
| 8085 | |
| 8086 | Gary Adams Albert Lunde |
| 8087 | Harald Tveit Alvestrand John C. Mallery |
| 8088 | Keith Ball Jean-Philippe Martin-Flatin |
| 8089 | Brian Behlendorf Larry Masinter |
| 8090 | Paul Burchard Mitra |
| 8091 | Maurizio Codogno David Morris |
| 8092 | Mike Cowlishaw Gavin Nicol |
| 8093 | Roman Czyborra Bill Perry |
| 8094 | Michael A. Dolan Jeffrey Perry |
| 8095 | David J. Fiander Scott Powers |
| 8096 | Alan Freier Owen Rees |
| 8097 | Marc Hedlund Luigi Rizzo |
| 8098 | Greg Herlihy David Robinson |
| 8099 | Koen Holtman Marc Salomon |
| 8100 | Alex Hopmann Rich Salz |
| 8101 | Bob Jernigan Allan M. Schiffman |
| 8102 | Shel Kaphan Jim Seidman |
| 8103 | Rohit Khare Chuck Shotton |
| 8104 | John Klensin Eric W. Sink |
| 8105 | Martijn Koster Simon E. Spero |
| 8106 | Alexei Kosut Richard N. Taylor |
| 8107 | David M. Kristol Robert S. Thau |
| 8108 | Daniel LaLiberte Bill (BearHeart) Weinman |
| 8109 | Ben Laurie Francois Yergeau |
| 8110 | Paul J. Leach Mary Ellen Zurko |
| 8111 | Daniel DuBois |
| 8112 | |
| 8113 | Much of the content and presentation of the caching design is due to |
| 8114 | suggestions and comments from individuals including: Shel Kaphan, |
| 8115 | Paul Leach, Koen Holtman, David Morris, and Larry Masinter. |
| 8116 | |
| 8117 | |
| 8118 | |
| 8119 | |
| 8120 | |
| 8121 | |
| 8122 | Fielding, et. al. Standards Track [Page 145] |
| 8123 | \f |
| 8124 | RFC 2068 HTTP/1.1 January 1997 |
| 8125 | |
| 8126 | |
| 8127 | Most of the specification of ranges is based on work originally done |
| 8128 | by Ari Luotonen and John Franks, with additional input from Steve |
| 8129 | Zilles. |
| 8130 | |
| 8131 | Thanks to the "cave men" of Palo Alto. You know who you are. |
| 8132 | |
| 8133 | Jim Gettys (the current editor of this document) wishes particularly |
| 8134 | to thank Roy Fielding, the previous editor of this document, along |
| 8135 | with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen |
| 8136 | Holtman, John Franks, Alex Hopmann, and Larry Masinter for their |
| 8137 | help. |
| 8138 | |
| 8139 | 17 References |
| 8140 | |
| 8141 | [1] Alvestrand, H., "Tags for the identification of languages", RFC |
| 8142 | 1766, UNINETT, March 1995. |
| 8143 | |
| 8144 | [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, |
| 8145 | D., and B. Alberti. "The Internet Gopher Protocol: (a distributed |
| 8146 | document search and retrieval protocol)", RFC 1436, University of |
| 8147 | Minnesota, March 1993. |
| 8148 | |
| 8149 | [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", A |
| 8150 | Unifying Syntax for the Expression of Names and Addresses of Objects |
| 8151 | on the Network as used in the World-Wide Web", RFC 1630, CERN, June |
| 8152 | 1994. |
| 8153 | |
| 8154 | [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource |
| 8155 | Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, |
| 8156 | December 1994. |
| 8157 | |
| 8158 | [5] Berners-Lee, T., and D. Connolly, "HyperText Markup Language |
| 8159 | Specification - 2.0", RFC 1866, MIT/LCS, November 1995. |
| 8160 | |
| 8161 | [6] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext |
| 8162 | Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May |
| 8163 | 1996. |
| 8164 | |
| 8165 | [7] Freed, N., and N. Borenstein, "Multipurpose Internet Mail |
| 8166 | Extensions (MIME) Part One: Format of Internet Message Bodies", RFC |
| 8167 | 2045, Innosoft, First Virtual, November 1996. |
| 8168 | |
| 8169 | [8] Braden, R., "Requirements for Internet hosts - application and |
| 8170 | support", STD 3, RFC 1123, IETF, October 1989. |
| 8171 | |
| 8172 | [9] Crocker, D., "Standard for the Format of ARPA Internet Text |
| 8173 | Messages", STD 11, RFC 822, UDEL, August 1982. |
| 8174 | |
| 8175 | |
| 8176 | |
| 8177 | |
| 8178 | Fielding, et. al. Standards Track [Page 146] |
| 8179 | \f |
| 8180 | RFC 2068 HTTP/1.1 January 1997 |
| 8181 | |
| 8182 | |
| 8183 | [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., |
| 8184 | Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype |
| 8185 | Functional Specification", (v1.5), Thinking Machines Corporation, |
| 8186 | April 1990. |
| 8187 | |
| 8188 | [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC |
| 8189 | Irvine, June 1995. |
| 8190 | |
| 8191 | [12] Horton, M., and R. Adams. "Standard for interchange of USENET |
| 8192 | messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic |
| 8193 | Studies, December 1987. |
| 8194 | |
| 8195 | [13] Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A |
| 8196 | Proposed Standard for the Stream-Based Transmission of News", RFC |
| 8197 | 977, UC San Diego, UC Berkeley, February 1986. |
| 8198 | |
| 8199 | [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part |
| 8200 | Three: Message Header Extensions for Non-ASCII Text", RFC 2047, |
| 8201 | University of Tennessee, November 1996. |
| 8202 | |
| 8203 | [15] Nebel, E., and L. Masinter. "Form-based File Upload in HTML", |
| 8204 | RFC 1867, Xerox Corporation, November 1995. |
| 8205 | |
| 8206 | [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, |
| 8207 | USC/ISI, August 1982. |
| 8208 | |
| 8209 | [17] Postel, J., "Media Type Registration Procedure", RFC 2048, |
| 8210 | USC/ISI, November 1996. |
| 8211 | |
| 8212 | [18] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD |
| 8213 | 9, RFC 959, USC/ISI, October 1985. |
| 8214 | |
| 8215 | [19] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC |
| 8216 | 1700, USC/ISI, October 1994. |
| 8217 | |
| 8218 | [20] Sollins, K., and L. Masinter, "Functional Requirements for |
| 8219 | Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, |
| 8220 | December 1994. |
| 8221 | |
| 8222 | [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for |
| 8223 | Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. |
| 8224 | |
| 8225 | [22] ISO-8859. International Standard -- Information Processing -- |
| 8226 | 8-bit Single-Byte Coded Graphic Character Sets -- |
| 8227 | Part 1: Latin alphabet No. 1, ISO 8859-1:1987. |
| 8228 | Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. |
| 8229 | Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. |
| 8230 | Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. |
| 8231 | |
| 8232 | |
| 8233 | |
| 8234 | Fielding, et. al. Standards Track [Page 147] |
| 8235 | \f |
| 8236 | RFC 2068 HTTP/1.1 January 1997 |
| 8237 | |
| 8238 | |
| 8239 | Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. |
| 8240 | Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. |
| 8241 | Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. |
| 8242 | Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. |
| 8243 | Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. |
| 8244 | |
| 8245 | [23] Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC |
| 8246 | 1864, Carnegie Mellon, Dover Beach Consulting, October, 1995. |
| 8247 | |
| 8248 | [24] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC |
| 8249 | 1900, IAB, February 1996. |
| 8250 | |
| 8251 | [25] Deutsch, P., "GZIP file format specification version 4.3." RFC |
| 8252 | 1952, Aladdin Enterprises, May 1996. |
| 8253 | |
| 8254 | [26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP |
| 8255 | Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. |
| 8256 | 1995. Slightly revised version of paper in Proc. 2nd International |
| 8257 | WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at |
| 8258 | http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/ |
| 8259 | HTTPLatency.html. |
| 8260 | |
| 8261 | [27] Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP |
| 8262 | Performance", <URL: http://www.isi.edu/lsam/ib/http-perf/>, |
| 8263 | USC/Information Sciences Institute, June 1996 |
| 8264 | |
| 8265 | [28] Mills, D., "Network Time Protocol, Version 3, Specification, |
| 8266 | Implementation and Analysis", RFC 1305, University of Delaware, March |
| 8267 | 1992. |
| 8268 | |
| 8269 | [29] Deutsch, P., "DEFLATE Compressed Data Format Specification |
| 8270 | version 1.3." RFC 1951, Aladdin Enterprises, May 1996. |
| 8271 | |
| 8272 | [30] Spero, S., "Analysis of HTTP Performance Problems" |
| 8273 | <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>. |
| 8274 | |
| 8275 | [31] Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format |
| 8276 | Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP, |
| 8277 | May 1996. |
| 8278 | |
| 8279 | [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., |
| 8280 | Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : |
| 8281 | Digest Access Authentication", RFC 2069, January 1997. |
| 8282 | |
| 8283 | |
| 8284 | |
| 8285 | |
| 8286 | |
| 8287 | |
| 8288 | |
| 8289 | |
| 8290 | Fielding, et. al. Standards Track [Page 148] |
| 8291 | \f |
| 8292 | RFC 2068 HTTP/1.1 January 1997 |
| 8293 | |
| 8294 | |
| 8295 | 18 Authors' Addresses |
| 8296 | |
| 8297 | Roy T. Fielding |
| 8298 | Department of Information and Computer Science |
| 8299 | University of California |
| 8300 | Irvine, CA 92717-3425, USA |
| 8301 | |
| 8302 | Fax: +1 (714) 824-4056 |
| 8303 | EMail: fielding@ics.uci.edu |
| 8304 | |
| 8305 | |
| 8306 | Jim Gettys |
| 8307 | MIT Laboratory for Computer Science |
| 8308 | 545 Technology Square |
| 8309 | Cambridge, MA 02139, USA |
| 8310 | |
| 8311 | Fax: +1 (617) 258 8682 |
| 8312 | EMail: jg@w3.org |
| 8313 | |
| 8314 | |
| 8315 | Jeffrey C. Mogul |
| 8316 | Western Research Laboratory |
| 8317 | Digital Equipment Corporation |
| 8318 | 250 University Avenue |
| 8319 | Palo Alto, California, 94305, USA |
| 8320 | |
| 8321 | EMail: mogul@wrl.dec.com |
| 8322 | |
| 8323 | |
| 8324 | Henrik Frystyk Nielsen |
| 8325 | W3 Consortium |
| 8326 | MIT Laboratory for Computer Science |
| 8327 | 545 Technology Square |
| 8328 | Cambridge, MA 02139, USA |
| 8329 | |
| 8330 | Fax: +1 (617) 258 8682 |
| 8331 | EMail: frystyk@w3.org |
| 8332 | |
| 8333 | |
| 8334 | Tim Berners-Lee |
| 8335 | Director, W3 Consortium |
| 8336 | MIT Laboratory for Computer Science |
| 8337 | 545 Technology Square |
| 8338 | Cambridge, MA 02139, USA |
| 8339 | |
| 8340 | Fax: +1 (617) 258 8682 |
| 8341 | EMail: timbl@w3.org |
| 8342 | |
| 8343 | |
| 8344 | |
| 8345 | |
| 8346 | Fielding, et. al. Standards Track [Page 149] |
| 8347 | \f |
| 8348 | RFC 2068 HTTP/1.1 January 1997 |
| 8349 | |
| 8350 | |
| 8351 | 19 Appendices |
| 8352 | |
| 8353 | 19.1 Internet Media Type message/http |
| 8354 | |
| 8355 | In addition to defining the HTTP/1.1 protocol, this document serves |
| 8356 | as the specification for the Internet media type "message/http". The |
| 8357 | following is to be registered with IANA. |
| 8358 | |
| 8359 | Media Type name: message |
| 8360 | Media subtype name: http |
| 8361 | Required parameters: none |
| 8362 | Optional parameters: version, msgtype |
| 8363 | |
| 8364 | version: The HTTP-Version number of the enclosed message |
| 8365 | (e.g., "1.1"). If not present, the version can be |
| 8366 | determined from the first line of the body. |
| 8367 | |
| 8368 | msgtype: The message type -- "request" or "response". If not |
| 8369 | present, the type can be determined from the first |
| 8370 | line of the body. |
| 8371 | |
| 8372 | Encoding considerations: only "7bit", "8bit", or "binary" are |
| 8373 | permitted |
| 8374 | |
| 8375 | Security considerations: none |
| 8376 | |
| 8377 | 19.2 Internet Media Type multipart/byteranges |
| 8378 | |
| 8379 | When an HTTP message includes the content of multiple ranges (for |
| 8380 | example, a response to a request for multiple non-overlapping |
| 8381 | ranges), these are transmitted as a multipart MIME message. The |
| 8382 | multipart media type for this purpose is called |
| 8383 | "multipart/byteranges". |
| 8384 | |
| 8385 | The multipart/byteranges media type includes two or more parts, each |
| 8386 | with its own Content-Type and Content-Range fields. The parts are |
| 8387 | separated using a MIME boundary parameter. |
| 8388 | |
| 8389 | Media Type name: multipart |
| 8390 | Media subtype name: byteranges |
| 8391 | Required parameters: boundary |
| 8392 | Optional parameters: none |
| 8393 | |
| 8394 | Encoding considerations: only "7bit", "8bit", or "binary" are |
| 8395 | permitted |
| 8396 | |
| 8397 | Security considerations: none |
| 8398 | |
| 8399 | |
| 8400 | |
| 8401 | |
| 8402 | Fielding, et. al. Standards Track [Page 150] |
| 8403 | \f |
| 8404 | RFC 2068 HTTP/1.1 January 1997 |
| 8405 | |
| 8406 | |
| 8407 | For example: |
| 8408 | |
| 8409 | HTTP/1.1 206 Partial content |
| 8410 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
| 8411 | Last-modified: Wed, 15 Nov 1995 04:58:08 GMT |
| 8412 | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
| 8413 | |
| 8414 | --THIS_STRING_SEPARATES |
| 8415 | Content-type: application/pdf |
| 8416 | Content-range: bytes 500-999/8000 |
| 8417 | |
| 8418 | ...the first range... |
| 8419 | --THIS_STRING_SEPARATES |
| 8420 | Content-type: application/pdf |
| 8421 | Content-range: bytes 7000-7999/8000 |
| 8422 | |
| 8423 | ...the second range |
| 8424 | --THIS_STRING_SEPARATES-- |
| 8425 | |
| 8426 | 19.3 Tolerant Applications |
| 8427 | |
| 8428 | Although this document specifies the requirements for the generation |
| 8429 | of HTTP/1.1 messages, not all applications will be correct in their |
| 8430 | implementation. We therefore recommend that operational applications |
| 8431 | be tolerant of deviations whenever those deviations can be |
| 8432 | interpreted unambiguously. |
| 8433 | |
| 8434 | Clients SHOULD be tolerant in parsing the Status-Line and servers |
| 8435 | tolerant when parsing the Request-Line. In particular, they SHOULD |
| 8436 | accept any amount of SP or HT characters between fields, even though |
| 8437 | only a single SP is required. |
| 8438 | |
| 8439 | The line terminator for message-header fields is the sequence CRLF. |
| 8440 | However, we recommend that applications, when parsing such headers, |
| 8441 | recognize a single LF as a line terminator and ignore the leading CR. |
| 8442 | |
| 8443 | The character set of an entity-body should be labeled as the lowest |
| 8444 | common denominator of the character codes used within that body, with |
| 8445 | the exception that no label is preferred over the labels US-ASCII or |
| 8446 | ISO-8859-1. |
| 8447 | |
| 8448 | Additional rules for requirements on parsing and encoding of dates |
| 8449 | and other potential problems with date encodings include: |
| 8450 | |
| 8451 | o HTTP/1.1 clients and caches should assume that an RFC-850 date |
| 8452 | which appears to be more than 50 years in the future is in fact |
| 8453 | in the past (this helps solve the "year 2000" problem). |
| 8454 | |
| 8455 | |
| 8456 | |
| 8457 | |
| 8458 | Fielding, et. al. Standards Track [Page 151] |
| 8459 | \f |
| 8460 | RFC 2068 HTTP/1.1 January 1997 |
| 8461 | |
| 8462 | |
| 8463 | o An HTTP/1.1 implementation may internally represent a parsed |
| 8464 | Expires date as earlier than the proper value, but MUST NOT |
| 8465 | internally represent a parsed Expires date as later than the |
| 8466 | proper value. |
| 8467 | |
| 8468 | o All expiration-related calculations must be done in GMT. The |
| 8469 | local time zone MUST NOT influence the calculation or comparison |
| 8470 | of an age or expiration time. |
| 8471 | |
| 8472 | o If an HTTP header incorrectly carries a date value with a time |
| 8473 | zone other than GMT, it must be converted into GMT using the most |
| 8474 | conservative possible conversion. |
| 8475 | |
| 8476 | 19.4 Differences Between HTTP Entities and MIME Entities |
| 8477 | |
| 8478 | HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC |
| 8479 | 822) and the Multipurpose Internet Mail Extensions (MIME ) to allow |
| 8480 | entities to be transmitted in an open variety of representations and |
| 8481 | with extensible mechanisms. However, MIME [7] discusses mail, and |
| 8482 | HTTP has a few features that are different from those described in |
| 8483 | MIME. These differences were carefully chosen to optimize |
| 8484 | performance over binary connections, to allow greater freedom in the |
| 8485 | use of new media types, to make date comparisons easier, and to |
| 8486 | acknowledge the practice of some early HTTP servers and clients. |
| 8487 | |
| 8488 | This appendix describes specific areas where HTTP differs from MIME. |
| 8489 | Proxies and gateways to strict MIME environments SHOULD be aware of |
| 8490 | these differences and provide the appropriate conversions where |
| 8491 | necessary. Proxies and gateways from MIME environments to HTTP also |
| 8492 | need to be aware of the differences because some conversions may be |
| 8493 | required. |
| 8494 | |
| 8495 | 19.4.1 Conversion to Canonical Form |
| 8496 | |
| 8497 | MIME requires that an Internet mail entity be converted to canonical |
| 8498 | form prior to being transferred. Section 3.7.1 of this document |
| 8499 | describes the forms allowed for subtypes of the "text" media type |
| 8500 | when transmitted over HTTP. MIME requires that content with a type of |
| 8501 | "text" represent line breaks as CRLF and forbids the use of CR or LF |
| 8502 | outside of line break sequences. HTTP allows CRLF, bare CR, and bare |
| 8503 | LF to indicate a line break within text content when a message is |
| 8504 | transmitted over HTTP. |
| 8505 | |
| 8506 | Where it is possible, a proxy or gateway from HTTP to a strict MIME |
| 8507 | environment SHOULD translate all line breaks within the text media |
| 8508 | types described in section 3.7.1 of this document to the MIME |
| 8509 | canonical form of CRLF. Note, however, that this may be complicated |
| 8510 | by the presence of a Content-Encoding and by the fact that HTTP |
| 8511 | |
| 8512 | |
| 8513 | |
| 8514 | Fielding, et. al. Standards Track [Page 152] |
| 8515 | \f |
| 8516 | RFC 2068 HTTP/1.1 January 1997 |
| 8517 | |
| 8518 | |
| 8519 | allows the use of some character sets which do not use octets 13 and |
| 8520 | 10 to represent CR and LF, as is the case for some multi-byte |
| 8521 | character sets. |
| 8522 | |
| 8523 | 19.4.2 Conversion of Date Formats |
| 8524 | |
| 8525 | HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to |
| 8526 | simplify the process of date comparison. Proxies and gateways from |
| 8527 | other protocols SHOULD ensure that any Date header field present in a |
| 8528 | message conforms to one of the HTTP/1.1 formats and rewrite the date |
| 8529 | if necessary. |
| 8530 | |
| 8531 | 19.4.3 Introduction of Content-Encoding |
| 8532 | |
| 8533 | MIME does not include any concept equivalent to HTTP/1.1's Content- |
| 8534 | Encoding header field. Since this acts as a modifier on the media |
| 8535 | type, proxies and gateways from HTTP to MIME-compliant protocols MUST |
| 8536 | either change the value of the Content-Type header field or decode |
| 8537 | the entity-body before forwarding the message. (Some experimental |
| 8538 | applications of Content-Type for Internet mail have used a media-type |
| 8539 | parameter of ";conversions=<content-coding>" to perform an equivalent |
| 8540 | function as Content-Encoding. However, this parameter is not part of |
| 8541 | MIME.) |
| 8542 | |
| 8543 | 19.4.4 No Content-Transfer-Encoding |
| 8544 | |
| 8545 | HTTP does not use the Content-Transfer-Encoding (CTE) field of MIME. |
| 8546 | Proxies and gateways from MIME-compliant protocols to HTTP MUST |
| 8547 | remove any non-identity CTE ("quoted-printable" or "base64") encoding |
| 8548 | prior to delivering the response message to an HTTP client. |
| 8549 | |
| 8550 | Proxies and gateways from HTTP to MIME-compliant protocols are |
| 8551 | responsible for ensuring that the message is in the correct format |
| 8552 | and encoding for safe transport on that protocol, where "safe |
| 8553 | transport" is defined by the limitations of the protocol being used. |
| 8554 | Such a proxy or gateway SHOULD label the data with an appropriate |
| 8555 | Content-Transfer-Encoding if doing so will improve the likelihood of |
| 8556 | safe transport over the destination protocol. |
| 8557 | |
| 8558 | 19.4.5 HTTP Header Fields in Multipart Body-Parts |
| 8559 | |
| 8560 | In MIME, most header fields in multipart body-parts are generally |
| 8561 | ignored unless the field name begins with "Content-". In HTTP/1.1, |
| 8562 | multipart body-parts may contain any HTTP header fields which are |
| 8563 | significant to the meaning of that part. |
| 8564 | |
| 8565 | |
| 8566 | |
| 8567 | |
| 8568 | |
| 8569 | |
| 8570 | Fielding, et. al. Standards Track [Page 153] |
| 8571 | \f |
| 8572 | RFC 2068 HTTP/1.1 January 1997 |
| 8573 | |
| 8574 | |
| 8575 | 19.4.6 Introduction of Transfer-Encoding |
| 8576 | |
| 8577 | HTTP/1.1 introduces the Transfer-Encoding header field (section |
| 8578 | 14.40). Proxies/gateways MUST remove any transfer coding prior to |
| 8579 | forwarding a message via a MIME-compliant protocol. |
| 8580 | |
| 8581 | A process for decoding the "chunked" transfer coding (section 3.6) |
| 8582 | can be represented in pseudo-code as: |
| 8583 | |
| 8584 | length := 0 |
| 8585 | read chunk-size, chunk-ext (if any) and CRLF |
| 8586 | while (chunk-size > 0) { |
| 8587 | read chunk-data and CRLF |
| 8588 | append chunk-data to entity-body |
| 8589 | length := length + chunk-size |
| 8590 | read chunk-size and CRLF |
| 8591 | } |
| 8592 | read entity-header |
| 8593 | while (entity-header not empty) { |
| 8594 | append entity-header to existing header fields |
| 8595 | read entity-header |
| 8596 | } |
| 8597 | Content-Length := length |
| 8598 | Remove "chunked" from Transfer-Encoding |
| 8599 | |
| 8600 | 19.4.7 MIME-Version |
| 8601 | |
| 8602 | HTTP is not a MIME-compliant protocol (see appendix 19.4). However, |
| 8603 | HTTP/1.1 messages may include a single MIME-Version general-header |
| 8604 | field to indicate what version of the MIME protocol was used to |
| 8605 | construct the message. Use of the MIME-Version header field indicates |
| 8606 | that the message is in full compliance with the MIME protocol. |
| 8607 | Proxies/gateways are responsible for ensuring full compliance (where |
| 8608 | possible) when exporting HTTP messages to strict MIME environments. |
| 8609 | |
| 8610 | MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT |
| 8611 | |
| 8612 | MIME version "1.0" is the default for use in HTTP/1.1. However, |
| 8613 | HTTP/1.1 message parsing and semantics are defined by this document |
| 8614 | and not the MIME specification. |
| 8615 | |
| 8616 | 19.5 Changes from HTTP/1.0 |
| 8617 | |
| 8618 | This section summarizes major differences between versions HTTP/1.0 |
| 8619 | and HTTP/1.1. |
| 8620 | |
| 8621 | |
| 8622 | |
| 8623 | |
| 8624 | |
| 8625 | |
| 8626 | Fielding, et. al. Standards Track [Page 154] |
| 8627 | \f |
| 8628 | RFC 2068 HTTP/1.1 January 1997 |
| 8629 | |
| 8630 | |
| 8631 | 19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP |
| 8632 | Addresses |
| 8633 | |
| 8634 | The requirements that clients and servers support the Host request- |
| 8635 | header, report an error if the Host request-header (section 14.23) is |
| 8636 | missing from an HTTP/1.1 request, and accept absolute URIs (section |
| 8637 | 5.1.2) are among the most important changes defined by this |
| 8638 | specification. |
| 8639 | |
| 8640 | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
| 8641 | addresses and servers; there was no other established mechanism for |
| 8642 | distinguishing the intended server of a request than the IP address |
| 8643 | to which that request was directed. The changes outlined above will |
| 8644 | allow the Internet, once older HTTP clients are no longer common, to |
| 8645 | support multiple Web sites from a single IP address, greatly |
| 8646 | simplifying large operational Web servers, where allocation of many |
| 8647 | IP addresses to a single host has created serious problems. The |
| 8648 | Internet will also be able to recover the IP addresses that have been |
| 8649 | allocated for the sole purpose of allowing special-purpose domain |
| 8650 | names to be used in root-level HTTP URLs. Given the rate of growth of |
| 8651 | the Web, and the number of servers already deployed, it is extremely |
| 8652 | important that all implementations of HTTP (including updates to |
| 8653 | existing HTTP/1.0 applications) correctly implement these |
| 8654 | requirements: |
| 8655 | |
| 8656 | o Both clients and servers MUST support the Host request-header. |
| 8657 | |
| 8658 | o Host request-headers are required in HTTP/1.1 requests. |
| 8659 | |
| 8660 | o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |
| 8661 | request does not include a Host request-header. |
| 8662 | |
| 8663 | o Servers MUST accept absolute URIs. |
| 8664 | |
| 8665 | |
| 8666 | |
| 8667 | |
| 8668 | |
| 8669 | |
| 8670 | |
| 8671 | |
| 8672 | |
| 8673 | |
| 8674 | |
| 8675 | |
| 8676 | |
| 8677 | |
| 8678 | |
| 8679 | |
| 8680 | |
| 8681 | |
| 8682 | Fielding, et. al. Standards Track [Page 155] |
| 8683 | \f |
| 8684 | RFC 2068 HTTP/1.1 January 1997 |
| 8685 | |
| 8686 | |
| 8687 | 19.6 Additional Features |
| 8688 | |
| 8689 | This appendix documents protocol elements used by some existing HTTP |
| 8690 | implementations, but not consistently and correctly across most |
| 8691 | HTTP/1.1 applications. Implementers should be aware of these |
| 8692 | features, but cannot rely upon their presence in, or interoperability |
| 8693 | with, other HTTP/1.1 applications. Some of these describe proposed |
| 8694 | experimental features, and some describe features that experimental |
| 8695 | deployment found lacking that are now addressed in the base HTTP/1.1 |
| 8696 | specification. |
| 8697 | |
| 8698 | 19.6.1 Additional Request Methods |
| 8699 | |
| 8700 | 19.6.1.1 PATCH |
| 8701 | |
| 8702 | The PATCH method is similar to PUT except that the entity contains a |
| 8703 | list of differences between the original version of the resource |
| 8704 | identified by the Request-URI and the desired content of the resource |
| 8705 | after the PATCH action has been applied. The list of differences is |
| 8706 | in a format defined by the media type of the entity (e.g., |
| 8707 | "application/diff") and MUST include sufficient information to allow |
| 8708 | the server to recreate the changes necessary to convert the original |
| 8709 | version of the resource to the desired version. |
| 8710 | |
| 8711 | If the request passes through a cache and the Request-URI identifies |
| 8712 | a currently cached entity, that entity MUST be removed from the |
| 8713 | cache. Responses to this method are not cachable. |
| 8714 | |
| 8715 | The actual method for determining how the patched resource is placed, |
| 8716 | and what happens to its predecessor, is defined entirely by the |
| 8717 | origin server. If the original version of the resource being patched |
| 8718 | included a Content-Version header field, the request entity MUST |
| 8719 | include a Derived-From header field corresponding to the value of the |
| 8720 | original Content-Version header field. Applications are encouraged to |
| 8721 | use these fields for constructing versioning relationships and |
| 8722 | resolving version conflicts. |
| 8723 | |
| 8724 | PATCH requests must obey the message transmission requirements set |
| 8725 | out in section 8.2. |
| 8726 | |
| 8727 | Caches that implement PATCH should invalidate cached responses as |
| 8728 | defined in section 13.10 for PUT. |
| 8729 | |
| 8730 | 19.6.1.2 LINK |
| 8731 | |
| 8732 | The LINK method establishes one or more Link relationships between |
| 8733 | the existing resource identified by the Request-URI and other |
| 8734 | existing resources. The difference between LINK and other methods |
| 8735 | |
| 8736 | |
| 8737 | |
| 8738 | Fielding, et. al. Standards Track [Page 156] |
| 8739 | \f |
| 8740 | RFC 2068 HTTP/1.1 January 1997 |
| 8741 | |
| 8742 | |
| 8743 | allowing links to be established between resources is that the LINK |
| 8744 | method does not allow any message-body to be sent in the request and |
| 8745 | does not directly result in the creation of new resources. |
| 8746 | |
| 8747 | If the request passes through a cache and the Request-URI identifies |
| 8748 | a currently cached entity, that entity MUST be removed from the |
| 8749 | cache. Responses to this method are not cachable. |
| 8750 | |
| 8751 | Caches that implement LINK should invalidate cached responses as |
| 8752 | defined in section 13.10 for PUT. |
| 8753 | |
| 8754 | 19.6.1.3 UNLINK |
| 8755 | |
| 8756 | The UNLINK method removes one or more Link relationships from the |
| 8757 | existing resource identified by the Request-URI. These relationships |
| 8758 | may have been established using the LINK method or by any other |
| 8759 | method supporting the Link header. The removal of a link to a |
| 8760 | resource does not imply that the resource ceases to exist or becomes |
| 8761 | inaccessible for future references. |
| 8762 | |
| 8763 | If the request passes through a cache and the Request-URI identifies |
| 8764 | a currently cached entity, that entity MUST be removed from the |
| 8765 | cache. Responses to this method are not cachable. |
| 8766 | |
| 8767 | Caches that implement UNLINK should invalidate cached responses as |
| 8768 | defined in section 13.10 for PUT. |
| 8769 | |
| 8770 | 19.6.2 Additional Header Field Definitions |
| 8771 | |
| 8772 | 19.6.2.1 Alternates |
| 8773 | |
| 8774 | The Alternates response-header field has been proposed as a means for |
| 8775 | the origin server to inform the client about other available |
| 8776 | representations of the requested resource, along with their |
| 8777 | distinguishing attributes, and thus providing a more reliable means |
| 8778 | for a user agent to perform subsequent selection of another |
| 8779 | representation which better fits the desires of its user (described |
| 8780 | as agent-driven negotiation in section 12). |
| 8781 | |
| 8782 | |
| 8783 | |
| 8784 | |
| 8785 | |
| 8786 | |
| 8787 | |
| 8788 | |
| 8789 | |
| 8790 | |
| 8791 | |
| 8792 | |
| 8793 | |
| 8794 | Fielding, et. al. Standards Track [Page 157] |
| 8795 | \f |
| 8796 | RFC 2068 HTTP/1.1 January 1997 |
| 8797 | |
| 8798 | |
| 8799 | The Alternates header field is orthogonal to the Vary header field in |
| 8800 | that both may coexist in a message without affecting the |
| 8801 | interpretation of the response or the available representations. It |
| 8802 | is expected that Alternates will provide a significant improvement |
| 8803 | over the server-driven negotiation provided by the Vary field for |
| 8804 | those resources that vary over common dimensions like type and |
| 8805 | language. |
| 8806 | |
| 8807 | The Alternates header field will be defined in a future |
| 8808 | specification. |
| 8809 | |
| 8810 | 19.6.2.2 Content-Version |
| 8811 | |
| 8812 | The Content-Version entity-header field defines the version tag |
| 8813 | associated with a rendition of an evolving entity. Together with the |
| 8814 | Derived-From field described in section 19.6.2.3, it allows a group |
| 8815 | of people to work simultaneously on the creation of a work as an |
| 8816 | iterative process. The field should be used to allow evolution of a |
| 8817 | particular work along a single path rather than derived works or |
| 8818 | renditions in different representations. |
| 8819 | |
| 8820 | Content-Version = "Content-Version" ":" quoted-string |
| 8821 | |
| 8822 | Examples of the Content-Version field include: |
| 8823 | |
| 8824 | Content-Version: "2.1.2" |
| 8825 | Content-Version: "Fred 19950116-12:26:48" |
| 8826 | Content-Version: "2.5a4-omega7" |
| 8827 | |
| 8828 | 19.6.2.3 Derived-From |
| 8829 | |
| 8830 | The Derived-From entity-header field can be used to indicate the |
| 8831 | version tag of the resource from which the enclosed entity was |
| 8832 | derived before modifications were made by the sender. This field is |
| 8833 | used to help manage the process of merging successive changes to a |
| 8834 | resource, particularly when such changes are being made in parallel |
| 8835 | and from multiple sources. |
| 8836 | |
| 8837 | Derived-From = "Derived-From" ":" quoted-string |
| 8838 | |
| 8839 | An example use of the field is: |
| 8840 | |
| 8841 | Derived-From: "2.1.1" |
| 8842 | |
| 8843 | The Derived-From field is required for PUT and PATCH requests if the |
| 8844 | entity being sent was previously retrieved from the same URI and a |
| 8845 | Content-Version header was included with the entity when it was last |
| 8846 | retrieved. |
| 8847 | |
| 8848 | |
| 8849 | |
| 8850 | Fielding, et. al. Standards Track [Page 158] |
| 8851 | \f |
| 8852 | RFC 2068 HTTP/1.1 January 1997 |
| 8853 | |
| 8854 | |
| 8855 | 19.6.2.4 Link |
| 8856 | |
| 8857 | The Link entity-header field provides a means for describing a |
| 8858 | relationship between two resources, generally between the requested |
| 8859 | resource and some other resource. An entity MAY include multiple Link |
| 8860 | values. Links at the metainformation level typically indicate |
| 8861 | relationships like hierarchical structure and navigation paths. The |
| 8862 | Link field is semantically equivalent to the <LINK> element in |
| 8863 | HTML.[5] |
| 8864 | |
| 8865 | Link = "Link" ":" #("<" URI ">" *( ";" link-param ) |
| 8866 | |
| 8867 | link-param = ( ( "rel" "=" relationship ) |
| 8868 | | ( "rev" "=" relationship ) |
| 8869 | | ( "title" "=" quoted-string ) |
| 8870 | | ( "anchor" "=" <"> URI <"> ) |
| 8871 | | ( link-extension ) ) |
| 8872 | |
| 8873 | link-extension = token [ "=" ( token | quoted-string ) ] |
| 8874 | |
| 8875 | relationship = sgml-name |
| 8876 | | ( <"> sgml-name *( SP sgml-name) <"> ) |
| 8877 | |
| 8878 | sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) |
| 8879 | |
| 8880 | Relationship values are case-insensitive and MAY be extended within |
| 8881 | the constraints of the sgml-name syntax. The title parameter MAY be |
| 8882 | used to label the destination of a link such that it can be used as |
| 8883 | identification within a human-readable menu. The anchor parameter MAY |
| 8884 | be used to indicate a source anchor other than the entire current |
| 8885 | resource, such as a fragment of this resource or a third resource. |
| 8886 | |
| 8887 | Examples of usage include: |
| 8888 | |
| 8889 | Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous" |
| 8890 | |
| 8891 | Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee" |
| 8892 | |
| 8893 | The first example indicates that chapter2 is previous to this |
| 8894 | resource in a logical navigation path. The second indicates that the |
| 8895 | person responsible for making the resource available is identified by |
| 8896 | the given e-mail address. |
| 8897 | |
| 8898 | 19.6.2.5 URI |
| 8899 | |
| 8900 | The URI header field has, in past versions of this specification, |
| 8901 | been used as a combination of the existing Location, Content- |
| 8902 | Location, and Vary header fields as well as the future Alternates |
| 8903 | |
| 8904 | |
| 8905 | |
| 8906 | Fielding, et. al. Standards Track [Page 159] |
| 8907 | \f |
| 8908 | RFC 2068 HTTP/1.1 January 1997 |
| 8909 | |
| 8910 | |
| 8911 | field (above). Its primary purpose has been to include a list of |
| 8912 | additional URIs for the resource, including names and mirror |
| 8913 | locations. However, it has become clear that the combination of many |
| 8914 | different functions within this single field has been a barrier to |
| 8915 | consistently and correctly implementing any of those functions. |
| 8916 | Furthermore, we believe that the identification of names and mirror |
| 8917 | locations would be better performed via the Link header field. The |
| 8918 | URI header field is therefore deprecated in favor of those other |
| 8919 | fields. |
| 8920 | |
| 8921 | URI-header = "URI" ":" 1#( "<" URI ">" ) |
| 8922 | |
| 8923 | 19.7 Compatibility with Previous Versions |
| 8924 | |
| 8925 | It is beyond the scope of a protocol specification to mandate |
| 8926 | compliance with previous versions. HTTP/1.1 was deliberately |
| 8927 | designed, however, to make supporting previous versions easy. It is |
| 8928 | worth noting that at the time of composing this specification, we |
| 8929 | would expect commercial HTTP/1.1 servers to: |
| 8930 | |
| 8931 | o recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1 |
| 8932 | requests; |
| 8933 | |
| 8934 | o understand any valid request in the format of HTTP/0.9, 1.0, or |
| 8935 | 1.1; |
| 8936 | |
| 8937 | o respond appropriately with a message in the same major version used |
| 8938 | by the client. |
| 8939 | |
| 8940 | And we would expect HTTP/1.1 clients to: |
| 8941 | |
| 8942 | o recognize the format of the Status-Line for HTTP/1.0 and 1.1 |
| 8943 | responses; |
| 8944 | |
| 8945 | o understand any valid response in the format of HTTP/0.9, 1.0, or |
| 8946 | 1.1. |
| 8947 | |
| 8948 | For most implementations of HTTP/1.0, each connection is established |
| 8949 | by the client prior to the request and closed by the server after |
| 8950 | sending the response. A few implementations implement the Keep-Alive |
| 8951 | version of persistent connections described in section 19.7.1.1. |
| 8952 | |
| 8953 | |
| 8954 | |
| 8955 | |
| 8956 | |
| 8957 | |
| 8958 | |
| 8959 | |
| 8960 | |
| 8961 | |
| 8962 | Fielding, et. al. Standards Track [Page 160] |
| 8963 | \f |
| 8964 | RFC 2068 HTTP/1.1 January 1997 |
| 8965 | |
| 8966 | |
| 8967 | 19.7.1 Compatibility with HTTP/1.0 Persistent Connections |
| 8968 | |
| 8969 | Some clients and servers may wish to be compatible with some previous |
| 8970 | implementations of persistent connections in HTTP/1.0 clients and |
| 8971 | servers. Persistent connections in HTTP/1.0 must be explicitly |
| 8972 | negotiated as they are not the default behavior. HTTP/1.0 |
| 8973 | experimental implementations of persistent connections are faulty, |
| 8974 | and the new facilities in HTTP/1.1 are designed to rectify these |
| 8975 | problems. The problem was that some existing 1.0 clients may be |
| 8976 | sending Keep-Alive to a proxy server that doesn't understand |
| 8977 | Connection, which would then erroneously forward it to the next |
| 8978 | inbound server, which would establish the Keep-Alive connection and |
| 8979 | result in a hung HTTP/1.0 proxy waiting for the close on the |
| 8980 | response. The result is that HTTP/1.0 clients must be prevented from |
| 8981 | using Keep-Alive when talking to proxies. |
| 8982 | |
| 8983 | However, talking to proxies is the most important use of persistent |
| 8984 | connections, so that prohibition is clearly unacceptable. Therefore, |
| 8985 | we need some other mechanism for indicating a persistent connection |
| 8986 | is desired, which is safe to use even when talking to an old proxy |
| 8987 | that ignores Connection. Persistent connections are the default for |
| 8988 | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
| 8989 | declaring non-persistence. |
| 8990 | |
| 8991 | The following describes the original HTTP/1.0 form of persistent |
| 8992 | connections. |
| 8993 | |
| 8994 | When it connects to an origin server, an HTTP client MAY send the |
| 8995 | Keep-Alive connection-token in addition to the Persist connection- |
| 8996 | token: |
| 8997 | |
| 8998 | Connection: Keep-Alive |
| 8999 | |
| 9000 | An HTTP/1.0 server would then respond with the Keep-Alive connection |
| 9001 | token and the client may proceed with an HTTP/1.0 (or Keep-Alive) |
| 9002 | persistent connection. |
| 9003 | |
| 9004 | An HTTP/1.1 server may also establish persistent connections with |
| 9005 | HTTP/1.0 clients upon receipt of a Keep-Alive connection token. |
| 9006 | However, a persistent connection with an HTTP/1.0 client cannot make |
| 9007 | use of the chunked transfer-coding, and therefore MUST use a |
| 9008 | Content-Length for marking the ending boundary of each message. |
| 9009 | |
| 9010 | A client MUST NOT send the Keep-Alive connection token to a proxy |
| 9011 | server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1 |
| 9012 | for parsing the Connection header field. |
| 9013 | |
| 9014 | |
| 9015 | |
| 9016 | |
| 9017 | |
| 9018 | Fielding, et. al. Standards Track [Page 161] |
| 9019 | \f |
| 9020 | RFC 2068 HTTP/1.1 January 1997 |
| 9021 | |
| 9022 | |
| 9023 | 19.7.1.1 The Keep-Alive Header |
| 9024 | |
| 9025 | When the Keep-Alive connection-token has been transmitted with a |
| 9026 | request or a response, a Keep-Alive header field MAY also be |
| 9027 | included. The Keep-Alive header field takes the following form: |
| 9028 | |
| 9029 | Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param |
| 9030 | |
| 9031 | keepalive-param = param-name "=" value |
| 9032 | |
| 9033 | The Keep-Alive header itself is optional, and is used only if a |
| 9034 | parameter is being sent. HTTP/1.1 does not define any parameters. |
| 9035 | |
| 9036 | If the Keep-Alive header is sent, the corresponding connection token |
| 9037 | MUST be transmitted. The Keep-Alive header MUST be ignored if |
| 9038 | received without the connection token. |
| 9039 | |
| 9040 | |
| 9041 | |
| 9042 | |
| 9043 | |
| 9044 | |
| 9045 | |
| 9046 | |
| 9047 | |
| 9048 | |
| 9049 | |
| 9050 | |
| 9051 | |
| 9052 | |
| 9053 | |
| 9054 | |
| 9055 | |
| 9056 | |
| 9057 | |
| 9058 | |
| 9059 | |
| 9060 | |
| 9061 | |
| 9062 | |
| 9063 | |
| 9064 | |
| 9065 | |
| 9066 | |
| 9067 | |
| 9068 | |
| 9069 | |
| 9070 | |
| 9071 | |
| 9072 | |
| 9073 | |
| 9074 | Fielding, et. al. Standards Track [Page 162] |
| 9075 | \f |