1
2
3
4
5
6
7 Network Working Group R. Fielding
8 Request for Comments: 2616 UC Irvine
9 Obsoletes: 2068 J. Gettys
10 Category: Standards Track Compaq/W3C
11 J. Mogul
12 Compaq
13 H. Frystyk
14 W3C/MIT
15 L. Masinter
16 Xerox
17 P. Leach
18 Microsoft
19 T. Berners-Lee
20 W3C/MIT
21 June 1999
22
23
24 Hypertext Transfer Protocol -- HTTP/1.1
25
26 Status of this Memo
27
28 This document specifies an Internet standards track protocol for the
29 Internet community, and requests discussion and suggestions for
30 improvements. Please refer to the current edition of the "Internet
31 Official Protocol Standards" (STD 1) for the standardization state
32 and status of this protocol. Distribution of this memo is unlimited.
33
34 Copyright Notice
35
36 Copyright (C) The Internet Society (1999). All Rights Reserved.
37
38 Abstract
39
40 The Hypertext Transfer Protocol (HTTP) is an application-level
41 protocol for distributed, collaborative, hypermedia information
42 systems. It is a generic, stateless, protocol which can be used for
43 many tasks beyond its use for hypertext, such as name servers and
44 distributed object management systems, through extension of its
45 request methods, error codes and headers [47]. A feature of HTTP is
46 the typing and negotiation of data representation, allowing systems
47 to be built independently of the data being transferred.
48
49 HTTP has been in use by the World-Wide Web global information
50 initiative since 1990. This specification defines the protocol
51 referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
52
53
54
55
56
57
58 Fielding, et al. Standards Track [Page 1]
59
60 RFC 2616 HTTP/1.1 June 1999
61
62
63 Table of Contents
64
65 1 Introduction ...................................................7
66 1.1 Purpose......................................................7
67 1.2 Requirements .................................................8
68 1.3 Terminology ..................................................8
69 1.4 Overall Operation ...........................................12
70 2 Notational Conventions and Generic Grammar ....................14
71 2.1 Augmented BNF ...............................................14
72 2.2 Basic Rules .................................................15
73 3 Protocol Parameters ...........................................17
74 3.1 HTTP Version ................................................17
75 3.2 Uniform Resource Identifiers ................................18
76 3.2.1 General Syntax ...........................................19
77 3.2.2 http URL .................................................19
78 3.2.3 URI Comparison ...........................................20
79 3.3 Date/Time Formats ...........................................20
80 3.3.1 Full Date ................................................20
81 3.3.2 Delta Seconds ............................................21
82 3.4 Character Sets ..............................................21
83 3.4.1 Missing Charset ..........................................22
84 3.5 Content Codings .............................................23
85 3.6 Transfer Codings ............................................24
86 3.6.1 Chunked Transfer Coding ..................................25
87 3.7 Media Types .................................................26
88 3.7.1 Canonicalization and Text Defaults .......................27
89 3.7.2 Multipart Types ..........................................27
90 3.8 Product Tokens ..............................................28
91 3.9 Quality Values ..............................................29
92 3.10 Language Tags ...............................................29
93 3.11 Entity Tags .................................................30
94 3.12 Range Units .................................................30
95 4 HTTP Message ..................................................31
96 4.1 Message Types ...............................................31
97 4.2 Message Headers .............................................31
98 4.3 Message Body ................................................32
99 4.4 Message Length ..............................................33
100 4.5 General Header Fields .......................................34
101 5 Request .......................................................35
102 5.1 Request-Line ................................................35
103 5.1.1 Method ...................................................36
104 5.1.2 Request-URI ..............................................36
105 5.2 The Resource Identified by a Request ........................38
106 5.3 Request Header Fields .......................................38
107 6 Response ......................................................39
108 6.1 Status-Line .................................................39
109 6.1.1 Status Code and Reason Phrase ............................39
110 6.2 Response Header Fields ......................................41
111
112
113
114 Fielding, et al. Standards Track [Page 2]
115
116 RFC 2616 HTTP/1.1 June 1999
117
118
119 7 Entity ........................................................42
120 7.1 Entity Header Fields ........................................42
121 7.2 Entity Body .................................................43
122 7.2.1 Type .....................................................43
123 7.2.2 Entity Length ............................................43
124 8 Connections ...................................................44
125 8.1 Persistent Connections ......................................44
126 8.1.1 Purpose ..................................................44
127 8.1.2 Overall Operation ........................................45
128 8.1.3 Proxy Servers ............................................46
129 8.1.4 Practical Considerations .................................46
130 8.2 Message Transmission Requirements ...........................47
131 8.2.1 Persistent Connections and Flow Control ..................47
132 8.2.2 Monitoring Connections for Error Status Messages .........48
133 8.2.3 Use of the 100 (Continue) Status .........................48
134 8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
135 9 Method Definitions ............................................51
136 9.1 Safe and Idempotent Methods .................................51
137 9.1.1 Safe Methods .............................................51
138 9.1.2 Idempotent Methods .......................................51
139 9.2 OPTIONS .....................................................52
140 9.3 GET .........................................................53
141 9.4 HEAD ........................................................54
142 9.5 POST ........................................................54
143 9.6 PUT .........................................................55
144 9.7 DELETE ......................................................56
145 9.8 TRACE .......................................................56
146 9.9 CONNECT .....................................................57
147 10 Status Code Definitions ......................................57
148 10.1 Informational 1xx ...........................................57
149 10.1.1 100 Continue .............................................58
150 10.1.2 101 Switching Protocols ..................................58
151 10.2 Successful 2xx ..............................................58
152 10.2.1 200 OK ...................................................58
153 10.2.2 201 Created ..............................................59
154 10.2.3 202 Accepted .............................................59
155 10.2.4 203 Non-Authoritative Information ........................59
156 10.2.5 204 No Content ...........................................60
157 10.2.6 205 Reset Content ........................................60
158 10.2.7 206 Partial Content ......................................60
159 10.3 Redirection 3xx .............................................61
160 10.3.1 300 Multiple Choices .....................................61
161 10.3.2 301 Moved Permanently ....................................62
162 10.3.3 302 Found ................................................62
163 10.3.4 303 See Other ............................................63
164 10.3.5 304 Not Modified .........................................63
165 10.3.6 305 Use Proxy ............................................64
166 10.3.7 306 (Unused) .............................................64
167
168
169
170 Fielding, et al. Standards Track [Page 3]
171
172 RFC 2616 HTTP/1.1 June 1999
173
174
175 10.3.8 307 Temporary Redirect ...................................65
176 10.4 Client Error 4xx ............................................65
177 10.4.1 400 Bad Request .........................................65
178 10.4.2 401 Unauthorized ........................................66
179 10.4.3 402 Payment Required ....................................66
180 10.4.4 403 Forbidden ...........................................66
181 10.4.5 404 Not Found ...........................................66
182 10.4.6 405 Method Not Allowed ..................................66
183 10.4.7 406 Not Acceptable ......................................67
184 10.4.8 407 Proxy Authentication Required .......................67
185 10.4.9 408 Request Timeout .....................................67
186 10.4.10 409 Conflict ............................................67
187 10.4.11 410 Gone ................................................68
188 10.4.12 411 Length Required .....................................68
189 10.4.13 412 Precondition Failed .................................68
190 10.4.14 413 Request Entity Too Large ............................69
191 10.4.15 414 Request-URI Too Long ................................69
192 10.4.16 415 Unsupported Media Type ..............................69
193 10.4.17 416 Requested Range Not Satisfiable .....................69
194 10.4.18 417 Expectation Failed ..................................70
195 10.5 Server Error 5xx ............................................70
196 10.5.1 500 Internal Server Error ................................70
197 10.5.2 501 Not Implemented ......................................70
198 10.5.3 502 Bad Gateway ..........................................70
199 10.5.4 503 Service Unavailable ..................................70
200 10.5.5 504 Gateway Timeout ......................................71
201 10.5.6 505 HTTP Version Not Supported ...........................71
202 11 Access Authentication ........................................71
203 12 Content Negotiation ..........................................71
204 12.1 Server-driven Negotiation ...................................72
205 12.2 Agent-driven Negotiation ....................................73
206 12.3 Transparent Negotiation .....................................74
207 13 Caching in HTTP ..............................................74
208 13.1.1 Cache Correctness ........................................75
209 13.1.2 Warnings .................................................76
210 13.1.3 Cache-control Mechanisms .................................77
211 13.1.4 Explicit User Agent Warnings .............................78
212 13.1.5 Exceptions to the Rules and Warnings .....................78
213 13.1.6 Client-controlled Behavior ...............................79
214 13.2 Expiration Model ............................................79
215 13.2.1 Server-Specified Expiration ..............................79
216 13.2.2 Heuristic Expiration .....................................80
217 13.2.3 Age Calculations .........................................80
218 13.2.4 Expiration Calculations ..................................83
219 13.2.5 Disambiguating Expiration Values .........................84
220 13.2.6 Disambiguating Multiple Responses ........................84
221 13.3 Validation Model ............................................85
222 13.3.1 Last-Modified Dates ......................................86
223
224
225
226 Fielding, et al. Standards Track [Page 4]
227
228 RFC 2616 HTTP/1.1 June 1999
229
230
231 13.3.2 Entity Tag Cache Validators ..............................86
232 13.3.3 Weak and Strong Validators ...............................86
233 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
234 13.3.5 Non-validating Conditionals ..............................90
235 13.4 Response Cacheability .......................................91
236 13.5 Constructing Responses From Caches ..........................92
237 13.5.1 End-to-end and Hop-by-hop Headers ........................92
238 13.5.2 Non-modifiable Headers ...................................92
239 13.5.3 Combining Headers ........................................94
240 13.5.4 Combining Byte Ranges ....................................95
241 13.6 Caching Negotiated Responses ................................95
242 13.7 Shared and Non-Shared Caches ................................96
243 13.8 Errors or Incomplete Response Cache Behavior ................97
244 13.9 Side Effects of GET and HEAD ................................97
245 13.10 Invalidation After Updates or Deletions ...................97
246 13.11 Write-Through Mandatory ...................................98
247 13.12 Cache Replacement .........................................99
248 13.13 History Lists .............................................99
249 14 Header Field Definitions ....................................100
250 14.1 Accept .....................................................100
251 14.2 Accept-Charset .............................................102
252 14.3 Accept-Encoding ............................................102
253 14.4 Accept-Language ............................................104
254 14.5 Accept-Ranges ..............................................105
255 14.6 Age ........................................................106
256 14.7 Allow ......................................................106
257 14.8 Authorization ..............................................107
258 14.9 Cache-Control ..............................................108
259 14.9.1 What is Cacheable .......................................109
260 14.9.2 What May be Stored by Caches ............................110
261 14.9.3 Modifications of the Basic Expiration Mechanism .........111
262 14.9.4 Cache Revalidation and Reload Controls ..................113
263 14.9.5 No-Transform Directive ..................................115
264 14.9.6 Cache Control Extensions ................................116
265 14.10 Connection ...............................................117
266 14.11 Content-Encoding .........................................118
267 14.12 Content-Language .........................................118
268 14.13 Content-Length ...........................................119
269 14.14 Content-Location .........................................120
270 14.15 Content-MD5 ..............................................121
271 14.16 Content-Range ............................................122
272 14.17 Content-Type .............................................124
273 14.18 Date .....................................................124
274 14.18.1 Clockless Origin Server Operation ......................125
275 14.19 ETag .....................................................126
276 14.20 Expect ...................................................126
277 14.21 Expires ..................................................127
278 14.22 From .....................................................128
279
280
281
282 Fielding, et al. Standards Track [Page 5]
283
284 RFC 2616 HTTP/1.1 June 1999
285
286
287 14.23 Host .....................................................128
288 14.24 If-Match .................................................129
289 14.25 If-Modified-Since ........................................130
290 14.26 If-None-Match ............................................132
291 14.27 If-Range .................................................133
292 14.28 If-Unmodified-Since ......................................134
293 14.29 Last-Modified ............................................134
294 14.30 Location .................................................135
295 14.31 Max-Forwards .............................................136
296 14.32 Pragma ...................................................136
297 14.33 Proxy-Authenticate .......................................137
298 14.34 Proxy-Authorization ......................................137
299 14.35 Range ....................................................138
300 14.35.1 Byte Ranges ...........................................138
301 14.35.2 Range Retrieval Requests ..............................139
302 14.36 Referer ..................................................140
303 14.37 Retry-After ..............................................141
304 14.38 Server ...................................................141
305 14.39 TE .......................................................142
306 14.40 Trailer ..................................................143
307 14.41 Transfer-Encoding..........................................143
308 14.42 Upgrade ..................................................144
309 14.43 User-Agent ...............................................145
310 14.44 Vary .....................................................145
311 14.45 Via ......................................................146
312 14.46 Warning ..................................................148
313 14.47 WWW-Authenticate .........................................150
314 15 Security Considerations .......................................150
315 15.1 Personal Information....................................151
316 15.1.1 Abuse of Server Log Information .........................151
317 15.1.2 Transfer of Sensitive Information .......................151
318 15.1.3 Encoding Sensitive Information in URI's .................152
319 15.1.4 Privacy Issues Connected to Accept Headers ..............152
320 15.2 Attacks Based On File and Path Names .......................153
321 15.3 DNS Spoofing ...............................................154
322 15.4 Location Headers and Spoofing ..............................154
323 15.5 Content-Disposition Issues .................................154
324 15.6 Authentication Credentials and Idle Clients ................155
325 15.7 Proxies and Caching ........................................155
326 15.7.1 Denial of Service Attacks on Proxies....................156
327 16 Acknowledgments .............................................156
328 17 References ..................................................158
329 18 Authors' Addresses ..........................................162
330 19 Appendices ..................................................164
331 19.1 Internet Media Type message/http and application/http ......164
332 19.2 Internet Media Type multipart/byteranges ...................165
333 19.3 Tolerant Applications ......................................166
334 19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
335
336
337
338 Fielding, et al. Standards Track [Page 6]
339
340 RFC 2616 HTTP/1.1 June 1999
341
342
343 19.4.1 MIME-Version ............................................167
344 19.4.2 Conversion to Canonical Form ............................167
345 19.4.3 Conversion of Date Formats ..............................168
346 19.4.4 Introduction of Content-Encoding ........................168
347 19.4.5 No Content-Transfer-Encoding ............................168
348 19.4.6 Introduction of Transfer-Encoding .......................169
349 19.4.7 MHTML and Line Length Limitations .......................169
350 19.5 Additional Features ........................................169
351 19.5.1 Content-Disposition .....................................170
352 19.6 Compatibility with Previous Versions .......................170
353 19.6.1 Changes from HTTP/1.0 ...................................171
354 19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
355 19.6.3 Changes from RFC 2068 ...................................172
356 20 Index .......................................................175
357 21 Full Copyright Statement ....................................176
358
359 1 Introduction
360
361 1.1 Purpose
362
363 The Hypertext Transfer Protocol (HTTP) is an application-level
364 protocol for distributed, collaborative, hypermedia information
365 systems. HTTP has been in use by the World-Wide Web global
366 information initiative since 1990. The first version of HTTP,
367 referred to as HTTP/0.9, was a simple protocol for raw data transfer
368 across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
369 the protocol by allowing messages to be in the format of MIME-like
370 messages, containing metainformation about the data transferred and
371 modifiers on the request/response semantics. However, HTTP/1.0 does
372 not sufficiently take into consideration the effects of hierarchical
373 proxies, caching, the need for persistent connections, or virtual
374 hosts. In addition, the proliferation of incompletely-implemented
375 applications calling themselves "HTTP/1.0" has necessitated a
376 protocol version change in order for two communicating applications
377 to determine each other's true capabilities.
378
379 This specification defines the protocol referred to as "HTTP/1.1".
380 This protocol includes more stringent requirements than HTTP/1.0 in
381 order to ensure reliable implementation of its features.
382
383 Practical information systems require more functionality than simple
384 retrieval, including search, front-end update, and annotation. HTTP
385 allows an open-ended set of methods and headers that indicate the
386 purpose of a request [47]. It builds on the discipline of reference
387 provided by the Uniform Resource Identifier (URI) [3], as a location
388 (URL) [4] or name (URN) [20], for indicating the resource to which a
389
390
391
392
393
394 Fielding, et al. Standards Track [Page 7]
395
396 RFC 2616 HTTP/1.1 June 1999
397
398
399 method is to be applied. Messages are passed in a format similar to
400 that used by Internet mail [9] as defined by the Multipurpose
401 Internet Mail Extensions (MIME) [7].
402
403 HTTP is also used as a generic protocol for communication between
404 user agents and proxies/gateways to other Internet systems, including
405 those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
406 and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
407 access to resources available from diverse applications.
408
409 1.2 Requirements
410
411 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
412 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
413 document are to be interpreted as described in RFC 2119 [34].
414
415 An implementation is not compliant if it fails to satisfy one or more
416 of the MUST or REQUIRED level requirements for the protocols it
417 implements. An implementation that satisfies all the MUST or REQUIRED
418 level and all the SHOULD level requirements for its protocols is said
419 to be "unconditionally compliant"; one that satisfies all the MUST
420 level requirements but not all the SHOULD level requirements for its
421 protocols is said to be "conditionally compliant."
422
423 1.3 Terminology
424
425 This specification uses a number of terms to refer to the roles
426 played by participants in, and objects of, the HTTP communication.
427
428 connection
429 A transport layer virtual circuit established between two programs
430 for the purpose of communication.
431
432 message
433 The basic unit of HTTP communication, consisting of a structured
434 sequence of octets matching the syntax defined in section 4 and
435 transmitted via the connection.
436
437 request
438 An HTTP request message, as defined in section 5.
439
440 response
441 An HTTP response message, as defined in section 6.
442
443
444
445
446
447
448
449
450 Fielding, et al. Standards Track [Page 8]
451
452 RFC 2616 HTTP/1.1 June 1999
453
454
455 resource
456 A network data object or service that can be identified by a URI,
457 as defined in section 3.2. Resources may be available in multiple
458 representations (e.g. multiple languages, data formats, size, and
459 resolutions) or vary in other ways.
460
461 entity
462 The information transferred as the payload of a request or
463 response. An entity consists of metainformation in the form of
464 entity-header fields and content in the form of an entity-body, as
465 described in section 7.
466
467 representation
468 An entity included with a response that is subject to content
469 negotiation, as described in section 12. There may exist multiple
470 representations associated with a particular response status.
471
472 content negotiation
473 The mechanism for selecting the appropriate representation when
474 servicing a request, as described in section 12. The
475 representation of entities in any response can be negotiated
476 (including error responses).
477
478 variant
479 A resource may have one, or more than one, representation(s)
480 associated with it at any given instant. Each of these
481 representations is termed a `varriant'. Use of the term `variant'
482 does not necessarily imply that the resource is subject to content
483 negotiation.
484
485 client
486 A program that establishes connections for the purpose of sending
487 requests.
488
489 user agent
490 The client which initiates a request. These are often browsers,
491 editors, spiders (web-traversing robots), or other end user tools.
492
493 server
494 An application program that accepts connections in order to
495 service requests by sending back responses. Any given program may
496 be capable of being both a client and a server; our use of these
497 terms refers only to the role being performed by the program for a
498 particular connection, rather than to the program's capabilities
499 in general. Likewise, any server may act as an origin server,
500 proxy, gateway, or tunnel, switching behavior based on the nature
501 of each request.
502
503
504
505
506 Fielding, et al. Standards Track [Page 9]
507
508 RFC 2616 HTTP/1.1 June 1999
509
510
511 origin server
512 The server on which a given resource resides or is to be created.
513
514 proxy
515 An intermediary program which acts as both a server and a client
516 for the purpose of making requests on behalf of other clients.
517 Requests are serviced internally or by passing them on, with
518 possible translation, to other servers. A proxy MUST implement
519 both the client and server requirements of this specification. A
520 "transparent proxy" is a proxy that does not modify the request or
521 response beyond what is required for proxy authentication and
522 identification. A "non-transparent proxy" is a proxy that modifies
523 the request or response in order to provide some added service to
524 the user agent, such as group annotation services, media type
525 transformation, protocol reduction, or anonymity filtering. Except
526 where either transparent or non-transparent behavior is explicitly
527 stated, the HTTP proxy requirements apply to both types of
528 proxies.
529
530 gateway
531 A server which acts as an intermediary for some other server.
532 Unlike a proxy, a gateway receives requests as if it were the
533 origin server for the requested resource; the requesting client
534 may not be aware that it is communicating with a gateway.
535
536 tunnel
537 An intermediary program which is acting as a blind relay between
538 two connections. Once active, a tunnel is not considered a party
539 to the HTTP communication, though the tunnel may have been
540 initiated by an HTTP request. The tunnel ceases to exist when both
541 ends of the relayed connections are closed.
542
543 cache
544 A program's local store of response messages and the subsystem
545 that controls its message storage, retrieval, and deletion. A
546 cache stores cacheable responses in order to reduce the response
547 time and network bandwidth consumption on future, equivalent
548 requests. Any client or server may include a cache, though a cache
549 cannot be used by a server that is acting as a tunnel.
550
551 cacheable
552 A response is cacheable if a cache is allowed to store a copy of
553 the response message for use in answering subsequent requests. The
554 rules for determining the cacheability of HTTP responses are
555 defined in section 13. Even if a resource is cacheable, there may
556 be additional constraints on whether a cache can use the cached
557 copy for a particular request.
558
559
560
561
562 Fielding, et al. Standards Track [Page 10]
563
564 RFC 2616 HTTP/1.1 June 1999
565
566
567 first-hand
568 A response is first-hand if it comes directly and without
569 unnecessary delay from the origin server, perhaps via one or more
570 proxies. A response is also first-hand if its validity has just
571 been checked directly with the origin server.
572
573 explicit expiration time
574 The time at which the origin server intends that an entity should
575 no longer be returned by a cache without further validation.
576
577 heuristic expiration time
578 An expiration time assigned by a cache when no explicit expiration
579 time is available.
580
581 age
582 The age of a response is the time since it was sent by, or
583 successfully validated with, the origin server.
584
585 freshness lifetime
586 The length of time between the generation of a response and its
587 expiration time.
588
589 fresh
590 A response is fresh if its age has not yet exceeded its freshness
591 lifetime.
592
593 stale
594 A response is stale if its age has passed its freshness lifetime.
595
596 semantically transparent
597 A cache behaves in a "semantically transparent" manner, with
598 respect to a particular response, when its use affects neither the
599 requesting client nor the origin server, except to improve
600 performance. When a cache is semantically transparent, the client
601 receives exactly the same response (except for hop-by-hop headers)
602 that it would have received had its request been handled directly
603 by the origin server.
604
605 validator
606 A protocol element (e.g., an entity tag or a Last-Modified time)
607 that is used to find out whether a cache entry is an equivalent
608 copy of an entity.
609
610 upstream/downstream
611 Upstream and downstream describe the flow of a message: all
612 messages flow from upstream to downstream.
613
614
615
616
617
618 Fielding, et al. Standards Track [Page 11]
619
620 RFC 2616 HTTP/1.1 June 1999
621
622
623 inbound/outbound
624 Inbound and outbound refer to the request and response paths for
625 messages: "inbound" means "traveling toward the origin server",
626 and "outbound" means "traveling toward the user agent"
627
628 1.4 Overall Operation
629
630 The HTTP protocol is a request/response protocol. A client sends a
631 request to the server in the form of a request method, URI, and
632 protocol version, followed by a MIME-like message containing request
633 modifiers, client information, and possible body content over a
634 connection with a server. The server responds with a status line,
635 including the message's protocol version and a success or error code,
636 followed by a MIME-like message containing server information, entity
637 metainformation, and possible entity-body content. The relationship
638 between HTTP and MIME is described in appendix 19.4.
639
640 Most HTTP communication is initiated by a user agent and consists of
641 a request to be applied to a resource on some origin server. In the
642 simplest case, this may be accomplished via a single connection (v)
643 between the user agent (UA) and the origin server (O).
644
645 request chain ------------------------>
646 UA -------------------v------------------- O
647 <----------------------- response chain
648
649 A more complicated situation occurs when one or more intermediaries
650 are present in the request/response chain. There are three common
651 forms of intermediary: proxy, gateway, and tunnel. A proxy is a
652 forwarding agent, receiving requests for a URI in its absolute form,
653 rewriting all or part of the message, and forwarding the reformatted
654 request toward the server identified by the URI. A gateway is a
655 receiving agent, acting as a layer above some other server(s) and, if
656 necessary, translating the requests to the underlying server's
657 protocol. A tunnel acts as a relay point between two connections
658 without changing the messages; tunnels are used when the
659 communication needs to pass through an intermediary (such as a
660 firewall) even when the intermediary cannot understand the contents
661 of the messages.
662
663 request chain -------------------------------------->
664 UA -----v----- A -----v----- B -----v----- C -----v----- O
665 <------------------------------------- response chain
666
667 The figure above shows three intermediaries (A, B, and C) between the
668 user agent and origin server. A request or response message that
669 travels the whole chain will pass through four separate connections.
670 This distinction is important because some HTTP communication options
671
672
673
674 Fielding, et al. Standards Track [Page 12]
675
676 RFC 2616 HTTP/1.1 June 1999
677
678
679 may apply only to the connection with the nearest, non-tunnel
680 neighbor, only to the end-points of the chain, or to all connections
681 along the chain. Although the diagram is linear, each participant may
682 be engaged in multiple, simultaneous communications. For example, B
683 may be receiving requests from many clients other than A, and/or
684 forwarding requests to servers other than C, at the same time that it
685 is handling A's request.
686
687 Any party to the communication which is not acting as a tunnel may
688 employ an internal cache for handling requests. The effect of a cache
689 is that the request/response chain is shortened if one of the
690 participants along the chain has a cached response applicable to that
691 request. The following illustrates the resulting chain if B has a
692 cached copy of an earlier response from O (via C) for a request which
693 has not been cached by UA or A.
694
695 request chain ---------->
696 UA -----v----- A -----v----- B - - - - - - C - - - - - - O
697 <--------- response chain
698
699 Not all responses are usefully cacheable, and some requests may
700 contain modifiers which place special requirements on cache behavior.
701 HTTP requirements for cache behavior and cacheable responses are
702 defined in section 13.
703
704 In fact, there are a wide variety of architectures and configurations
705 of caches and proxies currently being experimented with or deployed
706 across the World Wide Web. These systems include national hierarchies
707 of proxy caches to save transoceanic bandwidth, systems that
708 broadcast or multicast cache entries, organizations that distribute
709 subsets of cached data via CD-ROM, and so on. HTTP systems are used
710 in corporate intranets over high-bandwidth links, and for access via
711 PDAs with low-power radio links and intermittent connectivity. The
712 goal of HTTP/1.1 is to support the wide diversity of configurations
713 already deployed while introducing protocol constructs that meet the
714 needs of those who build web applications that require high
715 reliability and, failing that, at least reliable indications of
716 failure.
717
718 HTTP communication usually takes place over TCP/IP connections. The
719 default port is TCP 80 [19], but other ports can be used. This does
720 not preclude HTTP from being implemented on top of any other protocol
721 on the Internet, or on other networks. HTTP only presumes a reliable
722 transport; any protocol that provides such guarantees can be used;
723 the mapping of the HTTP/1.1 request and response structures onto the
724 transport data units of the protocol in question is outside the scope
725 of this specification.
726
727
728
729
730 Fielding, et al. Standards Track [Page 13]
731
732 RFC 2616 HTTP/1.1 June 1999
733
734
735 In HTTP/1.0, most implementations used a new connection for each
736 request/response exchange. In HTTP/1.1, a connection may be used for
737 one or more request/response exchanges, although connections may be
738 closed for a variety of reasons (see section 8.1).
739
740 2 Notational Conventions and Generic Grammar
741
742 2.1 Augmented BNF
743
744 All of the mechanisms specified in this document are described in
745 both prose and an augmented Backus-Naur Form (BNF) similar to that
746 used by RFC 822 [9]. Implementors will need to be familiar with the
747 notation in order to understand this specification. The augmented BNF
748 includes the following constructs:
749
750 name = definition
751 The name of a rule is simply the name itself (without any
752 enclosing "<" and ">") and is separated from its definition by the
753 equal "=" character. White space is only significant in that
754 indentation of continuation lines is used to indicate a rule
755 definition that spans more than one line. Certain basic rules are
756 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
757 brackets are used within definitions whenever their presence will
758 facilitate discerning the use of rule names.
759
760 "literal"
761 Quotation marks surround literal text. Unless stated otherwise,
762 the text is case-insensitive.
763
764 rule1 | rule2
765 Elements separated by a bar ("|") are alternatives, e.g., "yes |
766 no" will accept yes or no.
767
768 (rule1 rule2)
769 Elements enclosed in parentheses are treated as a single element.
770 Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
771 foo elem" and "elem bar elem".
772
773 *rule
774 The character "*" preceding an element indicates repetition. The
775 full form is "<n>*<m>element" indicating at least <n> and at most
776 <m> occurrences of element. Default values are 0 and infinity so
777 that "*(element)" allows any number, including zero; "1*element"
778 requires at least one; and "1*2element" allows one or two.
779
780 [rule]
781 Square brackets enclose optional elements; "[foo bar]" is
782 equivalent to "*1(foo bar)".
783
784
785
786 Fielding, et al. Standards Track [Page 14]
787
788 RFC 2616 HTTP/1.1 June 1999
789
790
791 N rule
792 Specific repetition: "<n>(element)" is equivalent to
793 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
794 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
795 alphabetic characters.
796
797 #rule
798 A construct "#" is defined, similar to "*", for defining lists of
799 elements. The full form is "<n>#<m>element" indicating at least
800 <n> and at most <m> elements, each separated by one or more commas
801 (",") and OPTIONAL linear white space (LWS). This makes the usual
802 form of lists very easy; a rule such as
803 ( *LWS element *( *LWS "," *LWS element ))
804 can be shown as
805 1#element
806 Wherever this construct is used, null elements are allowed, but do
807 not contribute to the count of elements present. That is,
808 "(element), , (element) " is permitted, but counts as only two
809 elements. Therefore, where at least one element is required, at
810 least one non-null element MUST be present. Default values are 0
811 and infinity so that "#element" allows any number, including zero;
812 "1#element" requires at least one; and "1#2element" allows one or
813 two.
814
815 ; comment
816 A semi-colon, set off some distance to the right of rule text,
817 starts a comment that continues to the end of line. This is a
818 simple way of including useful notes in parallel with the
819 specifications.
820
821 implied *LWS
822 The grammar described by this specification is word-based. Except
823 where noted otherwise, linear white space (LWS) can be included
824 between any two adjacent words (token or quoted-string), and
825 between adjacent words and separators, without changing the
826 interpretation of a field. At least one delimiter (LWS and/or
827
828 separators) MUST exist between any two tokens (for the definition
829 of "token" below), since they would otherwise be interpreted as a
830 single token.
831
832 2.2 Basic Rules
833
834 The following rules are used throughout this specification to
835 describe basic parsing constructs. The US-ASCII coded character set
836 is defined by ANSI X3.4-1986 [21].
837
838
839
840
841
842 Fielding, et al. Standards Track [Page 15]
843
844 RFC 2616 HTTP/1.1 June 1999
845
846
847 OCTET = <any 8-bit sequence of data>
848 CHAR = <any US-ASCII character (octets 0 - 127)>
849 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
850 LOALPHA = <any US-ASCII lowercase letter "a".."z">
851 ALPHA = UPALPHA | LOALPHA
852 DIGIT = <any US-ASCII digit "0".."9">
853 CTL = <any US-ASCII control character
854 (octets 0 - 31) and DEL (127)>
855 CR = <US-ASCII CR, carriage return (13)>
856 LF = <US-ASCII LF, linefeed (10)>
857 SP = <US-ASCII SP, space (32)>
858 HT = <US-ASCII HT, horizontal-tab (9)>
859 <"> = <US-ASCII double-quote mark (34)>
860
861 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
862 protocol elements except the entity-body (see appendix 19.3 for
863 tolerant applications). The end-of-line marker within an entity-body
864 is defined by its associated media type, as described in section 3.7.
865
866 CRLF = CR LF
867
868 HTTP/1.1 header field values can be folded onto multiple lines if the
869 continuation line begins with a space or horizontal tab. All linear
870 white space, including folding, has the same semantics as SP. A
871 recipient MAY replace any linear white space with a single SP before
872 interpreting the field value or forwarding the message downstream.
873
874 LWS = [CRLF] 1*( SP | HT )
875
876 The TEXT rule is only used for descriptive field contents and values
877 that are not intended to be interpreted by the message parser. Words
878 of *TEXT MAY contain characters from character sets other than ISO-
879 8859-1 [22] only when encoded according to the rules of RFC 2047
880 [14].
881
882 TEXT = <any OCTET except CTLs,
883 but including LWS>
884
885 A CRLF is allowed in the definition of TEXT only as part of a header
886 field continuation. It is expected that the folding LWS will be
887 replaced with a single SP before interpretation of the TEXT value.
888
889 Hexadecimal numeric characters are used in several protocol elements.
890
891 HEX = "A" | "B" | "C" | "D" | "E" | "F"
892 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
893
894
895
896
897
898 Fielding, et al. Standards Track [Page 16]
899
900 RFC 2616 HTTP/1.1 June 1999
901
902
903 Many HTTP/1.1 header field values consist of words separated by LWS
904 or special characters. These special characters MUST be in a quoted
905 string to be used within a parameter value (as defined in section
906 3.6).
907
908 token = 1*<any CHAR except CTLs or separators>
909 separators = "(" | ")" | "<" | ">" | "@"
910 | "," | ";" | ":" | "\" | <">
911 | "/" | "[" | "]" | "?" | "="
912 | "{" | "}" | SP | HT
913
914 Comments can be included in some HTTP header fields by surrounding
915 the comment text with parentheses. Comments are only allowed in
916 fields containing "comment" as part of their field value definition.
917 In all other fields, parentheses are considered part of the field
918 value.
919
920 comment = "(" *( ctext | quoted-pair | comment ) ")"
921 ctext = <any TEXT excluding "(" and ")">
922
923 A string of text is parsed as a single word if it is quoted using
924 double-quote marks.
925
926 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
927 qdtext = <any TEXT except <">>
928
929 The backslash character ("\") MAY be used as a single-character
930 quoting mechanism only within quoted-string and comment constructs.
931
932 quoted-pair = "\" CHAR
933
934 3 Protocol Parameters
935
936 3.1 HTTP Version
937
938 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
939 of the protocol. The protocol versioning policy is intended to allow
940 the sender to indicate the format of a message and its capacity for
941 understanding further HTTP communication, rather than the features
942 obtained via that communication. No change is made to the version
943 number for the addition of message components which do not affect
944 communication behavior or which only add to extensible field values.
945 The <minor> number is incremented when the changes made to the
946 protocol add features which do not change the general message parsing
947 algorithm, but which may add to the message semantics and imply
948 additional capabilities of the sender. The <major> number is
949 incremented when the format of a message within the protocol is
950 changed. See RFC 2145 [36] for a fuller explanation.
951
952
953
954 Fielding, et al. Standards Track [Page 17]
955
956 RFC 2616 HTTP/1.1 June 1999
957
958
959 The version of an HTTP message is indicated by an HTTP-Version field
960 in the first line of the message.
961
962 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
963
964 Note that the major and minor numbers MUST be treated as separate
965 integers and that each MAY be incremented higher than a single digit.
966 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
967 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
968 MUST NOT be sent.
969
970 An application that sends a request or response message that includes
971 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
972 with this specification. Applications that are at least conditionally
973 compliant with this specification SHOULD use an HTTP-Version of
974 "HTTP/1.1" in their messages, and MUST do so for any message that is
975 not compatible with HTTP/1.0. For more details on when to send
976 specific HTTP-Version values, see RFC 2145 [36].
977
978 The HTTP version of an application is the highest HTTP version for
979 which the application is at least conditionally compliant.
980
981 Proxy and gateway applications need to be careful when forwarding
982 messages in protocol versions different from that of the application.
983 Since the protocol version indicates the protocol capability of the
984 sender, a proxy/gateway MUST NOT send a message with a version
985 indicator which is greater than its actual version. If a higher
986 version request is received, the proxy/gateway MUST either downgrade
987 the request version, or respond with an error, or switch to tunnel
988 behavior.
989
990 Due to interoperability problems with HTTP/1.0 proxies discovered
991 since the publication of RFC 2068[33], caching proxies MUST, gateways
992 MAY, and tunnels MUST NOT upgrade the request to the highest version
993 they support. The proxy/gateway's response to that request MUST be in
994 the same major version as the request.
995
996 Note: Converting between versions of HTTP may involve modification
997 of header fields required or forbidden by the versions involved.
998
999 3.2 Uniform Resource Identifiers
1000
1001 URIs have been known by many names: WWW addresses, Universal Document
1002 Identifiers, Universal Resource Identifiers [3], and finally the
1003 combination of Uniform Resource Locators (URL) [4] and Names (URN)
1004 [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
1005 simply formatted strings which identify--via name, location, or any
1006 other characteristic--a resource.
1007
1008
1009
1010 Fielding, et al. Standards Track [Page 18]
1011
1012 RFC 2616 HTTP/1.1 June 1999
1013
1014
1015 3.2.1 General Syntax
1016
1017 URIs in HTTP can be represented in absolute form or relative to some
1018 known base URI [11], depending upon the context of their use. The two
1019 forms are differentiated by the fact that absolute URIs always begin
1020 with a scheme name followed by a colon. For definitive information on
1021 URL syntax and semantics, see "Uniform Resource Identifiers (URI):
1022 Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
1023 1738 [4] and RFC 1808 [11]). This specification adopts the
1024 definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
1025 "host","abs_path", "rel_path", and "authority" from that
1026 specification.
1027
1028 The HTTP protocol does not place any a priori limit on the length of
1029 a URI. Servers MUST be able to handle the URI of any resource they
1030 serve, and SHOULD be able to handle URIs of unbounded length if they
1031 provide GET-based forms that could generate such URIs. A server
1032 SHOULD return 414 (Request-URI Too Long) status if a URI is longer
1033 than the server can handle (see section 10.4.15).
1034
1035 Note: Servers ought to be cautious about depending on URI lengths
1036 above 255 bytes, because some older client or proxy
1037 implementations might not properly support these lengths.
1038
1039 3.2.2 http URL
1040
1041 The "http" scheme is used to locate network resources via the HTTP
1042 protocol. This section defines the scheme-specific syntax and
1043 semantics for http URLs.
1044
1045 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
1046
1047 If the port is empty or not given, port 80 is assumed. The semantics
1048 are that the identified resource is located at the server listening
1049 for TCP connections on that port of that host, and the Request-URI
1050 for the resource is abs_path (section 5.1.2). The use of IP addresses
1051 in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
1052 the abs_path is not present in the URL, it MUST be given as "/" when
1053 used as a Request-URI for a resource (section 5.1.2). If a proxy
1054 receives a host name which is not a fully qualified domain name, it
1055 MAY add its domain to the host name it received. If a proxy receives
1056 a fully qualified domain name, the proxy MUST NOT change the host
1057 name.
1058
1059
1060
1061
1062
1063
1064
1065
1066 Fielding, et al. Standards Track [Page 19]
1067
1068 RFC 2616 HTTP/1.1 June 1999
1069
1070
1071 3.2.3 URI Comparison
1072
1073 When comparing two URIs to decide if they match or not, a client
1074 SHOULD use a case-sensitive octet-by-octet comparison of the entire
1075 URIs, with these exceptions:
1076
1077 - A port that is empty or not given is equivalent to the default
1078 port for that URI-reference;
1079
1080 - Comparisons of host names MUST be case-insensitive;
1081
1082 - Comparisons of scheme names MUST be case-insensitive;
1083
1084 - An empty abs_path is equivalent to an abs_path of "/".
1085
1086 Characters other than those in the "reserved" and "unsafe" sets (see
1087 RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
1088
1089 For example, the following three URIs are equivalent:
1090
1091 http://abc.com:80/~smith/home.html
1092 http://ABC.com/%7Esmith/home.html
1093 http://ABC.com:/%7esmith/home.html
1094
1095 3.3 Date/Time Formats
1096
1097 3.3.1 Full Date
1098
1099 HTTP applications have historically allowed three different formats
1100 for the representation of date/time stamps:
1101
1102 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
1103 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
1104 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
1105
1106 The first format is preferred as an Internet standard and represents
1107 a fixed-length subset of that defined by RFC 1123 [8] (an update to
1108 RFC 822 [9]). The second format is in common use, but is based on the
1109 obsolete RFC 850 [12] date format and lacks a four-digit year.
1110 HTTP/1.1 clients and servers that parse the date value MUST accept
1111 all three formats (for compatibility with HTTP/1.0), though they MUST
1112 only generate the RFC 1123 format for representing HTTP-date values
1113 in header fields. See section 19.3 for further information.
1114
1115 Note: Recipients of date values are encouraged to be robust in
1116 accepting date values that may have been sent by non-HTTP
1117 applications, as is sometimes the case when retrieving or posting
1118 messages via proxies/gateways to SMTP or NNTP.
1119
1120
1121
1122 Fielding, et al. Standards Track [Page 20]
1123
1124 RFC 2616 HTTP/1.1 June 1999
1125
1126
1127 All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1128 (GMT), without exception. For the purposes of HTTP, GMT is exactly
1129 equal to UTC (Coordinated Universal Time). This is indicated in the
1130 first two formats by the inclusion of "GMT" as the three-letter
1131 abbreviation for time zone, and MUST be assumed when reading the
1132 asctime format. HTTP-date is case sensitive and MUST NOT include
1133 additional LWS beyond that specifically included as SP in the
1134 grammar.
1135
1136 HTTP-date = rfc1123-date | rfc850-date | asctime-date
1137 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
1138 rfc850-date = weekday "," SP date2 SP time SP "GMT"
1139 asctime-date = wkday SP date3 SP time SP 4DIGIT
1140 date1 = 2DIGIT SP month SP 4DIGIT
1141 ; day month year (e.g., 02 Jun 1982)
1142 date2 = 2DIGIT "-" month "-" 2DIGIT
1143 ; day-month-year (e.g., 02-Jun-82)
1144 date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
1145 ; month day (e.g., Jun 2)
1146 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
1147 ; 00:00:00 - 23:59:59
1148 wkday = "Mon" | "Tue" | "Wed"
1149 | "Thu" | "Fri" | "Sat" | "Sun"
1150 weekday = "Monday" | "Tuesday" | "Wednesday"
1151 | "Thursday" | "Friday" | "Saturday" | "Sunday"
1152 month = "Jan" | "Feb" | "Mar" | "Apr"
1153 | "May" | "Jun" | "Jul" | "Aug"
1154 | "Sep" | "Oct" | "Nov" | "Dec"
1155
1156 Note: HTTP requirements for the date/time stamp format apply only
1157 to their usage within the protocol stream. Clients and servers are
1158 not required to use these formats for user presentation, request
1159 logging, etc.
1160
1161 3.3.2 Delta Seconds
1162
1163 Some HTTP header fields allow a time value to be specified as an
1164 integer number of seconds, represented in decimal, after the time
1165 that the message was received.
1166
1167 delta-seconds = 1*DIGIT
1168
1169 3.4 Character Sets
1170
1171 HTTP uses the same definition of the term "character set" as that
1172 described for MIME:
1173
1174
1175
1176
1177
1178 Fielding, et al. Standards Track [Page 21]
1179
1180 RFC 2616 HTTP/1.1 June 1999
1181
1182
1183 The term "character set" is used in this document to refer to a
1184 method used with one or more tables to convert a sequence of octets
1185 into a sequence of characters. Note that unconditional conversion in
1186 the other direction is not required, in that not all characters may
1187 be available in a given character set and a character set may provide
1188 more than one sequence of octets to represent a particular character.
1189 This definition is intended to allow various kinds of character
1190 encoding, from simple single-table mappings such as US-ASCII to
1191 complex table switching methods such as those that use ISO-2022's
1192 techniques. However, the definition associated with a MIME character
1193 set name MUST fully specify the mapping to be performed from octets
1194 to characters. In particular, use of external profiling information
1195 to determine the exact mapping is not permitted.
1196
1197 Note: This use of the term "character set" is more commonly
1198 referred to as a "character encoding." However, since HTTP and
1199 MIME share the same registry, it is important that the terminology
1200 also be shared.
1201
1202 HTTP character sets are identified by case-insensitive tokens. The
1203 complete set of tokens is defined by the IANA Character Set registry
1204 [19].
1205
1206 charset = token
1207
1208 Although HTTP allows an arbitrary token to be used as a charset
1209 value, any token that has a predefined value within the IANA
1210 Character Set registry [19] MUST represent the character set defined
1211 by that registry. Applications SHOULD limit their use of character
1212 sets to those defined by the IANA registry.
1213
1214 Implementors should be aware of IETF character set requirements [38]
1215 [41].
1216
1217 3.4.1 Missing Charset
1218
1219 Some HTTP/1.0 software has interpreted a Content-Type header without
1220 charset parameter incorrectly to mean "recipient should guess."
1221 Senders wishing to defeat this behavior MAY include a charset
1222 parameter even when the charset is ISO-8859-1 and SHOULD do so when
1223 it is known that it will not confuse the recipient.
1224
1225 Unfortunately, some older HTTP/1.0 clients did not deal properly with
1226 an explicit charset parameter. HTTP/1.1 recipients MUST respect the
1227 charset label provided by the sender; and those user agents that have
1228 a provision to "guess" a charset MUST use the charset from the
1229
1230
1231
1232
1233
1234 Fielding, et al. Standards Track [Page 22]
1235
1236 RFC 2616 HTTP/1.1 June 1999
1237
1238
1239 content-type field if they support that charset, rather than the
1240 recipient's preference, when initially displaying a document. See
1241 section 3.7.1.
1242
1243 3.5 Content Codings
1244
1245 Content coding values indicate an encoding transformation that has
1246 been or can be applied to an entity. Content codings are primarily
1247 used to allow a document to be compressed or otherwise usefully
1248 transformed without losing the identity of its underlying media type
1249 and without loss of information. Frequently, the entity is stored in
1250 coded form, transmitted directly, and only decoded by the recipient.
1251
1252 content-coding = token
1253
1254 All content-coding values are case-insensitive. HTTP/1.1 uses
1255 content-coding values in the Accept-Encoding (section 14.3) and
1256 Content-Encoding (section 14.11) header fields. Although the value
1257 describes the content-coding, what is more important is that it
1258 indicates what decoding mechanism will be required to remove the
1259 encoding.
1260
1261 The Internet Assigned Numbers Authority (IANA) acts as a registry for
1262 content-coding value tokens. Initially, the registry contains the
1263 following tokens:
1264
1265 gzip An encoding format produced by the file compression program
1266 "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
1267 Lempel-Ziv coding (LZ77) with a 32 bit CRC.
1268
1269 compress
1270 The encoding format produced by the common UNIX file compression
1271 program "compress". This format is an adaptive Lempel-Ziv-Welch
1272 coding (LZW).
1273
1274 Use of program names for the identification of encoding formats
1275 is not desirable and is discouraged for future encodings. Their
1276 use here is representative of historical practice, not good
1277 design. For compatibility with previous implementations of HTTP,
1278 applications SHOULD consider "x-gzip" and "x-compress" to be
1279 equivalent to "gzip" and "compress" respectively.
1280
1281 deflate
1282 The "zlib" format defined in RFC 1950 [31] in combination with
1283 the "deflate" compression mechanism described in RFC 1951 [29].
1284
1285
1286
1287
1288
1289
1290 Fielding, et al. Standards Track [Page 23]
1291
1292 RFC 2616 HTTP/1.1 June 1999
1293
1294
1295 identity
1296 The default (identity) encoding; the use of no transformation
1297 whatsoever. This content-coding is used only in the Accept-
1298 Encoding header, and SHOULD NOT be used in the Content-Encoding
1299 header.
1300
1301 New content-coding value tokens SHOULD be registered; to allow
1302 interoperability between clients and servers, specifications of the
1303 content coding algorithms needed to implement a new value SHOULD be
1304 publicly available and adequate for independent implementation, and
1305 conform to the purpose of content coding defined in this section.
1306
1307 3.6 Transfer Codings
1308
1309 Transfer-coding values are used to indicate an encoding
1310 transformation that has been, can be, or may need to be applied to an
1311 entity-body in order to ensure "safe transport" through the network.
1312 This differs from a content coding in that the transfer-coding is a
1313 property of the message, not of the original entity.
1314
1315 transfer-coding = "chunked" | transfer-extension
1316 transfer-extension = token *( ";" parameter )
1317
1318 Parameters are in the form of attribute/value pairs.
1319
1320 parameter = attribute "=" value
1321 attribute = token
1322 value = token | quoted-string
1323
1324 All transfer-coding values are case-insensitive. HTTP/1.1 uses
1325 transfer-coding values in the TE header field (section 14.39) and in
1326 the Transfer-Encoding header field (section 14.41).
1327
1328 Whenever a transfer-coding is applied to a message-body, the set of
1329 transfer-codings MUST include "chunked", unless the message is
1330 terminated by closing the connection. When the "chunked" transfer-
1331 coding is used, it MUST be the last transfer-coding applied to the
1332 message-body. The "chunked" transfer-coding MUST NOT be applied more
1333 than once to a message-body. These rules allow the recipient to
1334 determine the transfer-length of the message (section 4.4).
1335
1336 Transfer-codings are analogous to the Content-Transfer-Encoding
1337 values of MIME [7], which were designed to enable safe transport of
1338 binary data over a 7-bit transport service. However, safe transport
1339 has a different focus for an 8bit-clean transfer protocol. In HTTP,
1340 the only unsafe characteristic of message-bodies is the difficulty in
1341 determining the exact body length (section 7.2.2), or the desire to
1342 encrypt data over a shared transport.
1343
1344
1345
1346 Fielding, et al. Standards Track [Page 24]
1347
1348 RFC 2616 HTTP/1.1 June 1999
1349
1350
1351 The Internet Assigned Numbers Authority (IANA) acts as a registry for
1352 transfer-coding value tokens. Initially, the registry contains the
1353 following tokens: "chunked" (section 3.6.1), "identity" (section
1354 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
1355 (section 3.5).
1356
1357 New transfer-coding value tokens SHOULD be registered in the same way
1358 as new content-coding value tokens (section 3.5).
1359
1360 A server which receives an entity-body with a transfer-coding it does
1361 not understand SHOULD return 501 (Unimplemented), and close the
1362 connection. A server MUST NOT send transfer-codings to an HTTP/1.0
1363 client.
1364
1365 3.6.1 Chunked Transfer Coding
1366
1367 The chunked encoding modifies the body of a message in order to
1368 transfer it as a series of chunks, each with its own size indicator,
1369 followed by an OPTIONAL trailer containing entity-header fields. This
1370 allows dynamically produced content to be transferred along with the
1371 information necessary for the recipient to verify that it has
1372 received the full message.
1373
1374 Chunked-Body = *chunk
1375 last-chunk
1376 trailer
1377 CRLF
1378
1379 chunk = chunk-size [ chunk-extension ] CRLF
1380 chunk-data CRLF
1381 chunk-size = 1*HEX
1382 last-chunk = 1*("0") [ chunk-extension ] CRLF
1383
1384 chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
1385 chunk-ext-name = token
1386 chunk-ext-val = token | quoted-string
1387 chunk-data = chunk-size(OCTET)
1388 trailer = *(entity-header CRLF)
1389
1390 The chunk-size field is a string of hex digits indicating the size of
1391 the chunk. The chunked encoding is ended by any chunk whose size is
1392 zero, followed by the trailer, which is terminated by an empty line.
1393
1394 The trailer allows the sender to include additional HTTP header
1395 fields at the end of the message. The Trailer header field can be
1396 used to indicate which header fields are included in a trailer (see
1397 section 14.40).
1398
1399
1400
1401
1402 Fielding, et al. Standards Track [Page 25]
1403
1404 RFC 2616 HTTP/1.1 June 1999
1405
1406
1407 A server using chunked transfer-coding in a response MUST NOT use the
1408 trailer for any header fields unless at least one of the following is
1409 true:
1410
1411 a)the request included a TE header field that indicates "trailers" is
1412 acceptable in the transfer-coding of the response, as described in
1413 section 14.39; or,
1414
1415 b)the server is the origin server for the response, the trailer
1416 fields consist entirely of optional metadata, and the recipient
1417 could use the message (in a manner acceptable to the origin server)
1418 without receiving this metadata. In other words, the origin server
1419 is willing to accept the possibility that the trailer fields might
1420 be silently discarded along the path to the client.
1421
1422 This requirement prevents an interoperability failure when the
1423 message is being received by an HTTP/1.1 (or later) proxy and
1424 forwarded to an HTTP/1.0 recipient. It avoids a situation where
1425 compliance with the protocol would have necessitated a possibly
1426 infinite buffer on the proxy.
1427
1428 An example process for decoding a Chunked-Body is presented in
1429 appendix 19.4.6.
1430
1431 All HTTP/1.1 applications MUST be able to receive and decode the
1432 "chunked" transfer-coding, and MUST ignore chunk-extension extensions
1433 they do not understand.
1434
1435 3.7 Media Types
1436
1437 HTTP uses Internet Media Types [17] in the Content-Type (section
1438 14.17) and Accept (section 14.1) header fields in order to provide
1439 open and extensible data typing and type negotiation.
1440
1441 media-type = type "/" subtype *( ";" parameter )
1442 type = token
1443 subtype = token
1444
1445 Parameters MAY follow the type/subtype in the form of attribute/value
1446 pairs (as defined in section 3.6).
1447
1448 The type, subtype, and parameter attribute names are case-
1449 insensitive. Parameter values might or might not be case-sensitive,
1450 depending on the semantics of the parameter name. Linear white space
1451 (LWS) MUST NOT be used between the type and subtype, nor between an
1452 attribute and its value. The presence or absence of a parameter might
1453 be significant to the processing of a media-type, depending on its
1454 definition within the media type registry.
1455
1456
1457
1458 Fielding, et al. Standards Track [Page 26]
1459
1460 RFC 2616 HTTP/1.1 June 1999
1461
1462
1463 Note that some older HTTP applications do not recognize media type
1464 parameters. When sending data to older HTTP applications,
1465 implementations SHOULD only use media type parameters when they are
1466 required by that type/subtype definition.
1467
1468 Media-type values are registered with the Internet Assigned Number
1469 Authority (IANA [19]). The media type registration process is
1470 outlined in RFC 1590 [17]. Use of non-registered media types is
1471 discouraged.
1472
1473 3.7.1 Canonicalization and Text Defaults
1474
1475 Internet media types are registered with a canonical form. An
1476 entity-body transferred via HTTP messages MUST be represented in the
1477 appropriate canonical form prior to its transmission except for
1478 "text" types, as defined in the next paragraph.
1479
1480 When in canonical form, media subtypes of the "text" type use CRLF as
1481 the text line break. HTTP relaxes this requirement and allows the
1482 transport of text media with plain CR or LF alone representing a line
1483 break when it is done consistently for an entire entity-body. HTTP
1484 applications MUST accept CRLF, bare CR, and bare LF as being
1485 representative of a line break in text media received via HTTP. In
1486 addition, if the text is represented in a character set that does not
1487 use octets 13 and 10 for CR and LF respectively, as is the case for
1488 some multi-byte character sets, HTTP allows the use of whatever octet
1489 sequences are defined by that character set to represent the
1490 equivalent of CR and LF for line breaks. This flexibility regarding
1491 line breaks applies only to text media in the entity-body; a bare CR
1492 or LF MUST NOT be substituted for CRLF within any of the HTTP control
1493 structures (such as header fields and multipart boundaries).
1494
1495 If an entity-body is encoded with a content-coding, the underlying
1496 data MUST be in a form defined above prior to being encoded.
1497
1498 The "charset" parameter is used with some media types to define the
1499 character set (section 3.4) of the data. When no explicit charset
1500 parameter is provided by the sender, media subtypes of the "text"
1501 type are defined to have a default charset value of "ISO-8859-1" when
1502 received via HTTP. Data in character sets other than "ISO-8859-1" or
1503 its subsets MUST be labeled with an appropriate charset value. See
1504 section 3.4.1 for compatibility problems.
1505
1506 3.7.2 Multipart Types
1507
1508 MIME provides for a number of "multipart" types -- encapsulations of
1509 one or more entities within a single message-body. All multipart
1510 types share a common syntax, as defined in section 5.1.1 of RFC 2046
1511
1512
1513
1514 Fielding, et al. Standards Track [Page 27]
1515
1516 RFC 2616 HTTP/1.1 June 1999
1517
1518
1519 [40], and MUST include a boundary parameter as part of the media type
1520 value. The message body is itself a protocol element and MUST
1521 therefore use only CRLF to represent line breaks between body-parts.
1522 Unlike in RFC 2046, the epilogue of any multipart message MUST be
1523 empty; HTTP applications MUST NOT transmit the epilogue (even if the
1524 original multipart contains an epilogue). These restrictions exist in
1525 order to preserve the self-delimiting nature of a multipart message-
1526 body, wherein the "end" of the message-body is indicated by the
1527 ending multipart boundary.
1528
1529 In general, HTTP treats a multipart message-body no differently than
1530 any other media type: strictly as payload. The one exception is the
1531 "multipart/byteranges" type (appendix 19.2) when it appears in a 206
1532 (Partial Content) response, which will be interpreted by some HTTP
1533 caching mechanisms as described in sections 13.5.4 and 14.16. In all
1534 other cases, an HTTP user agent SHOULD follow the same or similar
1535 behavior as a MIME user agent would upon receipt of a multipart type.
1536 The MIME header fields within each body-part of a multipart message-
1537 body do not have any significance to HTTP beyond that defined by
1538 their MIME semantics.
1539
1540 In general, an HTTP user agent SHOULD follow the same or similar
1541 behavior as a MIME user agent would upon receipt of a multipart type.
1542 If an application receives an unrecognized multipart subtype, the
1543 application MUST treat it as being equivalent to "multipart/mixed".
1544
1545 Note: The "multipart/form-data" type has been specifically defined
1546 for carrying form data suitable for processing via the POST
1547 request method, as described in RFC 1867 [15].
1548
1549 3.8 Product Tokens
1550
1551 Product tokens are used to allow communicating applications to
1552 identify themselves by software name and version. Most fields using
1553 product tokens also allow sub-products which form a significant part
1554 of the application to be listed, separated by white space. By
1555 convention, the products are listed in order of their significance
1556 for identifying the application.
1557
1558 product = token ["/" product-version]
1559 product-version = token
1560
1561 Examples:
1562
1563 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1564 Server: Apache/0.8.4
1565
1566
1567
1568
1569
1570 Fielding, et al. Standards Track [Page 28]
1571
1572 RFC 2616 HTTP/1.1 June 1999
1573
1574
1575 Product tokens SHOULD be short and to the point. They MUST NOT be
1576 used for advertising or other non-essential information. Although any
1577 token character MAY appear in a product-version, this token SHOULD
1578 only be used for a version identifier (i.e., successive versions of
1579 the same product SHOULD only differ in the product-version portion of
1580 the product value).
1581
1582 3.9 Quality Values
1583
1584 HTTP content negotiation (section 12) uses short "floating point"
1585 numbers to indicate the relative importance ("weight") of various
1586 negotiable parameters. A weight is normalized to a real number in
1587 the range 0 through 1, where 0 is the minimum and 1 the maximum
1588 value. If a parameter has a quality value of 0, then content with
1589 this parameter is `not acceptable' for the client. HTTP/1.1
1590 applications MUST NOT generate more than three digits after the
1591 decimal point. User configuration of these values SHOULD also be
1592 limited in this fashion.
1593
1594 qvalue = ( "0" [ "." 0*3DIGIT ] )
1595 | ( "1" [ "." 0*3("0") ] )
1596
1597 "Quality values" is a misnomer, since these values merely represent
1598 relative degradation in desired quality.
1599
1600 3.10 Language Tags
1601
1602 A language tag identifies a natural language spoken, written, or
1603 otherwise conveyed by human beings for communication of information
1604 to other human beings. Computer languages are explicitly excluded.
1605 HTTP uses language tags within the Accept-Language and Content-
1606 Language fields.
1607
1608 The syntax and registry of HTTP language tags is the same as that
1609 defined by RFC 1766 [1]. In summary, a language tag is composed of 1
1610 or more parts: A primary language tag and a possibly empty series of
1611 subtags:
1612
1613 language-tag = primary-tag *( "-" subtag )
1614 primary-tag = 1*8ALPHA
1615 subtag = 1*8ALPHA
1616
1617 White space is not allowed within the tag and all tags are case-
1618 insensitive. The name space of language tags is administered by the
1619 IANA. Example tags include:
1620
1621 en, en-US, en-cockney, i-cherokee, x-pig-latin
1622
1623
1624
1625
1626 Fielding, et al. Standards Track [Page 29]
1627
1628 RFC 2616 HTTP/1.1 June 1999
1629
1630
1631 where any two-letter primary-tag is an ISO-639 language abbreviation
1632 and any two-letter initial subtag is an ISO-3166 country code. (The
1633 last three tags above are not registered tags; all but the last are
1634 examples of tags which could be registered in future.)
1635
1636 3.11 Entity Tags
1637
1638 Entity tags are used for comparing two or more entities from the same
1639 requested resource. HTTP/1.1 uses entity tags in the ETag (section
1640 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
1641 If-Range (section 14.27) header fields. The definition of how they
1642 are used and compared as cache validators is in section 13.3.3. An
1643 entity tag consists of an opaque quoted string, possibly prefixed by
1644 a weakness indicator.
1645
1646 entity-tag = [ weak ] opaque-tag
1647 weak = "W/"
1648 opaque-tag = quoted-string
1649
1650 A "strong entity tag" MAY be shared by two entities of a resource
1651 only if they are equivalent by octet equality.
1652
1653 A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
1654 two entities of a resource only if the entities are equivalent and
1655 could be substituted for each other with no significant change in
1656 semantics. A weak entity tag can only be used for weak comparison.
1657
1658 An entity tag MUST be unique across all versions of all entities
1659 associated with a particular resource. A given entity tag value MAY
1660 be used for entities obtained by requests on different URIs. The use
1661 of the same entity tag value in conjunction with entities obtained by
1662 requests on different URIs does not imply the equivalence of those
1663 entities.
1664
1665 3.12 Range Units
1666
1667 HTTP/1.1 allows a client to request that only part (a range of) the
1668 response entity be included within the response. HTTP/1.1 uses range
1669 units in the Range (section 14.35) and Content-Range (section 14.16)
1670 header fields. An entity can be broken down into subranges according
1671 to various structural units.
1672
1673 range-unit = bytes-unit | other-range-unit
1674 bytes-unit = "bytes"
1675 other-range-unit = token
1676
1677 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
1678 implementations MAY ignore ranges specified using other units.
1679
1680
1681
1682 Fielding, et al. Standards Track [Page 30]
1683
1684 RFC 2616 HTTP/1.1 June 1999
1685
1686
1687 HTTP/1.1 has been designed to allow implementations of applications
1688 that do not depend on knowledge of ranges.
1689
1690 4 HTTP Message
1691
1692 4.1 Message Types
1693
1694 HTTP messages consist of requests from client to server and responses
1695 from server to client.
1696
1697 HTTP-message = Request | Response ; HTTP/1.1 messages
1698
1699 Request (section 5) and Response (section 6) messages use the generic
1700 message format of RFC 822 [9] for transferring entities (the payload
1701 of the message). Both types of message consist of a start-line, zero
1702 or more header fields (also known as "headers"), an empty line (i.e.,
1703 a line with nothing preceding the CRLF) indicating the end of the
1704 header fields, and possibly a message-body.
1705
1706 generic-message = start-line
1707 *(message-header CRLF)
1708 CRLF
1709 [ message-body ]
1710 start-line = Request-Line | Status-Line
1711
1712 In the interest of robustness, servers SHOULD ignore any empty
1713 line(s) received where a Request-Line is expected. In other words, if
1714 the server is reading the protocol stream at the beginning of a
1715 message and receives a CRLF first, it should ignore the CRLF.
1716
1717 Certain buggy HTTP/1.0 client implementations generate extra CRLF's
1718 after a POST request. To restate what is explicitly forbidden by the
1719 BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
1720 extra CRLF.
1721
1722 4.2 Message Headers
1723
1724 HTTP header fields, which include general-header (section 4.5),
1725 request-header (section 5.3), response-header (section 6.2), and
1726 entity-header (section 7.1) fields, follow the same generic format as
1727 that given in Section 3.1 of RFC 822 [9]. Each header field consists
1728 of a name followed by a colon (":") and the field value. Field names
1729 are case-insensitive. The field value MAY be preceded by any amount
1730 of LWS, though a single SP is preferred. Header fields can be
1731 extended over multiple lines by preceding each extra line with at
1732 least one SP or HT. Applications ought to follow "common form", where
1733 one is known or indicated, when generating HTTP constructs, since
1734 there might exist some implementations that fail to accept anything
1735
1736
1737
1738 Fielding, et al. Standards Track [Page 31]
1739
1740 RFC 2616 HTTP/1.1 June 1999
1741
1742
1743 beyond the common forms.
1744
1745 message-header = field-name ":" [ field-value ]
1746 field-name = token
1747 field-value = *( field-content | LWS )
1748 field-content = <the OCTETs making up the field-value
1749 and consisting of either *TEXT or combinations
1750 of token, separators, and quoted-string>
1751
1752 The field-content does not include any leading or trailing LWS:
1753 linear white space occurring before the first non-whitespace
1754 character of the field-value or after the last non-whitespace
1755 character of the field-value. Such leading or trailing LWS MAY be
1756 removed without changing the semantics of the field value. Any LWS
1757 that occurs between field-content MAY be replaced with a single SP
1758 before interpreting the field value or forwarding the message
1759 downstream.
1760
1761 The order in which header fields with differing field names are
1762 received is not significant. However, it is "good practice" to send
1763 general-header fields first, followed by request-header or response-
1764 header fields, and ending with the entity-header fields.
1765
1766 Multiple message-header fields with the same field-name MAY be
1767 present in a message if and only if the entire field-value for that
1768 header field is defined as a comma-separated list [i.e., #(values)].
1769 It MUST be possible to combine the multiple header fields into one
1770 "field-name: field-value" pair, without changing the semantics of the
1771 message, by appending each subsequent field-value to the first, each
1772 separated by a comma. The order in which header fields with the same
1773 field-name are received is therefore significant to the
1774 interpretation of the combined field value, and thus a proxy MUST NOT
1775 change the order of these field values when a message is forwarded.
1776
1777 4.3 Message Body
1778
1779 The message-body (if any) of an HTTP message is used to carry the
1780 entity-body associated with the request or response. The message-body
1781 differs from the entity-body only when a transfer-coding has been
1782 applied, as indicated by the Transfer-Encoding header field (section
1783 14.41).
1784
1785 message-body = entity-body
1786 | <entity-body encoded as per Transfer-Encoding>
1787
1788 Transfer-Encoding MUST be used to indicate any transfer-codings
1789 applied by an application to ensure safe and proper transfer of the
1790 message. Transfer-Encoding is a property of the message, not of the
1791
1792
1793
1794 Fielding, et al. Standards Track [Page 32]
1795
1796 RFC 2616 HTTP/1.1 June 1999
1797
1798
1799 entity, and thus MAY be added or removed by any application along the
1800 request/response chain. (However, section 3.6 places restrictions on
1801 when certain transfer-codings may be used.)
1802
1803 The rules for when a message-body is allowed in a message differ for
1804 requests and responses.
1805
1806 The presence of a message-body in a request is signaled by the
1807 inclusion of a Content-Length or Transfer-Encoding header field in
1808 the request's message-headers. A message-body MUST NOT be included in
1809 a request if the specification of the request method (section 5.1.1)
1810 does not allow sending an entity-body in requests. A server SHOULD
1811 read and forward a message-body on any request; if the request method
1812 does not include defined semantics for an entity-body, then the
1813 message-body SHOULD be ignored when handling the request.
1814
1815 For response messages, whether or not a message-body is included with
1816 a message is dependent on both the request method and the response
1817 status code (section 6.1.1). All responses to the HEAD request method
1818 MUST NOT include a message-body, even though the presence of entity-
1819 header fields might lead one to believe they do. All 1xx
1820 (informational), 204 (no content), and 304 (not modified) responses
1821 MUST NOT include a message-body. All other responses do include a
1822 message-body, although it MAY be of zero length.
1823
1824 4.4 Message Length
1825
1826 The transfer-length of a message is the length of the message-body as
1827 it appears in the message; that is, after any transfer-codings have
1828 been applied. When a message-body is included with a message, the
1829 transfer-length of that body is determined by one of the following
1830 (in order of precedence):
1831
1832 1.Any response message which "MUST NOT" include a message-body (such
1833 as the 1xx, 204, and 304 responses and any response to a HEAD
1834 request) is always terminated by the first empty line after the
1835 header fields, regardless of the entity-header fields present in
1836 the message.
1837
1838 2.If a Transfer-Encoding header field (section 14.41) is present and
1839 has any value other than "identity", then the transfer-length is
1840 defined by use of the "chunked" transfer-coding (section 3.6),
1841 unless the message is terminated by closing the connection.
1842
1843 3.If a Content-Length header field (section 14.13) is present, its
1844 decimal value in OCTETs represents both the entity-length and the
1845 transfer-length. The Content-Length header field MUST NOT be sent
1846 if these two lengths are different (i.e., if a Transfer-Encoding
1847
1848
1849
1850 Fielding, et al. Standards Track [Page 33]
1851
1852 RFC 2616 HTTP/1.1 June 1999
1853
1854
1855 header field is present). If a message is received with both a
1856 Transfer-Encoding header field and a Content-Length header field,
1857 the latter MUST be ignored.
1858
1859 4.If the message uses the media type "multipart/byteranges", and the
1860 ransfer-length is not otherwise specified, then this self-
1861 elimiting media type defines the transfer-length. This media type
1862 UST NOT be used unless the sender knows that the recipient can arse
1863 it; the presence in a request of a Range header with ultiple byte-
1864 range specifiers from a 1.1 client implies that the lient can parse
1865 multipart/byteranges responses.
1866
1867 A range header might be forwarded by a 1.0 proxy that does not
1868 understand multipart/byteranges; in this case the server MUST
1869 delimit the message using methods defined in items 1,3 or 5 of
1870 this section.
1871
1872 5.By the server closing the connection. (Closing the connection
1873 cannot be used to indicate the end of a request body, since that
1874 would leave no possibility for the server to send back a response.)
1875
1876 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
1877 containing a message-body MUST include a valid Content-Length header
1878 field unless the server is known to be HTTP/1.1 compliant. If a
1879 request contains a message-body and a Content-Length is not given,
1880 the server SHOULD respond with 400 (bad request) if it cannot
1881 determine the length of the message, or with 411 (length required) if
1882 it wishes to insist on receiving a valid Content-Length.
1883
1884 All HTTP/1.1 applications that receive entities MUST accept the
1885 "chunked" transfer-coding (section 3.6), thus allowing this mechanism
1886 to be used for messages when the message length cannot be determined
1887 in advance.
1888
1889 Messages MUST NOT include both a Content-Length header field and a
1890 non-identity transfer-coding. If the message does include a non-
1891 identity transfer-coding, the Content-Length MUST be ignored.
1892
1893 When a Content-Length is given in a message where a message-body is
1894 allowed, its field value MUST exactly match the number of OCTETs in
1895 the message-body. HTTP/1.1 user agents MUST notify the user when an
1896 invalid length is received and detected.
1897
1898 4.5 General Header Fields
1899
1900 There are a few header fields which have general applicability for
1901 both request and response messages, but which do not apply to the
1902 entity being transferred. These header fields apply only to the
1903
1904
1905
1906 Fielding, et al. Standards Track [Page 34]
1907
1908 RFC 2616 HTTP/1.1 June 1999
1909
1910
1911 message being transmitted.
1912
1913 general-header = Cache-Control ; Section 14.9
1914 | Connection ; Section 14.10
1915 | Date ; Section 14.18
1916 | Pragma ; Section 14.32
1917 | Trailer ; Section 14.40
1918 | Transfer-Encoding ; Section 14.41
1919 | Upgrade ; Section 14.42
1920 | Via ; Section 14.45
1921 | Warning ; Section 14.46
1922
1923 General-header field names can be extended reliably only in
1924 combination with a change in the protocol version. However, new or
1925 experimental header fields may be given the semantics of general
1926 header fields if all parties in the communication recognize them to
1927 be general-header fields. Unrecognized header fields are treated as
1928 entity-header fields.
1929
1930 5 Request
1931
1932 A request message from a client to a server includes, within the
1933 first line of that message, the method to be applied to the resource,
1934 the identifier of the resource, and the protocol version in use.
1935
1936 Request = Request-Line ; Section 5.1
1937 *(( general-header ; Section 4.5
1938 | request-header ; Section 5.3
1939 | entity-header ) CRLF) ; Section 7.1
1940 CRLF
1941 [ message-body ] ; Section 4.3
1942
1943 5.1 Request-Line
1944
1945 The Request-Line begins with a method token, followed by the
1946 Request-URI and the protocol version, and ending with CRLF. The
1947 elements are separated by SP characters. No CR or LF is allowed
1948 except in the final CRLF sequence.
1949
1950 Request-Line = Method SP Request-URI SP HTTP-Version CRLF
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962 Fielding, et al. Standards Track [Page 35]
1963
1964 RFC 2616 HTTP/1.1 June 1999
1965
1966
1967 5.1.1 Method
1968
1969 The Method token indicates the method to be performed on the
1970 resource identified by the Request-URI. The method is case-sensitive.
1971
1972 Method = "OPTIONS" ; Section 9.2
1973 | "GET" ; Section 9.3
1974 | "HEAD" ; Section 9.4
1975 | "POST" ; Section 9.5
1976 | "PUT" ; Section 9.6
1977 | "DELETE" ; Section 9.7
1978 | "TRACE" ; Section 9.8
1979 | "CONNECT" ; Section 9.9
1980 | extension-method
1981 extension-method = token
1982
1983 The list of methods allowed by a resource can be specified in an
1984 Allow header field (section 14.7). The return code of the response
1985 always notifies the client whether a method is currently allowed on a
1986 resource, since the set of allowed methods can change dynamically. An
1987 origin server SHOULD return the status code 405 (Method Not Allowed)
1988 if the method is known by the origin server but not allowed for the
1989 requested resource, and 501 (Not Implemented) if the method is
1990 unrecognized or not implemented by the origin server. The methods GET
1991 and HEAD MUST be supported by all general-purpose servers. All other
1992 methods are OPTIONAL; however, if the above methods are implemented,
1993 they MUST be implemented with the same semantics as those specified
1994 in section 9.
1995
1996 5.1.2 Request-URI
1997
1998 The Request-URI is a Uniform Resource Identifier (section 3.2) and
1999 identifies the resource upon which to apply the request.
2000
2001 Request-URI = "*" | absoluteURI | abs_path | authority
2002
2003 The four options for Request-URI are dependent on the nature of the
2004 request. The asterisk "*" means that the request does not apply to a
2005 particular resource, but to the server itself, and is only allowed
2006 when the method used does not necessarily apply to a resource. One
2007 example would be
2008
2009 OPTIONS * HTTP/1.1
2010
2011 The absoluteURI form is REQUIRED when the request is being made to a
2012 proxy. The proxy is requested to forward the request or service it
2013 from a valid cache, and return the response. Note that the proxy MAY
2014 forward the request on to another proxy or directly to the server
2015
2016
2017
2018 Fielding, et al. Standards Track [Page 36]
2019
2020 RFC 2616 HTTP/1.1 June 1999
2021
2022
2023 specified by the absoluteURI. In order to avoid request loops, a
2024 proxy MUST be able to recognize all of its server names, including
2025 any aliases, local variations, and the numeric IP address. An example
2026 Request-Line would be:
2027
2028 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
2029
2030 To allow for transition to absoluteURIs in all requests in future
2031 versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
2032 form in requests, even though HTTP/1.1 clients will only generate
2033 them in requests to proxies.
2034
2035 The authority form is only used by the CONNECT method (section 9.9).
2036
2037 The most common form of Request-URI is that used to identify a
2038 resource on an origin server or gateway. In this case the absolute
2039 path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
2040 the Request-URI, and the network location of the URI (authority) MUST
2041 be transmitted in a Host header field. For example, a client wishing
2042 to retrieve the resource above directly from the origin server would
2043 create a TCP connection to port 80 of the host "www.w3.org" and send
2044 the lines:
2045
2046 GET /pub/WWW/TheProject.html HTTP/1.1
2047 Host: www.w3.org
2048
2049 followed by the remainder of the Request. Note that the absolute path
2050 cannot be empty; if none is present in the original URI, it MUST be
2051 given as "/" (the server root).
2052
2053 The Request-URI is transmitted in the format specified in section
2054 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
2055 [42], the origin server MUST decode the Request-URI in order to
2056 properly interpret the request. Servers SHOULD respond to invalid
2057 Request-URIs with an appropriate status code.
2058
2059 A transparent proxy MUST NOT rewrite the "abs_path" part of the
2060 received Request-URI when forwarding it to the next inbound server,
2061 except as noted above to replace a null abs_path with "/".
2062
2063 Note: The "no rewrite" rule prevents the proxy from changing the
2064 meaning of the request when the origin server is improperly using
2065 a non-reserved URI character for a reserved purpose. Implementors
2066 should be aware that some pre-HTTP/1.1 proxies have been known to
2067 rewrite the Request-URI.
2068
2069
2070
2071
2072
2073
2074 Fielding, et al. Standards Track [Page 37]
2075
2076 RFC 2616 HTTP/1.1 June 1999
2077
2078
2079 5.2 The Resource Identified by a Request
2080
2081 The exact resource identified by an Internet request is determined by
2082 examining both the Request-URI and the Host header field.
2083
2084 An origin server that does not allow resources to differ by the
2085 requested host MAY ignore the Host header field value when
2086 determining the resource identified by an HTTP/1.1 request. (But see
2087 section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
2088
2089 An origin server that does differentiate resources based on the host
2090 requested (sometimes referred to as virtual hosts or vanity host
2091 names) MUST use the following rules for determining the requested
2092 resource on an HTTP/1.1 request:
2093
2094 1. If Request-URI is an absoluteURI, the host is part of the
2095 Request-URI. Any Host header field value in the request MUST be
2096 ignored.
2097
2098 2. If the Request-URI is not an absoluteURI, and the request includes
2099 a Host header field, the host is determined by the Host header
2100 field value.
2101
2102 3. If the host as determined by rule 1 or 2 is not a valid host on
2103 the server, the response MUST be a 400 (Bad Request) error message.
2104
2105 Recipients of an HTTP/1.0 request that lacks a Host header field MAY
2106 attempt to use heuristics (e.g., examination of the URI path for
2107 something unique to a particular host) in order to determine what
2108 exact resource is being requested.
2109
2110 5.3 Request Header Fields
2111
2112 The request-header fields allow the client to pass additional
2113 information about the request, and about the client itself, to the
2114 server. These fields act as request modifiers, with semantics
2115 equivalent to the parameters on a programming language method
2116 invocation.
2117
2118 request-header = Accept ; Section 14.1
2119 | Accept-Charset ; Section 14.2
2120 | Accept-Encoding ; Section 14.3
2121 | Accept-Language ; Section 14.4
2122 | Authorization ; Section 14.8
2123 | Expect ; Section 14.20
2124 | From ; Section 14.22
2125 | Host ; Section 14.23
2126 | If-Match ; Section 14.24
2127
2128
2129
2130 Fielding, et al. Standards Track [Page 38]
2131
2132 RFC 2616 HTTP/1.1 June 1999
2133
2134
2135 | If-Modified-Since ; Section 14.25
2136 | If-None-Match ; Section 14.26
2137 | If-Range ; Section 14.27
2138 | If-Unmodified-Since ; Section 14.28
2139 | Max-Forwards ; Section 14.31
2140 | Proxy-Authorization ; Section 14.34
2141 | Range ; Section 14.35
2142 | Referer ; Section 14.36
2143 | TE ; Section 14.39
2144 | User-Agent ; Section 14.43
2145
2146 Request-header field names can be extended reliably only in
2147 combination with a change in the protocol version. However, new or
2148 experimental header fields MAY be given the semantics of request-
2149 header fields if all parties in the communication recognize them to
2150 be request-header fields. Unrecognized header fields are treated as
2151 entity-header fields.
2152
2153 6 Response
2154
2155 After receiving and interpreting a request message, a server responds
2156 with an HTTP response message.
2157
2158 Response = Status-Line ; Section 6.1
2159 *(( general-header ; Section 4.5
2160 | response-header ; Section 6.2
2161 | entity-header ) CRLF) ; Section 7.1
2162 CRLF
2163 [ message-body ] ; Section 7.2
2164
2165 6.1 Status-Line
2166
2167 The first line of a Response message is the Status-Line, consisting
2168 of the protocol version followed by a numeric status code and its
2169 associated textual phrase, with each element separated by SP
2170 characters. No CR or LF is allowed except in the final CRLF sequence.
2171
2172 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
2173
2174 6.1.1 Status Code and Reason Phrase
2175
2176 The Status-Code element is a 3-digit integer result code of the
2177 attempt to understand and satisfy the request. These codes are fully
2178 defined in section 10. The Reason-Phrase is intended to give a short
2179 textual description of the Status-Code. The Status-Code is intended
2180 for use by automata and the Reason-Phrase is intended for the human
2181 user. The client is not required to examine or display the Reason-
2182 Phrase.
2183
2184
2185
2186 Fielding, et al. Standards Track [Page 39]
2187
2188 RFC 2616 HTTP/1.1 June 1999
2189
2190
2191 The first digit of the Status-Code defines the class of response. The
2192 last two digits do not have any categorization role. There are 5
2193 values for the first digit:
2194
2195 - 1xx: Informational - Request received, continuing process
2196
2197 - 2xx: Success - The action was successfully received,
2198 understood, and accepted
2199
2200 - 3xx: Redirection - Further action must be taken in order to
2201 complete the request
2202
2203 - 4xx: Client Error - The request contains bad syntax or cannot
2204 be fulfilled
2205
2206 - 5xx: Server Error - The server failed to fulfill an apparently
2207 valid request
2208
2209 The individual values of the numeric status codes defined for
2210 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
2211 presented below. The reason phrases listed here are only
2212 recommendations -- they MAY be replaced by local equivalents without
2213 affecting the protocol.
2214
2215 Status-Code =
2216 "100" ; Section 10.1.1: Continue
2217 | "101" ; Section 10.1.2: Switching Protocols
2218 | "200" ; Section 10.2.1: OK
2219 | "201" ; Section 10.2.2: Created
2220 | "202" ; Section 10.2.3: Accepted
2221 | "203" ; Section 10.2.4: Non-Authoritative Information
2222 | "204" ; Section 10.2.5: No Content
2223 | "205" ; Section 10.2.6: Reset Content
2224 | "206" ; Section 10.2.7: Partial Content
2225 | "300" ; Section 10.3.1: Multiple Choices
2226 | "301" ; Section 10.3.2: Moved Permanently
2227 | "302" ; Section 10.3.3: Found
2228 | "303" ; Section 10.3.4: See Other
2229 | "304" ; Section 10.3.5: Not Modified
2230 | "305" ; Section 10.3.6: Use Proxy
2231 | "307" ; Section 10.3.8: Temporary Redirect
2232 | "400" ; Section 10.4.1: Bad Request
2233 | "401" ; Section 10.4.2: Unauthorized
2234 | "402" ; Section 10.4.3: Payment Required
2235 | "403" ; Section 10.4.4: Forbidden
2236 | "404" ; Section 10.4.5: Not Found
2237 | "405" ; Section 10.4.6: Method Not Allowed
2238 | "406" ; Section 10.4.7: Not Acceptable
2239
2240
2241
2242 Fielding, et al. Standards Track [Page 40]
2243
2244 RFC 2616 HTTP/1.1 June 1999
2245
2246
2247 | "407" ; Section 10.4.8: Proxy Authentication Required
2248 | "408" ; Section 10.4.9: Request Time-out
2249 | "409" ; Section 10.4.10: Conflict
2250 | "410" ; Section 10.4.11: Gone
2251 | "411" ; Section 10.4.12: Length Required
2252 | "412" ; Section 10.4.13: Precondition Failed
2253 | "413" ; Section 10.4.14: Request Entity Too Large
2254 | "414" ; Section 10.4.15: Request-URI Too Large
2255 | "415" ; Section 10.4.16: Unsupported Media Type
2256 | "416" ; Section 10.4.17: Requested range not satisfiable
2257 | "417" ; Section 10.4.18: Expectation Failed
2258 | "500" ; Section 10.5.1: Internal Server Error
2259 | "501" ; Section 10.5.2: Not Implemented
2260 | "502" ; Section 10.5.3: Bad Gateway
2261 | "503" ; Section 10.5.4: Service Unavailable
2262 | "504" ; Section 10.5.5: Gateway Time-out
2263 | "505" ; Section 10.5.6: HTTP Version not supported
2264 | extension-code
2265
2266 extension-code = 3DIGIT
2267 Reason-Phrase = *<TEXT, excluding CR, LF>
2268
2269 HTTP status codes are extensible. HTTP applications are not required
2270 to understand the meaning of all registered status codes, though such
2271 understanding is obviously desirable. However, applications MUST
2272 understand the class of any status code, as indicated by the first
2273 digit, and treat any unrecognized response as being equivalent to the
2274 x00 status code of that class, with the exception that an
2275 unrecognized response MUST NOT be cached. For example, if an
2276 unrecognized status code of 431 is received by the client, it can
2277 safely assume that there was something wrong with its request and
2278 treat the response as if it had received a 400 status code. In such
2279 cases, user agents SHOULD present to the user the entity returned
2280 with the response, since that entity is likely to include human-
2281 readable information which will explain the unusual status.
2282
2283 6.2 Response Header Fields
2284
2285 The response-header fields allow the server to pass additional
2286 information about the response which cannot be placed in the Status-
2287 Line. These header fields give information about the server and about
2288 further access to the resource identified by the Request-URI.
2289
2290 response-header = Accept-Ranges ; Section 14.5
2291 | Age ; Section 14.6
2292 | ETag ; Section 14.19
2293 | Location ; Section 14.30
2294 | Proxy-Authenticate ; Section 14.33
2295
2296
2297
2298 Fielding, et al. Standards Track [Page 41]
2299
2300 RFC 2616 HTTP/1.1 June 1999
2301
2302
2303 | Retry-After ; Section 14.37
2304 | Server ; Section 14.38
2305 | Vary ; Section 14.44
2306 | WWW-Authenticate ; Section 14.47
2307
2308 Response-header field names can be extended reliably only in
2309 combination with a change in the protocol version. However, new or
2310 experimental header fields MAY be given the semantics of response-
2311 header fields if all parties in the communication recognize them to
2312 be response-header fields. Unrecognized header fields are treated as
2313 entity-header fields.
2314
2315 7 Entity
2316
2317 Request and Response messages MAY transfer an entity if not otherwise
2318 restricted by the request method or response status code. An entity
2319 consists of entity-header fields and an entity-body, although some
2320 responses will only include the entity-headers.
2321
2322 In this section, both sender and recipient refer to either the client
2323 or the server, depending on who sends and who receives the entity.
2324
2325 7.1 Entity Header Fields
2326
2327 Entity-header fields define metainformation about the entity-body or,
2328 if no body is present, about the resource identified by the request.
2329 Some of this metainformation is OPTIONAL; some might be REQUIRED by
2330 portions of this specification.
2331
2332 entity-header = Allow ; Section 14.7
2333 | Content-Encoding ; Section 14.11
2334 | Content-Language ; Section 14.12
2335 | Content-Length ; Section 14.13
2336 | Content-Location ; Section 14.14
2337 | Content-MD5 ; Section 14.15
2338 | Content-Range ; Section 14.16
2339 | Content-Type ; Section 14.17
2340 | Expires ; Section 14.21
2341 | Last-Modified ; Section 14.29
2342 | extension-header
2343
2344 extension-header = message-header
2345
2346 The extension-header mechanism allows additional entity-header fields
2347 to be defined without changing the protocol, but these fields cannot
2348 be assumed to be recognizable by the recipient. Unrecognized header
2349 fields SHOULD be ignored by the recipient and MUST be forwarded by
2350 transparent proxies.
2351
2352
2353
2354 Fielding, et al. Standards Track [Page 42]
2355
2356 RFC 2616 HTTP/1.1 June 1999
2357
2358
2359 7.2 Entity Body
2360
2361 The entity-body (if any) sent with an HTTP request or response is in
2362 a format and encoding defined by the entity-header fields.
2363
2364 entity-body = *OCTET
2365
2366 An entity-body is only present in a message when a message-body is
2367 present, as described in section 4.3. The entity-body is obtained
2368 from the message-body by decoding any Transfer-Encoding that might
2369 have been applied to ensure safe and proper transfer of the message.
2370
2371 7.2.1 Type
2372
2373 When an entity-body is included with a message, the data type of that
2374 body is determined via the header fields Content-Type and Content-
2375 Encoding. These define a two-layer, ordered encoding model:
2376
2377 entity-body := Content-Encoding( Content-Type( data ) )
2378
2379 Content-Type specifies the media type of the underlying data.
2380 Content-Encoding may be used to indicate any additional content
2381 codings applied to the data, usually for the purpose of data
2382 compression, that are a property of the requested resource. There is
2383 no default encoding.
2384
2385 Any HTTP/1.1 message containing an entity-body SHOULD include a
2386 Content-Type header field defining the media type of that body. If
2387 and only if the media type is not given by a Content-Type field, the
2388 recipient MAY attempt to guess the media type via inspection of its
2389 content and/or the name extension(s) of the URI used to identify the
2390 resource. If the media type remains unknown, the recipient SHOULD
2391 treat it as type "application/octet-stream".
2392
2393 7.2.2 Entity Length
2394
2395 The entity-length of a message is the length of the message-body
2396 before any transfer-codings have been applied. Section 4.4 defines
2397 how the transfer-length of a message-body is determined.
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410 Fielding, et al. Standards Track [Page 43]
2411
2412 RFC 2616 HTTP/1.1 June 1999
2413
2414
2415 8 Connections
2416
2417 8.1 Persistent Connections
2418
2419 8.1.1 Purpose
2420
2421 Prior to persistent connections, a separate TCP connection was
2422 established to fetch each URL, increasing the load on HTTP servers
2423 and causing congestion on the Internet. The use of inline images and
2424 other associated data often require a client to make multiple
2425 requests of the same server in a short amount of time. Analysis of
2426 these performance problems and results from a prototype
2427 implementation are available [26] [30]. Implementation experience and
2428 measurements of actual HTTP/1.1 (RFC 2068) implementations show good
2429 results [39]. Alternatives have also been explored, for example,
2430 T/TCP [27].
2431
2432 Persistent HTTP connections have a number of advantages:
2433
2434 - By opening and closing fewer TCP connections, CPU time is saved
2435 in routers and hosts (clients, servers, proxies, gateways,
2436 tunnels, or caches), and memory used for TCP protocol control
2437 blocks can be saved in hosts.
2438
2439 - HTTP requests and responses can be pipelined on a connection.
2440 Pipelining allows a client to make multiple requests without
2441 waiting for each response, allowing a single TCP connection to
2442 be used much more efficiently, with much lower elapsed time.
2443
2444 - Network congestion is reduced by reducing the number of packets
2445 caused by TCP opens, and by allowing TCP sufficient time to
2446 determine the congestion state of the network.
2447
2448 - Latency on subsequent requests is reduced since there is no time
2449 spent in TCP's connection opening handshake.
2450
2451 - HTTP can evolve more gracefully, since errors can be reported
2452 without the penalty of closing the TCP connection. Clients using
2453 future versions of HTTP might optimistically try a new feature,
2454 but if communicating with an older server, retry with old
2455 semantics after an error is reported.
2456
2457 HTTP implementations SHOULD implement persistent connections.
2458
2459
2460
2461
2462
2463
2464
2465
2466 Fielding, et al. Standards Track [Page 44]
2467
2468 RFC 2616 HTTP/1.1 June 1999
2469
2470
2471 8.1.2 Overall Operation
2472
2473 A significant difference between HTTP/1.1 and earlier versions of
2474 HTTP is that persistent connections are the default behavior of any
2475 HTTP connection. That is, unless otherwise indicated, the client
2476 SHOULD assume that the server will maintain a persistent connection,
2477 even after error responses from the server.
2478
2479 Persistent connections provide a mechanism by which a client and a
2480 server can signal the close of a TCP connection. This signaling takes
2481 place using the Connection header field (section 14.10). Once a close
2482 has been signaled, the client MUST NOT send any more requests on that
2483 connection.
2484
2485 8.1.2.1 Negotiation
2486
2487 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2488 maintain a persistent connection unless a Connection header including
2489 the connection-token "close" was sent in the request. If the server
2490 chooses to close the connection immediately after sending the
2491 response, it SHOULD send a Connection header including the
2492 connection-token close.
2493
2494 An HTTP/1.1 client MAY expect a connection to remain open, but would
2495 decide to keep it open based on whether the response from a server
2496 contains a Connection header with the connection-token close. In case
2497 the client does not want to maintain a connection for more than that
2498 request, it SHOULD send a Connection header including the
2499 connection-token close.
2500
2501 If either the client or the server sends the close token in the
2502 Connection header, that request becomes the last one for the
2503 connection.
2504
2505 Clients and servers SHOULD NOT assume that a persistent connection is
2506 maintained for HTTP versions less than 1.1 unless it is explicitly
2507 signaled. See section 19.6.2 for more information on backward
2508 compatibility with HTTP/1.0 clients.
2509
2510 In order to remain persistent, all messages on the connection MUST
2511 have a self-defined message length (i.e., one not defined by closure
2512 of the connection), as described in section 4.4.
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522 Fielding, et al. Standards Track [Page 45]
2523
2524 RFC 2616 HTTP/1.1 June 1999
2525
2526
2527 8.1.2.2 Pipelining
2528
2529 A client that supports persistent connections MAY "pipeline" its
2530 requests (i.e., send multiple requests without waiting for each
2531 response). A server MUST send its responses to those requests in the
2532 same order that the requests were received.
2533
2534 Clients which assume persistent connections and pipeline immediately
2535 after connection establishment SHOULD be prepared to retry their
2536 connection if the first pipelined attempt fails. If a client does
2537 such a retry, it MUST NOT pipeline before it knows the connection is
2538 persistent. Clients MUST also be prepared to resend their requests if
2539 the server closes the connection before sending all of the
2540 corresponding responses.
2541
2542 Clients SHOULD NOT pipeline requests using non-idempotent methods or
2543 non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
2544 premature termination of the transport connection could lead to
2545 indeterminate results. A client wishing to send a non-idempotent
2546 request SHOULD wait to send that request until it has received the
2547 response status for the previous request.
2548
2549 8.1.3 Proxy Servers
2550
2551 It is especially important that proxies correctly implement the
2552 properties of the Connection header field as specified in section
2553 14.10.
2554
2555 The proxy server MUST signal persistent connections separately with
2556 its clients and the origin servers (or other proxy servers) that it
2557 connects to. Each persistent connection applies to only one transport
2558 link.
2559
2560 A proxy server MUST NOT establish a HTTP/1.1 persistent connection
2561 with an HTTP/1.0 client (but see RFC 2068 [33] for information and
2562 discussion of the problems with the Keep-Alive header implemented by
2563 many HTTP/1.0 clients).
2564
2565 8.1.4 Practical Considerations
2566
2567 Servers will usually have some time-out value beyond which they will
2568 no longer maintain an inactive connection. Proxy servers might make
2569 this a higher value since it is likely that the client will be making
2570 more connections through the same server. The use of persistent
2571 connections places no requirements on the length (or existence) of
2572 this time-out for either the client or the server.
2573
2574
2575
2576
2577
2578 Fielding, et al. Standards Track [Page 46]
2579
2580 RFC 2616 HTTP/1.1 June 1999
2581
2582
2583 When a client or server wishes to time-out it SHOULD issue a graceful
2584 close on the transport connection. Clients and servers SHOULD both
2585 constantly watch for the other side of the transport close, and
2586 respond to it as appropriate. If a client or server does not detect
2587 the other side's close promptly it could cause unnecessary resource
2588 drain on the network.
2589
2590 A client, server, or proxy MAY close the transport connection at any
2591 time. For example, a client might have started to send a new request
2592 at the same time that the server has decided to close the "idle"
2593 connection. From the server's point of view, the connection is being
2594 closed while it was idle, but from the client's point of view, a
2595 request is in progress.
2596
2597 This means that clients, servers, and proxies MUST be able to recover
2598 from asynchronous close events. Client software SHOULD reopen the
2599 transport connection and retransmit the aborted sequence of requests
2600 without user interaction so long as the request sequence is
2601 idempotent (see section 9.1.2). Non-idempotent methods or sequences
2602 MUST NOT be automatically retried, although user agents MAY offer a
2603 human operator the choice of retrying the request(s). Confirmation by
2604 user-agent software with semantic understanding of the application
2605 MAY substitute for user confirmation. The automatic retry SHOULD NOT
2606 be repeated if the second sequence of requests fails.
2607
2608 Servers SHOULD always respond to at least one request per connection,
2609 if at all possible. Servers SHOULD NOT close a connection in the
2610 middle of transmitting a response, unless a network or client failure
2611 is suspected.
2612
2613 Clients that use persistent connections SHOULD limit the number of
2614 simultaneous connections that they maintain to a given server. A
2615 single-user client SHOULD NOT maintain more than 2 connections with
2616 any server or proxy. A proxy SHOULD use up to 2*N connections to
2617 another server or proxy, where N is the number of simultaneously
2618 active users. These guidelines are intended to improve HTTP response
2619 times and avoid congestion.
2620
2621 8.2 Message Transmission Requirements
2622
2623 8.2.1 Persistent Connections and Flow Control
2624
2625 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
2626 flow control mechanisms to resolve temporary overloads, rather than
2627 terminating connections with the expectation that clients will retry.
2628 The latter technique can exacerbate network congestion.
2629
2630
2631
2632
2633
2634 Fielding, et al. Standards Track [Page 47]
2635
2636 RFC 2616 HTTP/1.1 June 1999
2637
2638
2639 8.2.2 Monitoring Connections for Error Status Messages
2640
2641 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
2642 the network connection for an error status while it is transmitting
2643 the request. If the client sees an error status, it SHOULD
2644 immediately cease transmitting the body. If the body is being sent
2645 using a "chunked" encoding (section 3.6), a zero length chunk and
2646 empty trailer MAY be used to prematurely mark the end of the message.
2647 If the body was preceded by a Content-Length header, the client MUST
2648 close the connection.
2649
2650 8.2.3 Use of the 100 (Continue) Status
2651
2652 The purpose of the 100 (Continue) status (see section 10.1.1) is to
2653 allow a client that is sending a request message with a request body
2654 to determine if the origin server is willing to accept the request
2655 (based on the request headers) before the client sends the request
2656 body. In some cases, it might either be inappropriate or highly
2657 inefficient for the client to send the body if the server will reject
2658 the message without looking at the body.
2659
2660 Requirements for HTTP/1.1 clients:
2661
2662 - If a client will wait for a 100 (Continue) response before
2663 sending the request body, it MUST send an Expect request-header
2664 field (section 14.20) with the "100-continue" expectation.
2665
2666 - A client MUST NOT send an Expect request-header field (section
2667 14.20) with the "100-continue" expectation if it does not intend
2668 to send a request body.
2669
2670 Because of the presence of older implementations, the protocol allows
2671 ambiguous situations in which a client may send "Expect: 100-
2672 continue" without receiving either a 417 (Expectation Failed) status
2673 or a 100 (Continue) status. Therefore, when a client sends this
2674 header field to an origin server (possibly via a proxy) from which it
2675 has never seen a 100 (Continue) status, the client SHOULD NOT wait
2676 for an indefinite period before sending the request body.
2677
2678 Requirements for HTTP/1.1 origin servers:
2679
2680 - Upon receiving a request which includes an Expect request-header
2681 field with the "100-continue" expectation, an origin server MUST
2682 either respond with 100 (Continue) status and continue to read
2683 from the input stream, or respond with a final status code. The
2684 origin server MUST NOT wait for the request body before sending
2685 the 100 (Continue) response. If it responds with a final status
2686 code, it MAY close the transport connection or it MAY continue
2687
2688
2689
2690 Fielding, et al. Standards Track [Page 48]
2691
2692 RFC 2616 HTTP/1.1 June 1999
2693
2694
2695 to read and discard the rest of the request. It MUST NOT
2696 perform the requested method if it returns a final status code.
2697
2698 - An origin server SHOULD NOT send a 100 (Continue) response if
2699 the request message does not include an Expect request-header
2700 field with the "100-continue" expectation, and MUST NOT send a
2701 100 (Continue) response if such a request comes from an HTTP/1.0
2702 (or earlier) client. There is an exception to this rule: for
2703 compatibility with RFC 2068, a server MAY send a 100 (Continue)
2704 status in response to an HTTP/1.1 PUT or POST request that does
2705 not include an Expect request-header field with the "100-
2706 continue" expectation. This exception, the purpose of which is
2707 to minimize any client processing delays associated with an
2708 undeclared wait for 100 (Continue) status, applies only to
2709 HTTP/1.1 requests, and not to requests with any other HTTP-
2710 version value.
2711
2712 - An origin server MAY omit a 100 (Continue) response if it has
2713 already received some or all of the request body for the
2714 corresponding request.
2715
2716 - An origin server that sends a 100 (Continue) response MUST
2717 ultimately send a final status code, once the request body is
2718 received and processed, unless it terminates the transport
2719 connection prematurely.
2720
2721 - If an origin server receives a request that does not include an
2722 Expect request-header field with the "100-continue" expectation,
2723 the request includes a request body, and the server responds
2724 with a final status code before reading the entire request body
2725 from the transport connection, then the server SHOULD NOT close
2726 the transport connection until it has read the entire request,
2727 or until the client closes the connection. Otherwise, the client
2728 might not reliably receive the response message. However, this
2729 requirement is not be construed as preventing a server from
2730 defending itself against denial-of-service attacks, or from
2731 badly broken client implementations.
2732
2733 Requirements for HTTP/1.1 proxies:
2734
2735 - If a proxy receives a request that includes an Expect request-
2736 header field with the "100-continue" expectation, and the proxy
2737 either knows that the next-hop server complies with HTTP/1.1 or
2738 higher, or does not know the HTTP version of the next-hop
2739 server, it MUST forward the request, including the Expect header
2740 field.
2741
2742
2743
2744
2745
2746 Fielding, et al. Standards Track [Page 49]
2747
2748 RFC 2616 HTTP/1.1 June 1999
2749
2750
2751 - If the proxy knows that the version of the next-hop server is
2752 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2753 respond with a 417 (Expectation Failed) status.
2754
2755 - Proxies SHOULD maintain a cache recording the HTTP version
2756 numbers received from recently-referenced next-hop servers.
2757
2758 - A proxy MUST NOT forward a 100 (Continue) response if the
2759 request message was received from an HTTP/1.0 (or earlier)
2760 client and did not include an Expect request-header field with
2761 the "100-continue" expectation. This requirement overrides the
2762 general rule for forwarding of 1xx responses (see section 10.1).
2763
2764 8.2.4 Client Behavior if Server Prematurely Closes Connection
2765
2766 If an HTTP/1.1 client sends a request which includes a request body,
2767 but which does not include an Expect request-header field with the
2768 "100-continue" expectation, and if the client is not directly
2769 connected to an HTTP/1.1 origin server, and if the client sees the
2770 connection close before receiving any status from the server, the
2771 client SHOULD retry the request. If the client does retry this
2772 request, it MAY use the following "binary exponential backoff"
2773 algorithm to be assured of obtaining a reliable response:
2774
2775 1. Initiate a new connection to the server
2776
2777 2. Transmit the request-headers
2778
2779 3. Initialize a variable R to the estimated round-trip time to the
2780 server (e.g., based on the time it took to establish the
2781 connection), or to a constant value of 5 seconds if the round-
2782 trip time is not available.
2783
2784 4. Compute T = R * (2**N), where N is the number of previous
2785 retries of this request.
2786
2787 5. Wait either for an error response from the server, or for T
2788 seconds (whichever comes first)
2789
2790 6. If no error response is received, after T seconds transmit the
2791 body of the request.
2792
2793 7. If client sees that the connection is closed prematurely,
2794 repeat from step 1 until the request is accepted, an error
2795 response is received, or the user becomes impatient and
2796 terminates the retry process.
2797
2798
2799
2800
2801
2802 Fielding, et al. Standards Track [Page 50]
2803
2804 RFC 2616 HTTP/1.1 June 1999
2805
2806
2807 If at any point an error status is received, the client
2808
2809 - SHOULD NOT continue and
2810
2811 - SHOULD close the connection if it has not completed sending the
2812 request message.
2813
2814 9 Method Definitions
2815
2816 The set of common methods for HTTP/1.1 is defined below. Although
2817 this set can be expanded, additional methods cannot be assumed to
2818 share the same semantics for separately extended clients and servers.
2819
2820 The Host request-header field (section 14.23) MUST accompany all
2821 HTTP/1.1 requests.
2822
2823 9.1 Safe and Idempotent Methods
2824
2825 9.1.1 Safe Methods
2826
2827 Implementors should be aware that the software represents the user in
2828 their interactions over the Internet, and should be careful to allow
2829 the user to be aware of any actions they might take which may have an
2830 unexpected significance to themselves or others.
2831
2832 In particular, the convention has been established that the GET and
2833 HEAD methods SHOULD NOT have the significance of taking an action
2834 other than retrieval. These methods ought to be considered "safe".
2835 This allows user agents to represent other methods, such as POST, PUT
2836 and DELETE, in a special way, so that the user is made aware of the
2837 fact that a possibly unsafe action is being requested.
2838
2839 Naturally, it is not possible to ensure that the server does not
2840 generate side-effects as a result of performing a GET request; in
2841 fact, some dynamic resources consider that a feature. The important
2842 distinction here is that the user did not request the side-effects,
2843 so therefore cannot be held accountable for them.
2844
2845 9.1.2 Idempotent Methods
2846
2847 Methods can also have the property of "idempotence" in that (aside
2848 from error or expiration issues) the side-effects of N > 0 identical
2849 requests is the same as for a single request. The methods GET, HEAD,
2850 PUT and DELETE share this property. Also, the methods OPTIONS and
2851 TRACE SHOULD NOT have side effects, and so are inherently idempotent.
2852
2853
2854
2855
2856
2857
2858 Fielding, et al. Standards Track [Page 51]
2859
2860 RFC 2616 HTTP/1.1 June 1999
2861
2862
2863 However, it is possible that a sequence of several requests is non-
2864 idempotent, even if all of the methods executed in that sequence are
2865 idempotent. (A sequence is idempotent if a single execution of the
2866 entire sequence always yields a result that is not changed by a
2867 reexecution of all, or part, of that sequence.) For example, a
2868 sequence is non-idempotent if its result depends on a value that is
2869 later modified in the same sequence.
2870
2871 A sequence that never has side effects is idempotent, by definition
2872 (provided that no concurrent operations are being executed on the
2873 same set of resources).
2874
2875 9.2 OPTIONS
2876
2877 The OPTIONS method represents a request for information about the
2878 communication options available on the request/response chain
2879 identified by the Request-URI. This method allows the client to
2880 determine the options and/or requirements associated with a resource,
2881 or the capabilities of a server, without implying a resource action
2882 or initiating a resource retrieval.
2883
2884 Responses to this method are not cacheable.
2885
2886 If the OPTIONS request includes an entity-body (as indicated by the
2887 presence of Content-Length or Transfer-Encoding), then the media type
2888 MUST be indicated by a Content-Type field. Although this
2889 specification does not define any use for such a body, future
2890 extensions to HTTP might use the OPTIONS body to make more detailed
2891 queries on the server. A server that does not support such an
2892 extension MAY discard the request body.
2893
2894 If the Request-URI is an asterisk ("*"), the OPTIONS request is
2895 intended to apply to the server in general rather than to a specific
2896 resource. Since a server's communication options typically depend on
2897 the resource, the "*" request is only useful as a "ping" or "no-op"
2898 type of method; it does nothing beyond allowing the client to test
2899 the capabilities of the server. For example, this can be used to test
2900 a proxy for HTTP/1.1 compliance (or lack thereof).
2901
2902 If the Request-URI is not an asterisk, the OPTIONS request applies
2903 only to the options that are available when communicating with that
2904 resource.
2905
2906 A 200 response SHOULD include any header fields that indicate
2907 optional features implemented by the server and applicable to that
2908 resource (e.g., Allow), possibly including extensions not defined by
2909 this specification. The response body, if any, SHOULD also include
2910 information about the communication options. The format for such a
2911
2912
2913
2914 Fielding, et al. Standards Track [Page 52]
2915
2916 RFC 2616 HTTP/1.1 June 1999
2917
2918
2919 body is not defined by this specification, but might be defined by
2920 future extensions to HTTP. Content negotiation MAY be used to select
2921 the appropriate response format. If no response body is included, the
2922 response MUST include a Content-Length field with a field-value of
2923 "0".
2924
2925 The Max-Forwards request-header field MAY be used to target a
2926 specific proxy in the request chain. When a proxy receives an OPTIONS
2927 request on an absoluteURI for which request forwarding is permitted,
2928 the proxy MUST check for a Max-Forwards field. If the Max-Forwards
2929 field-value is zero ("0"), the proxy MUST NOT forward the message;
2930 instead, the proxy SHOULD respond with its own communication options.
2931 If the Max-Forwards field-value is an integer greater than zero, the
2932 proxy MUST decrement the field-value when it forwards the request. If
2933 no Max-Forwards field is present in the request, then the forwarded
2934 request MUST NOT include a Max-Forwards field.
2935
2936 9.3 GET
2937
2938 The GET method means retrieve whatever information (in the form of an
2939 entity) is identified by the Request-URI. If the Request-URI refers
2940 to a data-producing process, it is the produced data which shall be
2941 returned as the entity in the response and not the source text of the
2942 process, unless that text happens to be the output of the process.
2943
2944 The semantics of the GET method change to a "conditional GET" if the
2945 request message includes an If-Modified-Since, If-Unmodified-Since,
2946 If-Match, If-None-Match, or If-Range header field. A conditional GET
2947 method requests that the entity be transferred only under the
2948 circumstances described by the conditional header field(s). The
2949 conditional GET method is intended to reduce unnecessary network
2950 usage by allowing cached entities to be refreshed without requiring
2951 multiple requests or transferring data already held by the client.
2952
2953 The semantics of the GET method change to a "partial GET" if the
2954 request message includes a Range header field. A partial GET requests
2955 that only part of the entity be transferred, as described in section
2956 14.35. The partial GET method is intended to reduce unnecessary
2957 network usage by allowing partially-retrieved entities to be
2958 completed without transferring data already held by the client.
2959
2960 The response to a GET request is cacheable if and only if it meets
2961 the requirements for HTTP caching described in section 13.
2962
2963 See section 15.1.3 for security considerations when used for forms.
2964
2965
2966
2967
2968
2969
2970 Fielding, et al. Standards Track [Page 53]
2971
2972 RFC 2616 HTTP/1.1 June 1999
2973
2974
2975 9.4 HEAD
2976
2977 The HEAD method is identical to GET except that the server MUST NOT
2978 return a message-body in the response. The metainformation contained
2979 in the HTTP headers in response to a HEAD request SHOULD be identical
2980 to the information sent in response to a GET request. This method can
2981 be used for obtaining metainformation about the entity implied by the
2982 request without transferring the entity-body itself. This method is
2983 often used for testing hypertext links for validity, accessibility,
2984 and recent modification.
2985
2986 The response to a HEAD request MAY be cacheable in the sense that the
2987 information contained in the response MAY be used to update a
2988 previously cached entity from that resource. If the new field values
2989 indicate that the cached entity differs from the current entity (as
2990 would be indicated by a change in Content-Length, Content-MD5, ETag
2991 or Last-Modified), then the cache MUST treat the cache entry as
2992 stale.
2993
2994 9.5 POST
2995
2996 The POST method is used to request that the origin server accept the
2997 entity enclosed in the request as a new subordinate of the resource
2998 identified by the Request-URI in the Request-Line. POST is designed
2999 to allow a uniform method to cover the following functions:
3000
3001 - Annotation of existing resources;
3002
3003 - Posting a message to a bulletin board, newsgroup, mailing list,
3004 or similar group of articles;
3005
3006 - Providing a block of data, such as the result of submitting a
3007 form, to a data-handling process;
3008
3009 - Extending a database through an append operation.
3010
3011 The actual function performed by the POST method is determined by the
3012 server and is usually dependent on the Request-URI. The posted entity
3013 is subordinate to that URI in the same way that a file is subordinate
3014 to a directory containing it, a news article is subordinate to a
3015 newsgroup to which it is posted, or a record is subordinate to a
3016 database.
3017
3018 The action performed by the POST method might not result in a
3019 resource that can be identified by a URI. In this case, either 200
3020 (OK) or 204 (No Content) is the appropriate response status,
3021 depending on whether or not the response includes an entity that
3022 describes the result.
3023
3024
3025
3026 Fielding, et al. Standards Track [Page 54]
3027
3028 RFC 2616 HTTP/1.1 June 1999
3029
3030
3031 If a resource has been created on the origin server, the response
3032 SHOULD be 201 (Created) and contain an entity which describes the
3033 status of the request and refers to the new resource, and a Location
3034 header (see section 14.30).
3035
3036 Responses to this method are not cacheable, unless the response
3037 includes appropriate Cache-Control or Expires header fields. However,
3038 the 303 (See Other) response can be used to direct the user agent to
3039 retrieve a cacheable resource.
3040
3041 POST requests MUST obey the message transmission requirements set out
3042 in section 8.2.
3043
3044 See section 15.1.3 for security considerations.
3045
3046 9.6 PUT
3047
3048 The PUT method requests that the enclosed entity be stored under the
3049 supplied Request-URI. If the Request-URI refers to an already
3050 existing resource, the enclosed entity SHOULD be considered as a
3051 modified version of the one residing on the origin server. If the
3052 Request-URI does not point to an existing resource, and that URI is
3053 capable of being defined as a new resource by the requesting user
3054 agent, the origin server can create the resource with that URI. If a
3055 new resource is created, the origin server MUST inform the user agent
3056 via the 201 (Created) response. If an existing resource is modified,
3057 either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
3058 to indicate successful completion of the request. If the resource
3059 could not be created or modified with the Request-URI, an appropriate
3060 error response SHOULD be given that reflects the nature of the
3061 problem. The recipient of the entity MUST NOT ignore any Content-*
3062 (e.g. Content-Range) headers that it does not understand or implement
3063 and MUST return a 501 (Not Implemented) response in such cases.
3064
3065 If the request passes through a cache and the Request-URI identifies
3066 one or more currently cached entities, those entries SHOULD be
3067 treated as stale. Responses to this method are not cacheable.
3068
3069 The fundamental difference between the POST and PUT requests is
3070 reflected in the different meaning of the Request-URI. The URI in a
3071 POST request identifies the resource that will handle the enclosed
3072 entity. That resource might be a data-accepting process, a gateway to
3073 some other protocol, or a separate entity that accepts annotations.
3074 In contrast, the URI in a PUT request identifies the entity enclosed
3075 with the request -- the user agent knows what URI is intended and the
3076 server MUST NOT attempt to apply the request to some other resource.
3077 If the server desires that the request be applied to a different URI,
3078
3079
3080
3081
3082 Fielding, et al. Standards Track [Page 55]
3083
3084 RFC 2616 HTTP/1.1 June 1999
3085
3086
3087 it MUST send a 301 (Moved Permanently) response; the user agent MAY
3088 then make its own decision regarding whether or not to redirect the
3089 request.
3090
3091 A single resource MAY be identified by many different URIs. For
3092 example, an article might have a URI for identifying "the current
3093 version" which is separate from the URI identifying each particular
3094 version. In this case, a PUT request on a general URI might result in
3095 several other URIs being defined by the origin server.
3096
3097 HTTP/1.1 does not define how a PUT method affects the state of an
3098 origin server.
3099
3100 PUT requests MUST obey the message transmission requirements set out
3101 in section 8.2.
3102
3103 Unless otherwise specified for a particular entity-header, the
3104 entity-headers in the PUT request SHOULD be applied to the resource
3105 created or modified by the PUT.
3106
3107 9.7 DELETE
3108
3109 The DELETE method requests that the origin server delete the resource
3110 identified by the Request-URI. This method MAY be overridden by human
3111 intervention (or other means) on the origin server. The client cannot
3112 be guaranteed that the operation has been carried out, even if the
3113 status code returned from the origin server indicates that the action
3114 has been completed successfully. However, the server SHOULD NOT
3115 indicate success unless, at the time the response is given, it
3116 intends to delete the resource or move it to an inaccessible
3117 location.
3118
3119 A successful response SHOULD be 200 (OK) if the response includes an
3120 entity describing the status, 202 (Accepted) if the action has not
3121 yet been enacted, or 204 (No Content) if the action has been enacted
3122 but the response does not include an entity.
3123
3124 If the request passes through a cache and the Request-URI identifies
3125 one or more currently cached entities, those entries SHOULD be
3126 treated as stale. Responses to this method are not cacheable.
3127
3128 9.8 TRACE
3129
3130 The TRACE method is used to invoke a remote, application-layer loop-
3131 back of the request message. The final recipient of the request
3132 SHOULD reflect the message received back to the client as the
3133 entity-body of a 200 (OK) response. The final recipient is either the
3134
3135
3136
3137
3138 Fielding, et al. Standards Track [Page 56]
3139
3140 RFC 2616 HTTP/1.1 June 1999
3141
3142
3143 origin server or the first proxy or gateway to receive a Max-Forwards
3144 value of zero (0) in the request (see section 14.31). A TRACE request
3145 MUST NOT include an entity.
3146
3147 TRACE allows the client to see what is being received at the other
3148 end of the request chain and use that data for testing or diagnostic
3149 information. The value of the Via header field (section 14.45) is of
3150 particular interest, since it acts as a trace of the request chain.
3151 Use of the Max-Forwards header field allows the client to limit the
3152 length of the request chain, which is useful for testing a chain of
3153 proxies forwarding messages in an infinite loop.
3154
3155 If the request is valid, the response SHOULD contain the entire
3156 request message in the entity-body, with a Content-Type of
3157 "message/http". Responses to this method MUST NOT be cached.
3158
3159 9.9 CONNECT
3160
3161 This specification reserves the method name CONNECT for use with a
3162 proxy that can dynamically switch to being a tunnel (e.g. SSL
3163 tunneling [44]).
3164
3165 10 Status Code Definitions
3166
3167 Each Status-Code is described below, including a description of which
3168 method(s) it can follow and any metainformation required in the
3169 response.
3170
3171 10.1 Informational 1xx
3172
3173 This class of status code indicates a provisional response,
3174 consisting only of the Status-Line and optional headers, and is
3175 terminated by an empty line. There are no required headers for this
3176 class of status code. Since HTTP/1.0 did not define any 1xx status
3177 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
3178 except under experimental conditions.
3179
3180 A client MUST be prepared to accept one or more 1xx status responses
3181 prior to a regular response, even if the client does not expect a 100
3182 (Continue) status message. Unexpected 1xx status responses MAY be
3183 ignored by a user agent.
3184
3185 Proxies MUST forward 1xx responses, unless the connection between the
3186 proxy and its client has been closed, or unless the proxy itself
3187 requested the generation of the 1xx response. (For example, if a
3188
3189
3190
3191
3192
3193
3194 Fielding, et al. Standards Track [Page 57]
3195
3196 RFC 2616 HTTP/1.1 June 1999
3197
3198
3199 proxy adds a "Expect: 100-continue" field when it forwards a request,
3200 then it need not forward the corresponding 100 (Continue)
3201 response(s).)
3202
3203 10.1.1 100 Continue
3204
3205 The client SHOULD continue with its request. This interim response is
3206 used to inform the client that the initial part of the request has
3207 been received and has not yet been rejected by the server. The client
3208 SHOULD continue by sending the remainder of the request or, if the
3209 request has already been completed, ignore this response. The server
3210 MUST send a final response after the request has been completed. See
3211 section 8.2.3 for detailed discussion of the use and handling of this
3212 status code.
3213
3214 10.1.2 101 Switching Protocols
3215
3216 The server understands and is willing to comply with the client's
3217 request, via the Upgrade message header field (section 14.42), for a
3218 change in the application protocol being used on this connection. The
3219 server will switch protocols to those defined by the response's
3220 Upgrade header field immediately after the empty line which
3221 terminates the 101 response.
3222
3223 The protocol SHOULD be switched only when it is advantageous to do
3224 so. For example, switching to a newer version of HTTP is advantageous
3225 over older versions, and switching to a real-time, synchronous
3226 protocol might be advantageous when delivering resources that use
3227 such features.
3228
3229 10.2 Successful 2xx
3230
3231 This class of status code indicates that the client's request was
3232 successfully received, understood, and accepted.
3233
3234 10.2.1 200 OK
3235
3236 The request has succeeded. The information returned with the response
3237 is dependent on the method used in the request, for example:
3238
3239 GET an entity corresponding to the requested resource is sent in
3240 the response;
3241
3242 HEAD the entity-header fields corresponding to the requested
3243 resource are sent in the response without any message-body;
3244
3245 POST an entity describing or containing the result of the action;
3246
3247
3248
3249
3250 Fielding, et al. Standards Track [Page 58]
3251
3252 RFC 2616 HTTP/1.1 June 1999
3253
3254
3255 TRACE an entity containing the request message as received by the
3256 end server.
3257
3258 10.2.2 201 Created
3259
3260 The request has been fulfilled and resulted in a new resource being
3261 created. The newly created resource can be referenced by the URI(s)
3262 returned in the entity of the response, with the most specific URI
3263 for the resource given by a Location header field. The response
3264 SHOULD include an entity containing a list of resource
3265 characteristics and location(s) from which the user or user agent can
3266 choose the one most appropriate. The entity format is specified by
3267 the media type given in the Content-Type header field. The origin
3268 server MUST create the resource before returning the 201 status code.
3269 If the action cannot be carried out immediately, the server SHOULD
3270 respond with 202 (Accepted) response instead.
3271
3272 A 201 response MAY contain an ETag response header field indicating
3273 the current value of the entity tag for the requested variant just
3274 created, see section 14.19.
3275
3276 10.2.3 202 Accepted
3277
3278 The request has been accepted for processing, but the processing has
3279 not been completed. The request might or might not eventually be
3280 acted upon, as it might be disallowed when processing actually takes
3281 place. There is no facility for re-sending a status code from an
3282 asynchronous operation such as this.
3283
3284 The 202 response is intentionally non-committal. Its purpose is to
3285 allow a server to accept a request for some other process (perhaps a
3286 batch-oriented process that is only run once per day) without
3287 requiring that the user agent's connection to the server persist
3288 until the process is completed. The entity returned with this
3289 response SHOULD include an indication of the request's current status
3290 and either a pointer to a status monitor or some estimate of when the
3291 user can expect the request to be fulfilled.
3292
3293 10.2.4 203 Non-Authoritative Information
3294
3295 The returned metainformation in the entity-header is not the
3296 definitive set as available from the origin server, but is gathered
3297 from a local or a third-party copy. The set presented MAY be a subset
3298 or superset of the original version. For example, including local
3299 annotation information about the resource might result in a superset
3300 of the metainformation known by the origin server. Use of this
3301 response code is not required and is only appropriate when the
3302 response would otherwise be 200 (OK).
3303
3304
3305
3306 Fielding, et al. Standards Track [Page 59]
3307
3308 RFC 2616 HTTP/1.1 June 1999
3309
3310
3311 10.2.5 204 No Content
3312
3313 The server has fulfilled the request but does not need to return an
3314 entity-body, and might want to return updated metainformation. The
3315 response MAY include new or updated metainformation in the form of
3316 entity-headers, which if present SHOULD be associated with the
3317 requested variant.
3318
3319 If the client is a user agent, it SHOULD NOT change its document view
3320 from that which caused the request to be sent. This response is
3321 primarily intended to allow input for actions to take place without
3322 causing a change to the user agent's active document view, although
3323 any new or updated metainformation SHOULD be applied to the document
3324 currently in the user agent's active view.
3325
3326 The 204 response MUST NOT include a message-body, and thus is always
3327 terminated by the first empty line after the header fields.
3328
3329 10.2.6 205 Reset Content
3330
3331 The server has fulfilled the request and the user agent SHOULD reset
3332 the document view which caused the request to be sent. This response
3333 is primarily intended to allow input for actions to take place via
3334 user input, followed by a clearing of the form in which the input is
3335 given so that the user can easily initiate another input action. The
3336 response MUST NOT include an entity.
3337
3338 10.2.7 206 Partial Content
3339
3340 The server has fulfilled the partial GET request for the resource.
3341 The request MUST have included a Range header field (section 14.35)
3342 indicating the desired range, and MAY have included an If-Range
3343 header field (section 14.27) to make the request conditional.
3344
3345 The response MUST include the following header fields:
3346
3347 - Either a Content-Range header field (section 14.16) indicating
3348 the range included with this response, or a multipart/byteranges
3349 Content-Type including Content-Range fields for each part. If a
3350 Content-Length header field is present in the response, its
3351 value MUST match the actual number of OCTETs transmitted in the
3352 message-body.
3353
3354 - Date
3355
3356 - ETag and/or Content-Location, if the header would have been sent
3357 in a 200 response to the same request
3358
3359
3360
3361
3362 Fielding, et al. Standards Track [Page 60]
3363
3364 RFC 2616 HTTP/1.1 June 1999
3365
3366
3367 - Expires, Cache-Control, and/or Vary, if the field-value might
3368 differ from that sent in any previous response for the same
3369 variant
3370
3371 If the 206 response is the result of an If-Range request that used a
3372 strong cache validator (see section 13.3.3), the response SHOULD NOT
3373 include other entity-headers. If the response is the result of an
3374 If-Range request that used a weak validator, the response MUST NOT
3375 include other entity-headers; this prevents inconsistencies between
3376 cached entity-bodies and updated headers. Otherwise, the response
3377 MUST include all of the entity-headers that would have been returned
3378 with a 200 (OK) response to the same request.
3379
3380 A cache MUST NOT combine a 206 response with other previously cached
3381 content if the ETag or Last-Modified headers do not match exactly,
3382 see 13.5.4.
3383
3384 A cache that does not support the Range and Content-Range headers
3385 MUST NOT cache 206 (Partial) responses.
3386
3387 10.3 Redirection 3xx
3388
3389 This class of status code indicates that further action needs to be
3390 taken by the user agent in order to fulfill the request. The action
3391 required MAY be carried out by the user agent without interaction
3392 with the user if and only if the method used in the second request is
3393 GET or HEAD. A client SHOULD detect infinite redirection loops, since
3394 such loops generate network traffic for each redirection.
3395
3396 Note: previous versions of this specification recommended a
3397 maximum of five redirections. Content developers should be aware
3398 that there might be clients that implement such a fixed
3399 limitation.
3400
3401 10.3.1 300 Multiple Choices
3402
3403 The requested resource corresponds to any one of a set of
3404 representations, each with its own specific location, and agent-
3405 driven negotiation information (section 12) is being provided so that
3406 the user (or user agent) can select a preferred representation and
3407 redirect its request to that location.
3408
3409 Unless it was a HEAD request, the response SHOULD include an entity
3410 containing a list of resource characteristics and location(s) from
3411 which the user or user agent can choose the one most appropriate. The
3412 entity format is specified by the media type given in the Content-
3413 Type header field. Depending upon the format and the capabilities of
3414
3415
3416
3417
3418 Fielding, et al. Standards Track [Page 61]
3419
3420 RFC 2616 HTTP/1.1 June 1999
3421
3422
3423 the user agent, selection of the most appropriate choice MAY be
3424 performed automatically. However, this specification does not define
3425 any standard for such automatic selection.
3426
3427 If the server has a preferred choice of representation, it SHOULD
3428 include the specific URI for that representation in the Location
3429 field; user agents MAY use the Location field value for automatic
3430 redirection. This response is cacheable unless indicated otherwise.
3431
3432 10.3.2 301 Moved Permanently
3433
3434 The requested resource has been assigned a new permanent URI and any
3435 future references to this resource SHOULD use one of the returned
3436 URIs. Clients with link editing capabilities ought to automatically
3437 re-link references to the Request-URI to one or more of the new
3438 references returned by the server, where possible. This response is
3439 cacheable unless indicated otherwise.
3440
3441 The new permanent URI SHOULD be given by the Location field in the
3442 response. Unless the request method was HEAD, the entity of the
3443 response SHOULD contain a short hypertext note with a hyperlink to
3444 the new URI(s).
3445
3446 If the 301 status code is received in response to a request other
3447 than GET or HEAD, the user agent MUST NOT automatically redirect the
3448 request unless it can be confirmed by the user, since this might
3449 change the conditions under which the request was issued.
3450
3451 Note: When automatically redirecting a POST request after
3452 receiving a 301 status code, some existing HTTP/1.0 user agents
3453 will erroneously change it into a GET request.
3454
3455 10.3.3 302 Found
3456
3457 The requested resource resides temporarily under a different URI.
3458 Since the redirection might be altered on occasion, the client SHOULD
3459 continue to use the Request-URI for future requests. This response
3460 is only cacheable if indicated by a Cache-Control or Expires header
3461 field.
3462
3463 The temporary URI SHOULD be given by the Location field in the
3464 response. Unless the request method was HEAD, the entity of the
3465 response SHOULD contain a short hypertext note with a hyperlink to
3466 the new URI(s).
3467
3468
3469
3470
3471
3472
3473
3474 Fielding, et al. Standards Track [Page 62]
3475
3476 RFC 2616 HTTP/1.1 June 1999
3477
3478
3479 If the 302 status code is received in response to a request other
3480 than GET or HEAD, the user agent MUST NOT automatically redirect the
3481 request unless it can be confirmed by the user, since this might
3482 change the conditions under which the request was issued.
3483
3484 Note: RFC 1945 and RFC 2068 specify that the client is not allowed
3485 to change the method on the redirected request. However, most
3486 existing user agent implementations treat 302 as if it were a 303
3487 response, performing a GET on the Location field-value regardless
3488 of the original request method. The status codes 303 and 307 have
3489 been added for servers that wish to make unambiguously clear which
3490 kind of reaction is expected of the client.
3491
3492 10.3.4 303 See Other
3493
3494 The response to the request can be found under a different URI and
3495 SHOULD be retrieved using a GET method on that resource. This method
3496 exists primarily to allow the output of a POST-activated script to
3497 redirect the user agent to a selected resource. The new URI is not a
3498 substitute reference for the originally requested resource. The 303
3499 response MUST NOT be cached, but the response to the second
3500 (redirected) request might be cacheable.
3501
3502 The different URI SHOULD be given by the Location field in the
3503 response. Unless the request method was HEAD, the entity of the
3504 response SHOULD contain a short hypertext note with a hyperlink to
3505 the new URI(s).
3506
3507 Note: Many pre-HTTP/1.1 user agents do not understand the 303
3508 status. When interoperability with such clients is a concern, the
3509 302 status code may be used instead, since most user agents react
3510 to a 302 response as described here for 303.
3511
3512 10.3.5 304 Not Modified
3513
3514 If the client has performed a conditional GET request and access is
3515 allowed, but the document has not been modified, the server SHOULD
3516 respond with this status code. The 304 response MUST NOT contain a
3517 message-body, and thus is always terminated by the first empty line
3518 after the header fields.
3519
3520 The response MUST include the following header fields:
3521
3522 - Date, unless its omission is required by section 14.18.1
3523
3524
3525
3526
3527
3528
3529
3530 Fielding, et al. Standards Track [Page 63]
3531
3532 RFC 2616 HTTP/1.1 June 1999
3533
3534
3535 If a clockless origin server obeys these rules, and proxies and
3536 clients add their own Date to any response received without one (as
3537 already specified by [RFC 2068], section 14.19), caches will operate
3538 correctly.
3539
3540 - ETag and/or Content-Location, if the header would have been sent
3541 in a 200 response to the same request
3542
3543 - Expires, Cache-Control, and/or Vary, if the field-value might
3544 differ from that sent in any previous response for the same
3545 variant
3546
3547 If the conditional GET used a strong cache validator (see section
3548 13.3.3), the response SHOULD NOT include other entity-headers.
3549 Otherwise (i.e., the conditional GET used a weak validator), the
3550 response MUST NOT include other entity-headers; this prevents
3551 inconsistencies between cached entity-bodies and updated headers.
3552
3553 If a 304 response indicates an entity not currently cached, then the
3554 cache MUST disregard the response and repeat the request without the
3555 conditional.
3556
3557 If a cache uses a received 304 response to update a cache entry, the
3558 cache MUST update the entry to reflect any new field values given in
3559 the response.
3560
3561 10.3.6 305 Use Proxy
3562
3563 The requested resource MUST be accessed through the proxy given by
3564 the Location field. The Location field gives the URI of the proxy.
3565 The recipient is expected to repeat this single request via the
3566 proxy. 305 responses MUST only be generated by origin servers.
3567
3568 Note: RFC 2068 was not clear that 305 was intended to redirect a
3569 single request, and to be generated by origin servers only. Not
3570 observing these limitations has significant security consequences.
3571
3572 10.3.7 306 (Unused)
3573
3574 The 306 status code was used in a previous version of the
3575 specification, is no longer used, and the code is reserved.
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586 Fielding, et al. Standards Track [Page 64]
3587
3588 RFC 2616 HTTP/1.1 June 1999
3589
3590
3591 10.3.8 307 Temporary Redirect
3592
3593 The requested resource resides temporarily under a different URI.
3594 Since the redirection MAY be altered on occasion, the client SHOULD
3595 continue to use the Request-URI for future requests. This response
3596 is only cacheable if indicated by a Cache-Control or Expires header
3597 field.
3598
3599 The temporary URI SHOULD be given by the Location field in the
3600 response. Unless the request method was HEAD, the entity of the
3601 response SHOULD contain a short hypertext note with a hyperlink to
3602 the new URI(s) , since many pre-HTTP/1.1 user agents do not
3603 understand the 307 status. Therefore, the note SHOULD contain the
3604 information necessary for a user to repeat the original request on
3605 the new URI.
3606
3607 If the 307 status code is received in response to a request other
3608 than GET or HEAD, the user agent MUST NOT automatically redirect the
3609 request unless it can be confirmed by the user, since this might
3610 change the conditions under which the request was issued.
3611
3612 10.4 Client Error 4xx
3613
3614 The 4xx class of status code is intended for cases in which the
3615 client seems to have erred. Except when responding to a HEAD request,
3616 the server SHOULD include an entity containing an explanation of the
3617 error situation, and whether it is a temporary or permanent
3618 condition. These status codes are applicable to any request method.
3619 User agents SHOULD display any included entity to the user.
3620
3621 If the client is sending data, a server implementation using TCP
3622 SHOULD be careful to ensure that the client acknowledges receipt of
3623 the packet(s) containing the response, before the server closes the
3624 input connection. If the client continues sending data to the server
3625 after the close, the server's TCP stack will send a reset packet to
3626 the client, which may erase the client's unacknowledged input buffers
3627 before they can be read and interpreted by the HTTP application.
3628
3629 10.4.1 400 Bad Request
3630
3631 The request could not be understood by the server due to malformed
3632 syntax. The client SHOULD NOT repeat the request without
3633 modifications.
3634
3635
3636
3637
3638
3639
3640
3641
3642 Fielding, et al. Standards Track [Page 65]
3643
3644 RFC 2616 HTTP/1.1 June 1999
3645
3646
3647 10.4.2 401 Unauthorized
3648
3649 The request requires user authentication. The response MUST include a
3650 WWW-Authenticate header field (section 14.47) containing a challenge
3651 applicable to the requested resource. The client MAY repeat the
3652 request with a suitable Authorization header field (section 14.8). If
3653 the request already included Authorization credentials, then the 401
3654 response indicates that authorization has been refused for those
3655 credentials. If the 401 response contains the same challenge as the
3656 prior response, and the user agent has already attempted
3657 authentication at least once, then the user SHOULD be presented the
3658 entity that was given in the response, since that entity might
3659 include relevant diagnostic information. HTTP access authentication
3660 is explained in "HTTP Authentication: Basic and Digest Access
3661 Authentication" [43].
3662
3663 10.4.3 402 Payment Required
3664
3665 This code is reserved for future use.
3666
3667 10.4.4 403 Forbidden
3668
3669 The server understood the request, but is refusing to fulfill it.
3670 Authorization will not help and the request SHOULD NOT be repeated.
3671 If the request method was not HEAD and the server wishes to make
3672 public why the request has not been fulfilled, it SHOULD describe the
3673 reason for the refusal in the entity. If the server does not wish to
3674 make this information available to the client, the status code 404
3675 (Not Found) can be used instead.
3676
3677 10.4.5 404 Not Found
3678
3679 The server has not found anything matching the Request-URI. No
3680 indication is given of whether the condition is temporary or
3681 permanent. The 410 (Gone) status code SHOULD be used if the server
3682 knows, through some internally configurable mechanism, that an old
3683 resource is permanently unavailable and has no forwarding address.
3684 This status code is commonly used when the server does not wish to
3685 reveal exactly why the request has been refused, or when no other
3686 response is applicable.
3687
3688 10.4.6 405 Method Not Allowed
3689
3690 The method specified in the Request-Line is not allowed for the
3691 resource identified by the Request-URI. The response MUST include an
3692 Allow header containing a list of valid methods for the requested
3693 resource.
3694
3695
3696
3697
3698 Fielding, et al. Standards Track [Page 66]
3699
3700 RFC 2616 HTTP/1.1 June 1999
3701
3702
3703 10.4.7 406 Not Acceptable
3704
3705 The resource identified by the request is only capable of generating
3706 response entities which have content characteristics not acceptable
3707 according to the accept headers sent in the request.
3708
3709 Unless it was a HEAD request, the response SHOULD include an entity
3710 containing a list of available entity characteristics and location(s)
3711 from which the user or user agent can choose the one most
3712 appropriate. The entity format is specified by the media type given
3713 in the Content-Type header field. Depending upon the format and the
3714 capabilities of the user agent, selection of the most appropriate
3715 choice MAY be performed automatically. However, this specification
3716 does not define any standard for such automatic selection.
3717
3718 Note: HTTP/1.1 servers are allowed to return responses which are
3719 not acceptable according to the accept headers sent in the
3720 request. In some cases, this may even be preferable to sending a
3721 406 response. User agents are encouraged to inspect the headers of
3722 an incoming response to determine if it is acceptable.
3723
3724 If the response could be unacceptable, a user agent SHOULD
3725 temporarily stop receipt of more data and query the user for a
3726 decision on further actions.
3727
3728 10.4.8 407 Proxy Authentication Required
3729
3730 This code is similar to 401 (Unauthorized), but indicates that the
3731 client must first authenticate itself with the proxy. The proxy MUST
3732 return a Proxy-Authenticate header field (section 14.33) containing a
3733 challenge applicable to the proxy for the requested resource. The
3734 client MAY repeat the request with a suitable Proxy-Authorization
3735 header field (section 14.34). HTTP access authentication is explained
3736 in "HTTP Authentication: Basic and Digest Access Authentication"
3737 [43].
3738
3739 10.4.9 408 Request Timeout
3740
3741 The client did not produce a request within the time that the server
3742 was prepared to wait. The client MAY repeat the request without
3743 modifications at any later time.
3744
3745 10.4.10 409 Conflict
3746
3747 The request could not be completed due to a conflict with the current
3748 state of the resource. This code is only allowed in situations where
3749 it is expected that the user might be able to resolve the conflict
3750 and resubmit the request. The response body SHOULD include enough
3751
3752
3753
3754 Fielding, et al. Standards Track [Page 67]
3755
3756 RFC 2616 HTTP/1.1 June 1999
3757
3758
3759 information for the user to recognize the source of the conflict.
3760 Ideally, the response entity would include enough information for the
3761 user or user agent to fix the problem; however, that might not be
3762 possible and is not required.
3763
3764 Conflicts are most likely to occur in response to a PUT request. For
3765 example, if versioning were being used and the entity being PUT
3766 included changes to a resource which conflict with those made by an
3767 earlier (third-party) request, the server might use the 409 response
3768 to indicate that it can't complete the request. In this case, the
3769 response entity would likely contain a list of the differences
3770 between the two versions in a format defined by the response
3771 Content-Type.
3772
3773 10.4.11 410 Gone
3774
3775 The requested resource is no longer available at the server and no
3776 forwarding address is known. This condition is expected to be
3777 considered permanent. Clients with link editing capabilities SHOULD
3778 delete references to the Request-URI after user approval. If the
3779 server does not know, or has no facility to determine, whether or not
3780 the condition is permanent, the status code 404 (Not Found) SHOULD be
3781 used instead. This response is cacheable unless indicated otherwise.
3782
3783 The 410 response is primarily intended to assist the task of web
3784 maintenance by notifying the recipient that the resource is
3785 intentionally unavailable and that the server owners desire that
3786 remote links to that resource be removed. Such an event is common for
3787 limited-time, promotional services and for resources belonging to
3788 individuals no longer working at the server's site. It is not
3789 necessary to mark all permanently unavailable resources as "gone" or
3790 to keep the mark for any length of time -- that is left to the
3791 discretion of the server owner.
3792
3793 10.4.12 411 Length Required
3794
3795 The server refuses to accept the request without a defined Content-
3796 Length. The client MAY repeat the request if it adds a valid
3797 Content-Length header field containing the length of the message-body
3798 in the request message.
3799
3800 10.4.13 412 Precondition Failed
3801
3802 The precondition given in one or more of the request-header fields
3803 evaluated to false when it was tested on the server. This response
3804 code allows the client to place preconditions on the current resource
3805 metainformation (header field data) and thus prevent the requested
3806 method from being applied to a resource other than the one intended.
3807
3808
3809
3810 Fielding, et al. Standards Track [Page 68]
3811
3812 RFC 2616 HTTP/1.1 June 1999
3813
3814
3815 10.4.14 413 Request Entity Too Large
3816
3817 The server is refusing to process a request because the request
3818 entity is larger than the server is willing or able to process. The
3819 server MAY close the connection to prevent the client from continuing
3820 the request.
3821
3822 If the condition is temporary, the server SHOULD include a Retry-
3823 After header field to indicate that it is temporary and after what
3824 time the client MAY try again.
3825
3826 10.4.15 414 Request-URI Too Long
3827
3828 The server is refusing to service the request because the Request-URI
3829 is longer than the server is willing to interpret. This rare
3830 condition is only likely to occur when a client has improperly
3831 converted a POST request to a GET request with long query
3832 information, when the client has descended into a URI "black hole" of
3833 redirection (e.g., a redirected URI prefix that points to a suffix of
3834 itself), or when the server is under attack by a client attempting to
3835 exploit security holes present in some servers using fixed-length
3836 buffers for reading or manipulating the Request-URI.
3837
3838 10.4.16 415 Unsupported Media Type
3839
3840 The server is refusing to service the request because the entity of
3841 the request is in a format not supported by the requested resource
3842 for the requested method.
3843
3844 10.4.17 416 Requested Range Not Satisfiable
3845
3846 A server SHOULD return a response with this status code if a request
3847 included a Range request-header field (section 14.35), and none of
3848 the range-specifier values in this field overlap the current extent
3849 of the selected resource, and the request did not include an If-Range
3850 request-header field. (For byte-ranges, this means that the first-
3851 byte-pos of all of the byte-range-spec values were greater than the
3852 current length of the selected resource.)
3853
3854 When this status code is returned for a byte-range request, the
3855 response SHOULD include a Content-Range entity-header field
3856 specifying the current length of the selected resource (see section
3857 14.16). This response MUST NOT use the multipart/byteranges content-
3858 type.
3859
3860
3861
3862
3863
3864
3865
3866 Fielding, et al. Standards Track [Page 69]
3867
3868 RFC 2616 HTTP/1.1 June 1999
3869
3870
3871 10.4.18 417 Expectation Failed
3872
3873 The expectation given in an Expect request-header field (see section
3874 14.20) could not be met by this server, or, if the server is a proxy,
3875 the server has unambiguous evidence that the request could not be met
3876 by the next-hop server.
3877
3878 10.5 Server Error 5xx
3879
3880 Response status codes beginning with the digit "5" indicate cases in
3881 which the server is aware that it has erred or is incapable of
3882 performing the request. Except when responding to a HEAD request, the
3883 server SHOULD include an entity containing an explanation of the
3884 error situation, and whether it is a temporary or permanent
3885 condition. User agents SHOULD display any included entity to the
3886 user. These response codes are applicable to any request method.
3887
3888 10.5.1 500 Internal Server Error
3889
3890 The server encountered an unexpected condition which prevented it
3891 from fulfilling the request.
3892
3893 10.5.2 501 Not Implemented
3894
3895 The server does not support the functionality required to fulfill the
3896 request. This is the appropriate response when the server does not
3897 recognize the request method and is not capable of supporting it for
3898 any resource.
3899
3900 10.5.3 502 Bad Gateway
3901
3902 The server, while acting as a gateway or proxy, received an invalid
3903 response from the upstream server it accessed in attempting to
3904 fulfill the request.
3905
3906 10.5.4 503 Service Unavailable
3907
3908 The server is currently unable to handle the request due to a
3909 temporary overloading or maintenance of the server. The implication
3910 is that this is a temporary condition which will be alleviated after
3911 some delay. If known, the length of the delay MAY be indicated in a
3912 Retry-After header. If no Retry-After is given, the client SHOULD
3913 handle the response as it would for a 500 response.
3914
3915 Note: The existence of the 503 status code does not imply that a
3916 server must use it when becoming overloaded. Some servers may wish
3917 to simply refuse the connection.
3918
3919
3920
3921
3922 Fielding, et al. Standards Track [Page 70]
3923
3924 RFC 2616 HTTP/1.1 June 1999
3925
3926
3927 10.5.5 504 Gateway Timeout
3928
3929 The server, while acting as a gateway or proxy, did not receive a
3930 timely response from the upstream server specified by the URI (e.g.
3931 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
3932 to access in attempting to complete the request.
3933
3934 Note: Note to implementors: some deployed proxies are known to
3935 return 400 or 500 when DNS lookups time out.
3936
3937 10.5.6 505 HTTP Version Not Supported
3938
3939 The server does not support, or refuses to support, the HTTP protocol
3940 version that was used in the request message. The server is
3941 indicating that it is unable or unwilling to complete the request
3942 using the same major version as the client, as described in section
3943 3.1, other than with this error message. The response SHOULD contain
3944 an entity describing why that version is not supported and what other
3945 protocols are supported by that server.
3946
3947 11 Access Authentication
3948
3949 HTTP provides several OPTIONAL challenge-response authentication
3950 mechanisms which can be used by a server to challenge a client
3951 request and by a client to provide authentication information. The
3952 general framework for access authentication, and the specification of
3953 "basic" and "digest" authentication, are specified in "HTTP
3954 Authentication: Basic and Digest Access Authentication" [43]. This
3955 specification adopts the definitions of "challenge" and "credentials"
3956 from that specification.
3957
3958 12 Content Negotiation
3959
3960 Most HTTP responses include an entity which contains information for
3961 interpretation by a human user. Naturally, it is desirable to supply
3962 the user with the "best available" entity corresponding to the
3963 request. Unfortunately for servers and caches, not all users have the
3964 same preferences for what is "best," and not all user agents are
3965 equally capable of rendering all entity types. For that reason, HTTP
3966 has provisions for several mechanisms for "content negotiation" --
3967 the process of selecting the best representation for a given response
3968 when there are multiple representations available.
3969
3970 Note: This is not called "format negotiation" because the
3971 alternate representations may be of the same media type, but use
3972 different capabilities of that type, be in different languages,
3973 etc.
3974
3975
3976
3977
3978 Fielding, et al. Standards Track [Page 71]
3979
3980 RFC 2616 HTTP/1.1 June 1999
3981
3982
3983 Any response containing an entity-body MAY be subject to negotiation,
3984 including error responses.
3985
3986 There are two kinds of content negotiation which are possible in
3987 HTTP: server-driven and agent-driven negotiation. These two kinds of
3988 negotiation are orthogonal and thus may be used separately or in
3989 combination. One method of combination, referred to as transparent
3990 negotiation, occurs when a cache uses the agent-driven negotiation
3991 information provided by the origin server in order to provide
3992 server-driven negotiation for subsequent requests.
3993
3994 12.1 Server-driven Negotiation
3995
3996 If the selection of the best representation for a response is made by
3997 an algorithm located at the server, it is called server-driven
3998 negotiation. Selection is based on the available representations of
3999 the response (the dimensions over which it can vary; e.g. language,
4000 content-coding, etc.) and the contents of particular header fields in
4001 the request message or on other information pertaining to the request
4002 (such as the network address of the client).
4003
4004 Server-driven negotiation is advantageous when the algorithm for
4005 selecting from among the available representations is difficult to
4006 describe to the user agent, or when the server desires to send its
4007 "best guess" to the client along with the first response (hoping to
4008 avoid the round-trip delay of a subsequent request if the "best
4009 guess" is good enough for the user). In order to improve the server's
4010 guess, the user agent MAY include request header fields (Accept,
4011 Accept-Language, Accept-Encoding, etc.) which describe its
4012 preferences for such a response.
4013
4014 Server-driven negotiation has disadvantages:
4015
4016 1. It is impossible for the server to accurately determine what
4017 might be "best" for any given user, since that would require
4018 complete knowledge of both the capabilities of the user agent
4019 and the intended use for the response (e.g., does the user want
4020 to view it on screen or print it on paper?).
4021
4022 2. Having the user agent describe its capabilities in every
4023 request can be both very inefficient (given that only a small
4024 percentage of responses have multiple representations) and a
4025 potential violation of the user's privacy.
4026
4027 3. It complicates the implementation of an origin server and the
4028 algorithms for generating responses to a request.
4029
4030
4031
4032
4033
4034 Fielding, et al. Standards Track [Page 72]
4035
4036 RFC 2616 HTTP/1.1 June 1999
4037
4038
4039 4. It may limit a public cache's ability to use the same response
4040 for multiple user's requests.
4041
4042 HTTP/1.1 includes the following request-header fields for enabling
4043 server-driven negotiation through description of user agent
4044 capabilities and user preferences: Accept (section 14.1), Accept-
4045 Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
4046 Language (section 14.4), and User-Agent (section 14.43). However, an
4047 origin server is not limited to these dimensions and MAY vary the
4048 response based on any aspect of the request, including information
4049 outside the request-header fields or within extension header fields
4050 not defined by this specification.
4051
4052 The Vary header field can be used to express the parameters the
4053 server uses to select a representation that is subject to server-
4054 driven negotiation. See section 13.6 for use of the Vary header field
4055 by caches and section 14.44 for use of the Vary header field by
4056 servers.
4057
4058 12.2 Agent-driven Negotiation
4059
4060 With agent-driven negotiation, selection of the best representation
4061 for a response is performed by the user agent after receiving an
4062 initial response from the origin server. Selection is based on a list
4063 of the available representations of the response included within the
4064 header fields or entity-body of the initial response, with each
4065 representation identified by its own URI. Selection from among the
4066 representations may be performed automatically (if the user agent is
4067 capable of doing so) or manually by the user selecting from a
4068 generated (possibly hypertext) menu.
4069
4070 Agent-driven negotiation is advantageous when the response would vary
4071 over commonly-used dimensions (such as type, language, or encoding),
4072 when the origin server is unable to determine a user agent's
4073 capabilities from examining the request, and generally when public
4074 caches are used to distribute server load and reduce network usage.
4075
4076 Agent-driven negotiation suffers from the disadvantage of needing a
4077 second request to obtain the best alternate representation. This
4078 second request is only efficient when caching is used. In addition,
4079 this specification does not define any mechanism for supporting
4080 automatic selection, though it also does not prevent any such
4081 mechanism from being developed as an extension and used within
4082 HTTP/1.1.
4083
4084
4085
4086
4087
4088
4089
4090 Fielding, et al. Standards Track [Page 73]
4091
4092 RFC 2616 HTTP/1.1 June 1999
4093
4094
4095 HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
4096 status codes for enabling agent-driven negotiation when the server is
4097 unwilling or unable to provide a varying response using server-driven
4098 negotiation.
4099
4100 12.3 Transparent Negotiation
4101
4102 Transparent negotiation is a combination of both server-driven and
4103 agent-driven negotiation. When a cache is supplied with a form of the
4104 list of available representations of the response (as in agent-driven
4105 negotiation) and the dimensions of variance are completely understood
4106 by the cache, then the cache becomes capable of performing server-
4107 driven negotiation on behalf of the origin server for subsequent
4108 requests on that resource.
4109
4110 Transparent negotiation has the advantage of distributing the
4111 negotiation work that would otherwise be required of the origin
4112 server and also removing the second request delay of agent-driven
4113 negotiation when the cache is able to correctly guess the right
4114 response.
4115
4116 This specification does not define any mechanism for transparent
4117 negotiation, though it also does not prevent any such mechanism from
4118 being developed as an extension that could be used within HTTP/1.1.
4119
4120 13 Caching in HTTP
4121
4122 HTTP is typically used for distributed information systems, where
4123 performance can be improved by the use of response caches. The
4124 HTTP/1.1 protocol includes a number of elements intended to make
4125 caching work as well as possible. Because these elements are
4126 inextricable from other aspects of the protocol, and because they
4127 interact with each other, it is useful to describe the basic caching
4128 design of HTTP separately from the detailed descriptions of methods,
4129 headers, response codes, etc.
4130
4131 Caching would be useless if it did not significantly improve
4132 performance. The goal of caching in HTTP/1.1 is to eliminate the need
4133 to send requests in many cases, and to eliminate the need to send
4134 full responses in many other cases. The former reduces the number of
4135 network round-trips required for many operations; we use an
4136 "expiration" mechanism for this purpose (see section 13.2). The
4137 latter reduces network bandwidth requirements; we use a "validation"
4138 mechanism for this purpose (see section 13.3).
4139
4140 Requirements for performance, availability, and disconnected
4141 operation require us to be able to relax the goal of semantic
4142 transparency. The HTTP/1.1 protocol allows origin servers, caches,
4143
4144
4145
4146 Fielding, et al. Standards Track [Page 74]
4147
4148 RFC 2616 HTTP/1.1 June 1999
4149
4150
4151 and clients to explicitly reduce transparency when necessary.
4152 However, because non-transparent operation may confuse non-expert
4153 users, and might be incompatible with certain server applications
4154 (such as those for ordering merchandise), the protocol requires that
4155 transparency be relaxed
4156
4157 - only by an explicit protocol-level request when relaxed by
4158 client or origin server
4159
4160 - only with an explicit warning to the end user when relaxed by
4161 cache or client
4162
4163 Therefore, the HTTP/1.1 protocol provides these important elements:
4164
4165 1. Protocol features that provide full semantic transparency when
4166 this is required by all parties.
4167
4168 2. Protocol features that allow an origin server or user agent to
4169 explicitly request and control non-transparent operation.
4170
4171 3. Protocol features that allow a cache to attach warnings to
4172 responses that do not preserve the requested approximation of
4173 semantic transparency.
4174
4175 A basic principle is that it must be possible for the clients to
4176 detect any potential relaxation of semantic transparency.
4177
4178 Note: The server, cache, or client implementor might be faced with
4179 design decisions not explicitly discussed in this specification.
4180 If a decision might affect semantic transparency, the implementor
4181 ought to err on the side of maintaining transparency unless a
4182 careful and complete analysis shows significant benefits in
4183 breaking transparency.
4184
4185 13.1.1 Cache Correctness
4186
4187 A correct cache MUST respond to a request with the most up-to-date
4188 response held by the cache that is appropriate to the request (see
4189 sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
4190 conditions:
4191
4192 1. It has been checked for equivalence with what the origin server
4193 would have returned by revalidating the response with the
4194 origin server (section 13.3);
4195
4196
4197
4198
4199
4200
4201
4202 Fielding, et al. Standards Track [Page 75]
4203
4204 RFC 2616 HTTP/1.1 June 1999
4205
4206
4207 2. It is "fresh enough" (see section 13.2). In the default case,
4208 this means it meets the least restrictive freshness requirement
4209 of the client, origin server, and cache (see section 14.9); if
4210 the origin server so specifies, it is the freshness requirement
4211 of the origin server alone.
4212
4213 If a stored response is not "fresh enough" by the most
4214 restrictive freshness requirement of both the client and the
4215 origin server, in carefully considered circumstances the cache
4216 MAY still return the response with the appropriate Warning
4217 header (see section 13.1.5 and 14.46), unless such a response
4218 is prohibited (e.g., by a "no-store" cache-directive, or by a
4219 "no-cache" cache-request-directive; see section 14.9).
4220
4221 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
4222 or error (4xx or 5xx) response message.
4223
4224 If the cache can not communicate with the origin server, then a
4225 correct cache SHOULD respond as above if the response can be
4226 correctly served from the cache; if not it MUST return an error or
4227 warning indicating that there was a communication failure.
4228
4229 If a cache receives a response (either an entire response, or a 304
4230 (Not Modified) response) that it would normally forward to the
4231 requesting client, and the received response is no longer fresh, the
4232 cache SHOULD forward it to the requesting client without adding a new
4233 Warning (but without removing any existing Warning headers). A cache
4234 SHOULD NOT attempt to revalidate a response simply because that
4235 response became stale in transit; this might lead to an infinite
4236 loop. A user agent that receives a stale response without a Warning
4237 MAY display a warning indication to the user.
4238
4239 13.1.2 Warnings
4240
4241 Whenever a cache returns a response that is neither first-hand nor
4242 "fresh enough" (in the sense of condition 2 in section 13.1.1), it
4243 MUST attach a warning to that effect, using a Warning general-header.
4244 The Warning header and the currently defined warnings are described
4245 in section 14.46. The warning allows clients to take appropriate
4246 action.
4247
4248 Warnings MAY be used for other purposes, both cache-related and
4249 otherwise. The use of a warning, rather than an error status code,
4250 distinguish these responses from true failures.
4251
4252 Warnings are assigned three digit warn-codes. The first digit
4253 indicates whether the Warning MUST or MUST NOT be deleted from a
4254 stored cache entry after a successful revalidation:
4255
4256
4257
4258 Fielding, et al. Standards Track [Page 76]
4259
4260 RFC 2616 HTTP/1.1 June 1999
4261
4262
4263 1xx Warnings that describe the freshness or revalidation status of
4264 the response, and so MUST be deleted after a successful
4265 revalidation. 1XX warn-codes MAY be generated by a cache only when
4266 validating a cached entry. It MUST NOT be generated by clients.
4267
4268 2xx Warnings that describe some aspect of the entity body or entity
4269 headers that is not rectified by a revalidation (for example, a
4270 lossy compression of the entity bodies) and which MUST NOT be
4271 deleted after a successful revalidation.
4272
4273 See section 14.46 for the definitions of the codes themselves.
4274
4275 HTTP/1.0 caches will cache all Warnings in responses, without
4276 deleting the ones in the first category. Warnings in responses that
4277 are passed to HTTP/1.0 caches carry an extra warning-date field,
4278 which prevents a future HTTP/1.1 recipient from believing an
4279 erroneously cached Warning.
4280
4281 Warnings also carry a warning text. The text MAY be in any
4282 appropriate natural language (perhaps based on the client's Accept
4283 headers), and include an OPTIONAL indication of what character set is
4284 used.
4285
4286 Multiple warnings MAY be attached to a response (either by the origin
4287 server or by a cache), including multiple warnings with the same code
4288 number. For example, a server might provide the same warning with
4289 texts in both English and Basque.
4290
4291 When multiple warnings are attached to a response, it might not be
4292 practical or reasonable to display all of them to the user. This
4293 version of HTTP does not specify strict priority rules for deciding
4294 which warnings to display and in what order, but does suggest some
4295 heuristics.
4296
4297 13.1.3 Cache-control Mechanisms
4298
4299 The basic cache mechanisms in HTTP/1.1 (server-specified expiration
4300 times and validators) are implicit directives to caches. In some
4301 cases, a server or client might need to provide explicit directives
4302 to the HTTP caches. We use the Cache-Control header for this purpose.
4303
4304 The Cache-Control header allows a client or server to transmit a
4305 variety of directives in either requests or responses. These
4306 directives typically override the default caching algorithms. As a
4307 general rule, if there is any apparent conflict between header
4308 values, the most restrictive interpretation is applied (that is, the
4309 one that is most likely to preserve semantic transparency). However,
4310
4311
4312
4313
4314 Fielding, et al. Standards Track [Page 77]
4315
4316 RFC 2616 HTTP/1.1 June 1999
4317
4318
4319 in some cases, cache-control directives are explicitly specified as
4320 weakening the approximation of semantic transparency (for example,
4321 "max-stale" or "public").
4322
4323 The cache-control directives are described in detail in section 14.9.
4324
4325 13.1.4 Explicit User Agent Warnings
4326
4327 Many user agents make it possible for users to override the basic
4328 caching mechanisms. For example, the user agent might allow the user
4329 to specify that cached entities (even explicitly stale ones) are
4330 never validated. Or the user agent might habitually add "Cache-
4331 Control: max-stale=3600" to every request. The user agent SHOULD NOT
4332 default to either non-transparent behavior, or behavior that results
4333 in abnormally ineffective caching, but MAY be explicitly configured
4334 to do so by an explicit action of the user.
4335
4336 If the user has overridden the basic caching mechanisms, the user
4337 agent SHOULD explicitly indicate to the user whenever this results in
4338 the display of information that might not meet the server's
4339 transparency requirements (in particular, if the displayed entity is
4340 known to be stale). Since the protocol normally allows the user agent
4341 to determine if responses are stale or not, this indication need only
4342 be displayed when this actually happens. The indication need not be a
4343 dialog box; it could be an icon (for example, a picture of a rotting
4344 fish) or some other indicator.
4345
4346 If the user has overridden the caching mechanisms in a way that would
4347 abnormally reduce the effectiveness of caches, the user agent SHOULD
4348 continually indicate this state to the user (for example, by a
4349 display of a picture of currency in flames) so that the user does not
4350 inadvertently consume excess resources or suffer from excessive
4351 latency.
4352
4353 13.1.5 Exceptions to the Rules and Warnings
4354
4355 In some cases, the operator of a cache MAY choose to configure it to
4356 return stale responses even when not requested by clients. This
4357 decision ought not be made lightly, but may be necessary for reasons
4358 of availability or performance, especially when the cache is poorly
4359 connected to the origin server. Whenever a cache returns a stale
4360 response, it MUST mark it as such (using a Warning header) enabling
4361 the client software to alert the user that there might be a potential
4362 problem.
4363
4364
4365
4366
4367
4368
4369
4370 Fielding, et al. Standards Track [Page 78]
4371
4372 RFC 2616 HTTP/1.1 June 1999
4373
4374
4375 It also allows the user agent to take steps to obtain a first-hand or
4376 fresh response. For this reason, a cache SHOULD NOT return a stale
4377 response if the client explicitly requests a first-hand or fresh one,
4378 unless it is impossible to comply for technical or policy reasons.
4379
4380 13.1.6 Client-controlled Behavior
4381
4382 While the origin server (and to a lesser extent, intermediate caches,
4383 by their contribution to the age of a response) are the primary
4384 source of expiration information, in some cases the client might need
4385 to control a cache's decision about whether to return a cached
4386 response without validating it. Clients do this using several
4387 directives of the Cache-Control header.
4388
4389 A client's request MAY specify the maximum age it is willing to
4390 accept of an unvalidated response; specifying a value of zero forces
4391 the cache(s) to revalidate all responses. A client MAY also specify
4392 the minimum time remaining before a response expires. Both of these
4393 options increase constraints on the behavior of caches, and so cannot
4394 further relax the cache's approximation of semantic transparency.
4395
4396 A client MAY also specify that it will accept stale responses, up to
4397 some maximum amount of staleness. This loosens the constraints on the
4398 caches, and so might violate the origin server's specified
4399 constraints on semantic transparency, but might be necessary to
4400 support disconnected operation, or high availability in the face of
4401 poor connectivity.
4402
4403 13.2 Expiration Model
4404
4405 13.2.1 Server-Specified Expiration
4406
4407 HTTP caching works best when caches can entirely avoid making
4408 requests to the origin server. The primary mechanism for avoiding
4409 requests is for an origin server to provide an explicit expiration
4410 time in the future, indicating that a response MAY be used to satisfy
4411 subsequent requests. In other words, a cache can return a fresh
4412 response without first contacting the server.
4413
4414 Our expectation is that servers will assign future explicit
4415 expiration times to responses in the belief that the entity is not
4416 likely to change, in a semantically significant way, before the
4417 expiration time is reached. This normally preserves semantic
4418 transparency, as long as the server's expiration times are carefully
4419 chosen.
4420
4421
4422
4423
4424
4425
4426 Fielding, et al. Standards Track [Page 79]
4427
4428 RFC 2616 HTTP/1.1 June 1999
4429
4430
4431 The expiration mechanism applies only to responses taken from a cache
4432 and not to first-hand responses forwarded immediately to the
4433 requesting client.
4434
4435 If an origin server wishes to force a semantically transparent cache
4436 to validate every request, it MAY assign an explicit expiration time
4437 in the past. This means that the response is always stale, and so the
4438 cache SHOULD validate it before using it for subsequent requests. See
4439 section 14.9.4 for a more restrictive way to force revalidation.
4440
4441 If an origin server wishes to force any HTTP/1.1 cache, no matter how
4442 it is configured, to validate every request, it SHOULD use the "must-
4443 revalidate" cache-control directive (see section 14.9).
4444
4445 Servers specify explicit expiration times using either the Expires
4446 header, or the max-age directive of the Cache-Control header.
4447
4448 An expiration time cannot be used to force a user agent to refresh
4449 its display or reload a resource; its semantics apply only to caching
4450 mechanisms, and such mechanisms need only check a resource's
4451 expiration status when a new request for that resource is initiated.
4452 See section 13.13 for an explanation of the difference between caches
4453 and history mechanisms.
4454
4455 13.2.2 Heuristic Expiration
4456
4457 Since origin servers do not always provide explicit expiration times,
4458 HTTP caches typically assign heuristic expiration times, employing
4459 algorithms that use other header values (such as the Last-Modified
4460 time) to estimate a plausible expiration time. The HTTP/1.1
4461 specification does not provide specific algorithms, but does impose
4462 worst-case constraints on their results. Since heuristic expiration
4463 times might compromise semantic transparency, they ought to used
4464 cautiously, and we encourage origin servers to provide explicit
4465 expiration times as much as possible.
4466
4467 13.2.3 Age Calculations
4468
4469 In order to know if a cached entry is fresh, a cache needs to know if
4470 its age exceeds its freshness lifetime. We discuss how to calculate
4471 the latter in section 13.2.4; this section describes how to calculate
4472 the age of a response or cache entry.
4473
4474 In this discussion, we use the term "now" to mean "the current value
4475 of the clock at the host performing the calculation." Hosts that use
4476 HTTP, but especially hosts running origin servers and caches, SHOULD
4477 use NTP [28] or some similar protocol to synchronize their clocks to
4478 a globally accurate time standard.
4479
4480
4481
4482 Fielding, et al. Standards Track [Page 80]
4483
4484 RFC 2616 HTTP/1.1 June 1999
4485
4486
4487 HTTP/1.1 requires origin servers to send a Date header, if possible,
4488 with every response, giving the time at which the response was
4489 generated (see section 14.18). We use the term "date_value" to denote
4490 the value of the Date header, in a form appropriate for arithmetic
4491 operations.
4492
4493 HTTP/1.1 uses the Age response-header to convey the estimated age of
4494 the response message when obtained from a cache. The Age field value
4495 is the cache's estimate of the amount of time since the response was
4496 generated or revalidated by the origin server.
4497
4498 In essence, the Age value is the sum of the time that the response
4499 has been resident in each of the caches along the path from the
4500 origin server, plus the amount of time it has been in transit along
4501 network paths.
4502
4503 We use the term "age_value" to denote the value of the Age header, in
4504 a form appropriate for arithmetic operations.
4505
4506 A response's age can be calculated in two entirely independent ways:
4507
4508 1. now minus date_value, if the local clock is reasonably well
4509 synchronized to the origin server's clock. If the result is
4510 negative, the result is replaced by zero.
4511
4512 2. age_value, if all of the caches along the response path
4513 implement HTTP/1.1.
4514
4515 Given that we have two independent ways to compute the age of a
4516 response when it is received, we can combine these as
4517
4518 corrected_received_age = max(now - date_value, age_value)
4519
4520 and as long as we have either nearly synchronized clocks or all-
4521 HTTP/1.1 paths, one gets a reliable (conservative) result.
4522
4523 Because of network-imposed delays, some significant interval might
4524 pass between the time that a server generates a response and the time
4525 it is received at the next outbound cache or client. If uncorrected,
4526 this delay could result in improperly low ages.
4527
4528 Because the request that resulted in the returned Age value must have
4529 been initiated prior to that Age value's generation, we can correct
4530 for delays imposed by the network by recording the time at which the
4531 request was initiated. Then, when an Age value is received, it MUST
4532 be interpreted relative to the time the request was initiated, not
4533
4534
4535
4536
4537
4538 Fielding, et al. Standards Track [Page 81]
4539
4540 RFC 2616 HTTP/1.1 June 1999
4541
4542
4543 the time that the response was received. This algorithm results in
4544 conservative behavior no matter how much delay is experienced. So, we
4545 compute:
4546
4547 corrected_initial_age = corrected_received_age
4548 + (now - request_time)
4549
4550 where "request_time" is the time (according to the local clock) when
4551 the request that elicited this response was sent.
4552
4553 Summary of age calculation algorithm, when a cache receives a
4554 response:
4555
4556 /*
4557 * age_value
4558 * is the value of Age: header received by the cache with
4559 * this response.
4560 * date_value
4561 * is the value of the origin server's Date: header
4562 * request_time
4563 * is the (local) time when the cache made the request
4564 * that resulted in this cached response
4565 * response_time
4566 * is the (local) time when the cache received the
4567 * response
4568 * now
4569 * is the current (local) time
4570 */
4571
4572 apparent_age = max(0, response_time - date_value);
4573 corrected_received_age = max(apparent_age, age_value);
4574 response_delay = response_time - request_time;
4575 corrected_initial_age = corrected_received_age + response_delay;
4576 resident_time = now - response_time;
4577 current_age = corrected_initial_age + resident_time;
4578
4579 The current_age of a cache entry is calculated by adding the amount
4580 of time (in seconds) since the cache entry was last validated by the
4581 origin server to the corrected_initial_age. When a response is
4582 generated from a cache entry, the cache MUST include a single Age
4583 header field in the response with a value equal to the cache entry's
4584 current_age.
4585
4586 The presence of an Age header field in a response implies that a
4587 response is not first-hand. However, the converse is not true, since
4588 the lack of an Age header field in a response does not imply that the
4589
4590
4591
4592
4593
4594 Fielding, et al. Standards Track [Page 82]
4595
4596 RFC 2616 HTTP/1.1 June 1999
4597
4598
4599 response is first-hand unless all caches along the request path are
4600 compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
4601 the Age header field).
4602
4603 13.2.4 Expiration Calculations
4604
4605 In order to decide whether a response is fresh or stale, we need to
4606 compare its freshness lifetime to its age. The age is calculated as
4607 described in section 13.2.3; this section describes how to calculate
4608 the freshness lifetime, and to determine if a response has expired.
4609 In the discussion below, the values can be represented in any form
4610 appropriate for arithmetic operations.
4611
4612 We use the term "expires_value" to denote the value of the Expires
4613 header. We use the term "max_age_value" to denote an appropriate
4614 value of the number of seconds carried by the "max-age" directive of
4615 the Cache-Control header in a response (see section 14.9.3).
4616
4617 The max-age directive takes priority over Expires, so if max-age is
4618 present in a response, the calculation is simply:
4619
4620 freshness_lifetime = max_age_value
4621
4622 Otherwise, if Expires is present in the response, the calculation is:
4623
4624 freshness_lifetime = expires_value - date_value
4625
4626 Note that neither of these calculations is vulnerable to clock skew,
4627 since all of the information comes from the origin server.
4628
4629 If none of Expires, Cache-Control: max-age, or Cache-Control: s-
4630 maxage (see section 14.9.3) appears in the response, and the response
4631 does not include other restrictions on caching, the cache MAY compute
4632 a freshness lifetime using a heuristic. The cache MUST attach Warning
4633 113 to any response whose age is more than 24 hours if such warning
4634 has not already been added.
4635
4636 Also, if the response does have a Last-Modified time, the heuristic
4637 expiration value SHOULD be no more than some fraction of the interval
4638 since that time. A typical setting of this fraction might be 10%.
4639
4640 The calculation to determine if a response has expired is quite
4641 simple:
4642
4643 response_is_fresh = (freshness_lifetime > current_age)
4644
4645
4646
4647
4648
4649
4650 Fielding, et al. Standards Track [Page 83]
4651
4652 RFC 2616 HTTP/1.1 June 1999
4653
4654
4655 13.2.5 Disambiguating Expiration Values
4656
4657 Because expiration values are assigned optimistically, it is possible
4658 for two caches to contain fresh values for the same resource that are
4659 different.
4660
4661 If a client performing a retrieval receives a non-first-hand response
4662 for a request that was already fresh in its own cache, and the Date
4663 header in its existing cache entry is newer than the Date on the new
4664 response, then the client MAY ignore the response. If so, it MAY
4665 retry the request with a "Cache-Control: max-age=0" directive (see
4666 section 14.9), to force a check with the origin server.
4667
4668 If a cache has two fresh responses for the same representation with
4669 different validators, it MUST use the one with the more recent Date
4670 header. This situation might arise because the cache is pooling
4671 responses from other caches, or because a client has asked for a
4672 reload or a revalidation of an apparently fresh cache entry.
4673
4674 13.2.6 Disambiguating Multiple Responses
4675
4676 Because a client might be receiving responses via multiple paths, so
4677 that some responses flow through one set of caches and other
4678 responses flow through a different set of caches, a client might
4679 receive responses in an order different from that in which the origin
4680 server sent them. We would like the client to use the most recently
4681 generated response, even if older responses are still apparently
4682 fresh.
4683
4684 Neither the entity tag nor the expiration value can impose an
4685 ordering on responses, since it is possible that a later response
4686 intentionally carries an earlier expiration time. The Date values are
4687 ordered to a granularity of one second.
4688
4689 When a client tries to revalidate a cache entry, and the response it
4690 receives contains a Date header that appears to be older than the one
4691 for the existing entry, then the client SHOULD repeat the request
4692 unconditionally, and include
4693
4694 Cache-Control: max-age=0
4695
4696 to force any intermediate caches to validate their copies directly
4697 with the origin server, or
4698
4699 Cache-Control: no-cache
4700
4701 to force any intermediate caches to obtain a new copy from the origin
4702 server.
4703
4704
4705
4706 Fielding, et al. Standards Track [Page 84]
4707
4708 RFC 2616 HTTP/1.1 June 1999
4709
4710
4711 If the Date values are equal, then the client MAY use either response
4712 (or MAY, if it is being extremely prudent, request a new response).
4713 Servers MUST NOT depend on clients being able to choose
4714 deterministically between responses generated during the same second,
4715 if their expiration times overlap.
4716
4717 13.3 Validation Model
4718
4719 When a cache has a stale entry that it would like to use as a
4720 response to a client's request, it first has to check with the origin
4721 server (or possibly an intermediate cache with a fresh response) to
4722 see if its cached entry is still usable. We call this "validating"
4723 the cache entry. Since we do not want to have to pay the overhead of
4724 retransmitting the full response if the cached entry is good, and we
4725 do not want to pay the overhead of an extra round trip if the cached
4726 entry is invalid, the HTTP/1.1 protocol supports the use of
4727 conditional methods.
4728
4729 The key protocol features for supporting conditional methods are
4730 those concerned with "cache validators." When an origin server
4731 generates a full response, it attaches some sort of validator to it,
4732 which is kept with the cache entry. When a client (user agent or
4733 proxy cache) makes a conditional request for a resource for which it
4734 has a cache entry, it includes the associated validator in the
4735 request.
4736
4737 The server then checks that validator against the current validator
4738 for the entity, and, if they match (see section 13.3.3), it responds
4739 with a special status code (usually, 304 (Not Modified)) and no
4740 entity-body. Otherwise, it returns a full response (including
4741 entity-body). Thus, we avoid transmitting the full response if the
4742 validator matches, and we avoid an extra round trip if it does not
4743 match.
4744
4745 In HTTP/1.1, a conditional request looks exactly the same as a normal
4746 request for the same resource, except that it carries a special
4747 header (which includes the validator) that implicitly turns the
4748 method (usually, GET) into a conditional.
4749
4750 The protocol includes both positive and negative senses of cache-
4751 validating conditions. That is, it is possible to request either that
4752 a method be performed if and only if a validator matches or if and
4753 only if no validators match.
4754
4755
4756
4757
4758
4759
4760
4761
4762 Fielding, et al. Standards Track [Page 85]
4763
4764 RFC 2616 HTTP/1.1 June 1999
4765
4766
4767 Note: a response that lacks a validator may still be cached, and
4768 served from cache until it expires, unless this is explicitly
4769 prohibited by a cache-control directive. However, a cache cannot
4770 do a conditional retrieval if it does not have a validator for the
4771 entity, which means it will not be refreshable after it expires.
4772
4773 13.3.1 Last-Modified Dates
4774
4775 The Last-Modified entity-header field value is often used as a cache
4776 validator. In simple terms, a cache entry is considered to be valid
4777 if the entity has not been modified since the Last-Modified value.
4778
4779 13.3.2 Entity Tag Cache Validators
4780
4781 The ETag response-header field value, an entity tag, provides for an
4782 "opaque" cache validator. This might allow more reliable validation
4783 in situations where it is inconvenient to store modification dates,
4784 where the one-second resolution of HTTP date values is not
4785 sufficient, or where the origin server wishes to avoid certain
4786 paradoxes that might arise from the use of modification dates.
4787
4788 Entity Tags are described in section 3.11. The headers used with
4789 entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
4790
4791 13.3.3 Weak and Strong Validators
4792
4793 Since both origin servers and caches will compare two validators to
4794 decide if they represent the same or different entities, one normally
4795 would expect that if the entity (the entity-body or any entity-
4796 headers) changes in any way, then the associated validator would
4797 change as well. If this is true, then we call this validator a
4798 "strong validator."
4799
4800 However, there might be cases when a server prefers to change the
4801 validator only on semantically significant changes, and not when
4802 insignificant aspects of the entity change. A validator that does not
4803 always change when the resource changes is a "weak validator."
4804
4805 Entity tags are normally "strong validators," but the protocol
4806 provides a mechanism to tag an entity tag as "weak." One can think of
4807 a strong validator as one that changes whenever the bits of an entity
4808 changes, while a weak value changes whenever the meaning of an entity
4809 changes. Alternatively, one can think of a strong validator as part
4810 of an identifier for a specific entity, while a weak validator is
4811 part of an identifier for a set of semantically equivalent entities.
4812
4813 Note: One example of a strong validator is an integer that is
4814 incremented in stable storage every time an entity is changed.
4815
4816
4817
4818 Fielding, et al. Standards Track [Page 86]
4819
4820 RFC 2616 HTTP/1.1 June 1999
4821
4822
4823 An entity's modification time, if represented with one-second
4824 resolution, could be a weak validator, since it is possible that
4825 the resource might be modified twice during a single second.
4826
4827 Support for weak validators is optional. However, weak validators
4828 allow for more efficient caching of equivalent objects; for
4829 example, a hit counter on a site is probably good enough if it is
4830 updated every few days or weeks, and any value during that period
4831 is likely "good enough" to be equivalent.
4832
4833 A "use" of a validator is either when a client generates a request
4834 and includes the validator in a validating header field, or when a
4835 server compares two validators.
4836
4837 Strong validators are usable in any context. Weak validators are only
4838 usable in contexts that do not depend on exact equality of an entity.
4839 For example, either kind is usable for a conditional GET of a full
4840 entity. However, only a strong validator is usable for a sub-range
4841 retrieval, since otherwise the client might end up with an internally
4842 inconsistent entity.
4843
4844 Clients MAY issue simple (non-subrange) GET requests with either weak
4845 validators or strong validators. Clients MUST NOT use weak validators
4846 in other forms of request.
4847
4848 The only function that the HTTP/1.1 protocol defines on validators is
4849 comparison. There are two validator comparison functions, depending
4850 on whether the comparison context allows the use of weak validators
4851 or not:
4852
4853 - The strong comparison function: in order to be considered equal,
4854 both validators MUST be identical in every way, and both MUST
4855 NOT be weak.
4856
4857 - The weak comparison function: in order to be considered equal,
4858 both validators MUST be identical in every way, but either or
4859 both of them MAY be tagged as "weak" without affecting the
4860 result.
4861
4862 An entity tag is strong unless it is explicitly tagged as weak.
4863 Section 3.11 gives the syntax for entity tags.
4864
4865 A Last-Modified time, when used as a validator in a request, is
4866 implicitly weak unless it is possible to deduce that it is strong,
4867 using the following rules:
4868
4869 - The validator is being compared by an origin server to the
4870 actual current validator for the entity and,
4871
4872
4873
4874 Fielding, et al. Standards Track [Page 87]
4875
4876 RFC 2616 HTTP/1.1 June 1999
4877
4878
4879 - That origin server reliably knows that the associated entity did
4880 not change twice during the second covered by the presented
4881 validator.
4882
4883 or
4884
4885 - The validator is about to be used by a client in an If-
4886 Modified-Since or If-Unmodified-Since header, because the client
4887 has a cache entry for the associated entity, and
4888
4889 - That cache entry includes a Date value, which gives the time
4890 when the origin server sent the original response, and
4891
4892 - The presented Last-Modified time is at least 60 seconds before
4893 the Date value.
4894
4895 or
4896
4897 - The validator is being compared by an intermediate cache to the
4898 validator stored in its cache entry for the entity, and
4899
4900 - That cache entry includes a Date value, which gives the time
4901 when the origin server sent the original response, and
4902
4903 - The presented Last-Modified time is at least 60 seconds before
4904 the Date value.
4905
4906 This method relies on the fact that if two different responses were
4907 sent by the origin server during the same second, but both had the
4908 same Last-Modified time, then at least one of those responses would
4909 have a Date value equal to its Last-Modified time. The arbitrary 60-
4910 second limit guards against the possibility that the Date and Last-
4911 Modified values are generated from different clocks, or at somewhat
4912 different times during the preparation of the response. An
4913 implementation MAY use a value larger than 60 seconds, if it is
4914 believed that 60 seconds is too short.
4915
4916 If a client wishes to perform a sub-range retrieval on a value for
4917 which it has only a Last-Modified time and no opaque validator, it
4918 MAY do this only if the Last-Modified time is strong in the sense
4919 described here.
4920
4921 A cache or origin server receiving a conditional request, other than
4922 a full-body GET request, MUST use the strong comparison function to
4923 evaluate the condition.
4924
4925 These rules allow HTTP/1.1 caches and clients to safely perform sub-
4926 range retrievals on values that have been obtained from HTTP/1.0
4927
4928
4929
4930 Fielding, et al. Standards Track [Page 88]
4931
4932 RFC 2616 HTTP/1.1 June 1999
4933
4934
4935 servers.
4936
4937 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
4938
4939 We adopt a set of rules and recommendations for origin servers,
4940 clients, and caches regarding when various validator types ought to
4941 be used, and for what purposes.
4942
4943 HTTP/1.1 origin servers:
4944
4945 - SHOULD send an entity tag validator unless it is not feasible to
4946 generate one.
4947
4948 - MAY send a weak entity tag instead of a strong entity tag, if
4949 performance considerations support the use of weak entity tags,
4950 or if it is unfeasible to send a strong entity tag.
4951
4952 - SHOULD send a Last-Modified value if it is feasible to send one,
4953 unless the risk of a breakdown in semantic transparency that
4954 could result from using this date in an If-Modified-Since header
4955 would lead to serious problems.
4956
4957 In other words, the preferred behavior for an HTTP/1.1 origin server
4958 is to send both a strong entity tag and a Last-Modified value.
4959
4960 In order to be legal, a strong entity tag MUST change whenever the
4961 associated entity value changes in any way. A weak entity tag SHOULD
4962 change whenever the associated entity changes in a semantically
4963 significant way.
4964
4965 Note: in order to provide semantically transparent caching, an
4966 origin server must avoid reusing a specific strong entity tag
4967 value for two different entities, or reusing a specific weak
4968 entity tag value for two semantically different entities. Cache
4969 entries might persist for arbitrarily long periods, regardless of
4970 expiration times, so it might be inappropriate to expect that a
4971 cache will never again attempt to validate an entry using a
4972 validator that it obtained at some point in the past.
4973
4974 HTTP/1.1 clients:
4975
4976 - If an entity tag has been provided by the origin server, MUST
4977 use that entity tag in any cache-conditional request (using If-
4978 Match or If-None-Match).
4979
4980 - If only a Last-Modified value has been provided by the origin
4981 server, SHOULD use that value in non-subrange cache-conditional
4982 requests (using If-Modified-Since).
4983
4984
4985
4986 Fielding, et al. Standards Track [Page 89]
4987
4988 RFC 2616 HTTP/1.1 June 1999
4989
4990
4991 - If only a Last-Modified value has been provided by an HTTP/1.0
4992 origin server, MAY use that value in subrange cache-conditional
4993 requests (using If-Unmodified-Since:). The user agent SHOULD
4994 provide a way to disable this, in case of difficulty.
4995
4996 - If both an entity tag and a Last-Modified value have been
4997 provided by the origin server, SHOULD use both validators in
4998 cache-conditional requests. This allows both HTTP/1.0 and
4999 HTTP/1.1 caches to respond appropriately.
5000
5001 An HTTP/1.1 origin server, upon receiving a conditional request that
5002 includes both a Last-Modified date (e.g., in an If-Modified-Since or
5003 If-Unmodified-Since header field) and one or more entity tags (e.g.,
5004 in an If-Match, If-None-Match, or If-Range header field) as cache
5005 validators, MUST NOT return a response status of 304 (Not Modified)
5006 unless doing so is consistent with all of the conditional header
5007 fields in the request.
5008
5009 An HTTP/1.1 caching proxy, upon receiving a conditional request that
5010 includes both a Last-Modified date and one or more entity tags as
5011 cache validators, MUST NOT return a locally cached response to the
5012 client unless that cached response is consistent with all of the
5013 conditional header fields in the request.
5014
5015 Note: The general principle behind these rules is that HTTP/1.1
5016 servers and clients should transmit as much non-redundant
5017 information as is available in their responses and requests.
5018 HTTP/1.1 systems receiving this information will make the most
5019 conservative assumptions about the validators they receive.
5020
5021 HTTP/1.0 clients and caches will ignore entity tags. Generally,
5022 last-modified values received or used by these systems will
5023 support transparent and efficient caching, and so HTTP/1.1 origin
5024 servers should provide Last-Modified values. In those rare cases
5025 where the use of a Last-Modified value as a validator by an
5026 HTTP/1.0 system could result in a serious problem, then HTTP/1.1
5027 origin servers should not provide one.
5028
5029 13.3.5 Non-validating Conditionals
5030
5031 The principle behind entity tags is that only the service author
5032 knows the semantics of a resource well enough to select an
5033 appropriate cache validation mechanism, and the specification of any
5034 validator comparison function more complex than byte-equality would
5035 open up a can of worms. Thus, comparisons of any other headers
5036 (except Last-Modified, for compatibility with HTTP/1.0) are never
5037 used for purposes of validating a cache entry.
5038
5039
5040
5041
5042 Fielding, et al. Standards Track [Page 90]
5043
5044 RFC 2616 HTTP/1.1 June 1999
5045
5046
5047 13.4 Response Cacheability
5048
5049 Unless specifically constrained by a cache-control (section 14.9)
5050 directive, a caching system MAY always store a successful response
5051 (see section 13.8) as a cache entry, MAY return it without validation
5052 if it is fresh, and MAY return it after successful validation. If
5053 there is neither a cache validator nor an explicit expiration time
5054 associated with a response, we do not expect it to be cached, but
5055 certain caches MAY violate this expectation (for example, when little
5056 or no network connectivity is available). A client can usually detect
5057 that such a response was taken from a cache by comparing the Date
5058 header to the current time.
5059
5060 Note: some HTTP/1.0 caches are known to violate this expectation
5061 without providing any Warning.
5062
5063 However, in some cases it might be inappropriate for a cache to
5064 retain an entity, or to return it in response to a subsequent
5065 request. This might be because absolute semantic transparency is
5066 deemed necessary by the service author, or because of security or
5067 privacy considerations. Certain cache-control directives are
5068 therefore provided so that the server can indicate that certain
5069 resource entities, or portions thereof, are not to be cached
5070 regardless of other considerations.
5071
5072 Note that section 14.8 normally prevents a shared cache from saving
5073 and returning a response to a previous request if that request
5074 included an Authorization header.
5075
5076 A response received with a status code of 200, 203, 206, 300, 301 or
5077 410 MAY be stored by a cache and used in reply to a subsequent
5078 request, subject to the expiration mechanism, unless a cache-control
5079 directive prohibits caching. However, a cache that does not support
5080 the Range and Content-Range headers MUST NOT cache 206 (Partial
5081 Content) responses.
5082
5083 A response received with any other status code (e.g. status codes 302
5084 and 307) MUST NOT be returned in a reply to a subsequent request
5085 unless there are cache-control directives or another header(s) that
5086 explicitly allow it. For example, these include the following: an
5087 Expires header (section 14.21); a "max-age", "s-maxage", "must-
5088 revalidate", "proxy-revalidate", "public" or "private" cache-control
5089 directive (section 14.9).
5090
5091
5092
5093
5094
5095
5096
5097
5098 Fielding, et al. Standards Track [Page 91]
5099
5100 RFC 2616 HTTP/1.1 June 1999
5101
5102
5103 13.5 Constructing Responses From Caches
5104
5105 The purpose of an HTTP cache is to store information received in
5106 response to requests for use in responding to future requests. In
5107 many cases, a cache simply returns the appropriate parts of a
5108 response to the requester. However, if the cache holds a cache entry
5109 based on a previous response, it might have to combine parts of a new
5110 response with what is held in the cache entry.
5111
5112 13.5.1 End-to-end and Hop-by-hop Headers
5113
5114 For the purpose of defining the behavior of caches and non-caching
5115 proxies, we divide HTTP headers into two categories:
5116
5117 - End-to-end headers, which are transmitted to the ultimate
5118 recipient of a request or response. End-to-end headers in
5119 responses MUST be stored as part of a cache entry and MUST be
5120 transmitted in any response formed from a cache entry.
5121
5122 - Hop-by-hop headers, which are meaningful only for a single
5123 transport-level connection, and are not stored by caches or
5124 forwarded by proxies.
5125
5126 The following HTTP/1.1 headers are hop-by-hop headers:
5127
5128 - Connection
5129 - Keep-Alive
5130 - Proxy-Authenticate
5131 - Proxy-Authorization
5132 - TE
5133 - Trailers
5134 - Transfer-Encoding
5135 - Upgrade
5136
5137 All other headers defined by HTTP/1.1 are end-to-end headers.
5138
5139 Other hop-by-hop headers MUST be listed in a Connection header,
5140 (section 14.10) to be introduced into HTTP/1.1 (or later).
5141
5142 13.5.2 Non-modifiable Headers
5143
5144 Some features of the HTTP/1.1 protocol, such as Digest
5145 Authentication, depend on the value of certain end-to-end headers. A
5146 transparent proxy SHOULD NOT modify an end-to-end header unless the
5147 definition of that header requires or specifically allows that.
5148
5149
5150
5151
5152
5153
5154 Fielding, et al. Standards Track [Page 92]
5155
5156 RFC 2616 HTTP/1.1 June 1999
5157
5158
5159 A transparent proxy MUST NOT modify any of the following fields in a
5160 request or response, and it MUST NOT add any of these fields if not
5161 already present:
5162
5163 - Content-Location
5164
5165 - Content-MD5
5166
5167 - ETag
5168
5169 - Last-Modified
5170
5171 A transparent proxy MUST NOT modify any of the following fields in a
5172 response:
5173
5174 - Expires
5175
5176 but it MAY add any of these fields if not already present. If an
5177 Expires header is added, it MUST be given a field-value identical to
5178 that of the Date header in that response.
5179
5180 A proxy MUST NOT modify or add any of the following fields in a
5181 message that contains the no-transform cache-control directive, or in
5182 any request:
5183
5184 - Content-Encoding
5185
5186 - Content-Range
5187
5188 - Content-Type
5189
5190 A non-transparent proxy MAY modify or add these fields to a message
5191 that does not include no-transform, but if it does so, it MUST add a
5192 Warning 214 (Transformation applied) if one does not already appear
5193 in the message (see section 14.46).
5194
5195 Warning: unnecessary modification of end-to-end headers might
5196 cause authentication failures if stronger authentication
5197 mechanisms are introduced in later versions of HTTP. Such
5198 authentication mechanisms MAY rely on the values of header fields
5199 not listed here.
5200
5201 The Content-Length field of a request or response is added or deleted
5202 according to the rules in section 4.4. A transparent proxy MUST
5203 preserve the entity-length (section 7.2.2) of the entity-body,
5204 although it MAY change the transfer-length (section 4.4).
5205
5206
5207
5208
5209
5210 Fielding, et al. Standards Track [Page 93]
5211
5212 RFC 2616 HTTP/1.1 June 1999
5213
5214
5215 13.5.3 Combining Headers
5216
5217 When a cache makes a validating request to a server, and the server
5218 provides a 304 (Not Modified) response or a 206 (Partial Content)
5219 response, the cache then constructs a response to send to the
5220 requesting client.
5221
5222 If the status code is 304 (Not Modified), the cache uses the entity-
5223 body stored in the cache entry as the entity-body of this outgoing
5224 response. If the status code is 206 (Partial Content) and the ETag or
5225 Last-Modified headers match exactly, the cache MAY combine the
5226 contents stored in the cache entry with the new contents received in
5227 the response and use the result as the entity-body of this outgoing
5228 response, (see 13.5.4).
5229
5230 The end-to-end headers stored in the cache entry are used for the
5231 constructed response, except that
5232
5233 - any stored Warning headers with warn-code 1xx (see section
5234 14.46) MUST be deleted from the cache entry and the forwarded
5235 response.
5236
5237 - any stored Warning headers with warn-code 2xx MUST be retained
5238 in the cache entry and the forwarded response.
5239
5240 - any end-to-end headers provided in the 304 or 206 response MUST
5241 replace the corresponding headers from the cache entry.
5242
5243 Unless the cache decides to remove the cache entry, it MUST also
5244 replace the end-to-end headers stored with the cache entry with
5245 corresponding headers received in the incoming response, except for
5246 Warning headers as described immediately above. If a header field-
5247 name in the incoming response matches more than one header in the
5248 cache entry, all such old headers MUST be replaced.
5249
5250 In other words, the set of end-to-end headers received in the
5251 incoming response overrides all corresponding end-to-end headers
5252 stored with the cache entry (except for stored Warning headers with
5253 warn-code 1xx, which are deleted even if not overridden).
5254
5255 Note: this rule allows an origin server to use a 304 (Not
5256 Modified) or a 206 (Partial Content) response to update any header
5257 associated with a previous response for the same entity or sub-
5258 ranges thereof, although it might not always be meaningful or
5259 correct to do so. This rule does not allow an origin server to use
5260 a 304 (Not Modified) or a 206 (Partial Content) response to
5261 entirely delete a header that it had provided with a previous
5262 response.
5263
5264
5265
5266 Fielding, et al. Standards Track [Page 94]
5267
5268 RFC 2616 HTTP/1.1 June 1999
5269
5270
5271 13.5.4 Combining Byte Ranges
5272
5273 A response might transfer only a subrange of the bytes of an entity-
5274 body, either because the request included one or more Range
5275 specifications, or because a connection was broken prematurely. After
5276 several such transfers, a cache might have received several ranges of
5277 the same entity-body.
5278
5279 If a cache has a stored non-empty set of subranges for an entity, and
5280 an incoming response transfers another subrange, the cache MAY
5281 combine the new subrange with the existing set if both the following
5282 conditions are met:
5283
5284 - Both the incoming response and the cache entry have a cache
5285 validator.
5286
5287 - The two cache validators match using the strong comparison
5288 function (see section 13.3.3).
5289
5290 If either requirement is not met, the cache MUST use only the most
5291 recent partial response (based on the Date values transmitted with
5292 every response, and using the incoming response if these values are
5293 equal or missing), and MUST discard the other partial information.
5294
5295 13.6 Caching Negotiated Responses
5296
5297 Use of server-driven content negotiation (section 12.1), as indicated
5298 by the presence of a Vary header field in a response, alters the
5299 conditions and procedure by which a cache can use the response for
5300 subsequent requests. See section 14.44 for use of the Vary header
5301 field by servers.
5302
5303 A server SHOULD use the Vary header field to inform a cache of what
5304 request-header fields were used to select among multiple
5305 representations of a cacheable response subject to server-driven
5306 negotiation. The set of header fields named by the Vary field value
5307 is known as the "selecting" request-headers.
5308
5309 When the cache receives a subsequent request whose Request-URI
5310 specifies one or more cache entries including a Vary header field,
5311 the cache MUST NOT use such a cache entry to construct a response to
5312 the new request unless all of the selecting request-headers present
5313 in the new request match the corresponding stored request-headers in
5314 the original request.
5315
5316 The selecting request-headers from two requests are defined to match
5317 if and only if the selecting request-headers in the first request can
5318 be transformed to the selecting request-headers in the second request
5319
5320
5321
5322 Fielding, et al. Standards Track [Page 95]
5323
5324 RFC 2616 HTTP/1.1 June 1999
5325
5326
5327 by adding or removing linear white space (LWS) at places where this
5328 is allowed by the corresponding BNF, and/or combining multiple
5329 message-header fields with the same field name following the rules
5330 about message headers in section 4.2.
5331
5332 A Vary header field-value of "*" always fails to match and subsequent
5333 requests on that resource can only be properly interpreted by the
5334 origin server.
5335
5336 If the selecting request header fields for the cached entry do not
5337 match the selecting request header fields of the new request, then
5338 the cache MUST NOT use a cached entry to satisfy the request unless
5339 it first relays the new request to the origin server in a conditional
5340 request and the server responds with 304 (Not Modified), including an
5341 entity tag or Content-Location that indicates the entity to be used.
5342
5343 If an entity tag was assigned to a cached representation, the
5344 forwarded request SHOULD be conditional and include the entity tags
5345 in an If-None-Match header field from all its cache entries for the
5346 resource. This conveys to the server the set of entities currently
5347 held by the cache, so that if any one of these entities matches the
5348 requested entity, the server can use the ETag header field in its 304
5349 (Not Modified) response to tell the cache which entry is appropriate.
5350 If the entity-tag of the new response matches that of an existing
5351 entry, the new response SHOULD be used to update the header fields of
5352 the existing entry, and the result MUST be returned to the client.
5353
5354 If any of the existing cache entries contains only partial content
5355 for the associated entity, its entity-tag SHOULD NOT be included in
5356 the If-None-Match header field unless the request is for a range that
5357 would be fully satisfied by that entry.
5358
5359 If a cache receives a successful response whose Content-Location
5360 field matches that of an existing cache entry for the same Request-
5361 ]URI, whose entity-tag differs from that of the existing entry, and
5362 whose Date is more recent than that of the existing entry, the
5363 existing entry SHOULD NOT be returned in response to future requests
5364 and SHOULD be deleted from the cache.
5365
5366 13.7 Shared and Non-Shared Caches
5367
5368 For reasons of security and privacy, it is necessary to make a
5369 distinction between "shared" and "non-shared" caches. A non-shared
5370 cache is one that is accessible only to a single user. Accessibility
5371 in this case SHOULD be enforced by appropriate security mechanisms.
5372 All other caches are considered to be "shared." Other sections of
5373
5374
5375
5376
5377
5378 Fielding, et al. Standards Track [Page 96]
5379
5380 RFC 2616 HTTP/1.1 June 1999
5381
5382
5383 this specification place certain constraints on the operation of
5384 shared caches in order to prevent loss of privacy or failure of
5385 access controls.
5386
5387 13.8 Errors or Incomplete Response Cache Behavior
5388
5389 A cache that receives an incomplete response (for example, with fewer
5390 bytes of data than specified in a Content-Length header) MAY store
5391 the response. However, the cache MUST treat this as a partial
5392 response. Partial responses MAY be combined as described in section
5393 13.5.4; the result might be a full response or might still be
5394 partial. A cache MUST NOT return a partial response to a client
5395 without explicitly marking it as such, using the 206 (Partial
5396 Content) status code. A cache MUST NOT return a partial response
5397 using a status code of 200 (OK).
5398
5399 If a cache receives a 5xx response while attempting to revalidate an
5400 entry, it MAY either forward this response to the requesting client,
5401 or act as if the server failed to respond. In the latter case, it MAY
5402 return a previously received response unless the cached entry
5403 includes the "must-revalidate" cache-control directive (see section
5404 14.9).
5405
5406 13.9 Side Effects of GET and HEAD
5407
5408 Unless the origin server explicitly prohibits the caching of their
5409 responses, the application of GET and HEAD methods to any resources
5410 SHOULD NOT have side effects that would lead to erroneous behavior if
5411 these responses are taken from a cache. They MAY still have side
5412 effects, but a cache is not required to consider such side effects in
5413 its caching decisions. Caches are always expected to observe an
5414 origin server's explicit restrictions on caching.
5415
5416 We note one exception to this rule: since some applications have
5417 traditionally used GETs and HEADs with query URLs (those containing a
5418 "?" in the rel_path part) to perform operations with significant side
5419 effects, caches MUST NOT treat responses to such URIs as fresh unless
5420 the server provides an explicit expiration time. This specifically
5421 means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
5422 be taken from a cache. See section 9.1.1 for related information.
5423
5424 13.10 Invalidation After Updates or Deletions
5425
5426 The effect of certain methods performed on a resource at the origin
5427 server might cause one or more existing cache entries to become non-
5428 transparently invalid. That is, although they might continue to be
5429 "fresh," they do not accurately reflect what the origin server would
5430 return for a new request on that resource.
5431
5432
5433
5434 Fielding, et al. Standards Track [Page 97]
5435
