7 Network Working Group R. Fielding
8 Request for Comments: 2068 UC Irvine
9 Category: Standards Track J. Gettys
18 Hypertext Transfer Protocol -- HTTP/1.1
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
30 The Hypertext Transfer Protocol (HTTP) is an application-level
31 protocol for distributed, collaborative, hypermedia information
32 systems. It is a generic, stateless, object-oriented protocol which
33 can be used for many tasks, such as name servers and distributed
34 object management systems, through extension of its request methods.
35 A feature of HTTP is the typing and negotiation of data
36 representation, allowing systems to be built independently of the
37 data being transferred.
39 HTTP has been in use by the World-Wide Web global information
40 initiative since 1990. This specification defines the protocol
41 referred to as "HTTP/1.1".
45 1 Introduction.............................................7
46 1.1 Purpose ..............................................7
47 1.2 Requirements .........................................7
48 1.3 Terminology ..........................................8
49 1.4 Overall Operation ...................................11
50 2 Notational Conventions and Generic Grammar..............13
51 2.1 Augmented BNF .......................................13
52 2.2 Basic Rules .........................................15
53 3 Protocol Parameters.....................................17
54 3.1 HTTP Version ........................................17
58 Fielding, et. al. Standards Track [Page 1]
60 RFC 2068 HTTP/1.1 January 1997
63 3.2 Uniform Resource Identifiers ........................18
64 3.2.1 General Syntax ...................................18
65 3.2.2 http URL .........................................19
66 3.2.3 URI Comparison ...................................20
67 3.3 Date/Time Formats ...................................21
68 3.3.1 Full Date ........................................21
69 3.3.2 Delta Seconds ....................................22
70 3.4 Character Sets ......................................22
71 3.5 Content Codings .....................................23
72 3.6 Transfer Codings ....................................24
73 3.7 Media Types .........................................25
74 3.7.1 Canonicalization and Text Defaults ...............26
75 3.7.2 Multipart Types ..................................27
76 3.8 Product Tokens ......................................28
77 3.9 Quality Values ......................................28
78 3.10 Language Tags ......................................28
79 3.11 Entity Tags ........................................29
80 3.12 Range Units ........................................30
81 4 HTTP Message............................................30
82 4.1 Message Types .......................................30
83 4.2 Message Headers .....................................31
84 4.3 Message Body ........................................32
85 4.4 Message Length ......................................32
86 4.5 General Header Fields ...............................34
87 5 Request.................................................34
88 5.1 Request-Line ........................................34
89 5.1.1 Method ...........................................35
90 5.1.2 Request-URI ......................................35
91 5.2 The Resource Identified by a Request ................37
92 5.3 Request Header Fields ...............................37
93 6 Response................................................38
94 6.1 Status-Line .........................................38
95 6.1.1 Status Code and Reason Phrase ....................39
96 6.2 Response Header Fields ..............................41
97 7 Entity..................................................41
98 7.1 Entity Header Fields ................................41
99 7.2 Entity Body .........................................42
100 7.2.1 Type .............................................42
101 7.2.2 Length ...........................................43
102 8 Connections.............................................43
103 8.1 Persistent Connections ..............................43
104 8.1.1 Purpose ..........................................43
105 8.1.2 Overall Operation ................................44
106 8.1.3 Proxy Servers ....................................45
107 8.1.4 Practical Considerations .........................45
108 8.2 Message Transmission Requirements ...................46
109 9 Method Definitions......................................48
110 9.1 Safe and Idempotent Methods .........................48
114 Fielding, et. al. Standards Track [Page 2]
116 RFC 2068 HTTP/1.1 January 1997
119 9.1.1 Safe Methods .....................................48
120 9.1.2 Idempotent Methods ...............................49
121 9.2 OPTIONS .............................................49
122 9.3 GET .................................................50
123 9.4 HEAD ................................................50
124 9.5 POST ................................................51
125 9.6 PUT .................................................52
126 9.7 DELETE ..............................................53
127 9.8 TRACE ...............................................53
128 10 Status Code Definitions................................53
129 10.1 Informational 1xx ..................................54
130 10.1.1 100 Continue ....................................54
131 10.1.2 101 Switching Protocols .........................54
132 10.2 Successful 2xx .....................................54
133 10.2.1 200 OK ..........................................54
134 10.2.2 201 Created .....................................55
135 10.2.3 202 Accepted ....................................55
136 10.2.4 203 Non-Authoritative Information ...............55
137 10.2.5 204 No Content ..................................55
138 10.2.6 205 Reset Content ...............................56
139 10.2.7 206 Partial Content .............................56
140 10.3 Redirection 3xx ....................................56
141 10.3.1 300 Multiple Choices ............................57
142 10.3.2 301 Moved Permanently ...........................57
143 10.3.3 302 Moved Temporarily ...........................58
144 10.3.4 303 See Other ...................................58
145 10.3.5 304 Not Modified ................................58
146 10.3.6 305 Use Proxy ...................................59
147 10.4 Client Error 4xx ...................................59
148 10.4.1 400 Bad Request .................................60
149 10.4.2 401 Unauthorized ................................60
150 10.4.3 402 Payment Required ............................60
151 10.4.4 403 Forbidden ...................................60
152 10.4.5 404 Not Found ...................................60
153 10.4.6 405 Method Not Allowed ..........................61
154 10.4.7 406 Not Acceptable ..............................61
155 10.4.8 407 Proxy Authentication Required ...............61
156 10.4.9 408 Request Timeout .............................62
157 10.4.10 409 Conflict ...................................62
158 10.4.11 410 Gone .......................................62
159 10.4.12 411 Length Required ............................63
160 10.4.13 412 Precondition Failed ........................63
161 10.4.14 413 Request Entity Too Large ...................63
162 10.4.15 414 Request-URI Too Long .......................63
163 10.4.16 415 Unsupported Media Type .....................63
164 10.5 Server Error 5xx ...................................64
165 10.5.1 500 Internal Server Error .......................64
166 10.5.2 501 Not Implemented .............................64
170 Fielding, et. al. Standards Track [Page 3]
172 RFC 2068 HTTP/1.1 January 1997
175 10.5.3 502 Bad Gateway .................................64
176 10.5.4 503 Service Unavailable .........................64
177 10.5.5 504 Gateway Timeout .............................64
178 10.5.6 505 HTTP Version Not Supported ..................65
179 11 Access Authentication..................................65
180 11.1 Basic Authentication Scheme ........................66
181 11.2 Digest Authentication Scheme .......................67
182 12 Content Negotiation....................................67
183 12.1 Server-driven Negotiation ..........................68
184 12.2 Agent-driven Negotiation ...........................69
185 12.3 Transparent Negotiation ............................70
186 13 Caching in HTTP........................................70
187 13.1.1 Cache Correctness ...............................72
188 13.1.2 Warnings ........................................73
189 13.1.3 Cache-control Mechanisms ........................74
190 13.1.4 Explicit User Agent Warnings ....................74
191 13.1.5 Exceptions to the Rules and Warnings ............75
192 13.1.6 Client-controlled Behavior ......................75
193 13.2 Expiration Model ...................................75
194 13.2.1 Server-Specified Expiration .....................75
195 13.2.2 Heuristic Expiration ............................76
196 13.2.3 Age Calculations ................................77
197 13.2.4 Expiration Calculations .........................79
198 13.2.5 Disambiguating Expiration Values ................80
199 13.2.6 Disambiguating Multiple Responses ...............80
200 13.3 Validation Model ...................................81
201 13.3.1 Last-modified Dates .............................82
202 13.3.2 Entity Tag Cache Validators .....................82
203 13.3.3 Weak and Strong Validators ......................82
204 13.3.4 Rules for When to Use Entity Tags and Last-
205 modified Dates..........................................85
206 13.3.5 Non-validating Conditionals .....................86
207 13.4 Response Cachability ...............................86
208 13.5 Constructing Responses From Caches .................87
209 13.5.1 End-to-end and Hop-by-hop Headers ...............88
210 13.5.2 Non-modifiable Headers ..........................88
211 13.5.3 Combining Headers ...............................89
212 13.5.4 Combining Byte Ranges ...........................90
213 13.6 Caching Negotiated Responses .......................90
214 13.7 Shared and Non-Shared Caches .......................91
215 13.8 Errors or Incomplete Response Cache Behavior .......91
216 13.9 Side Effects of GET and HEAD .......................92
217 13.10 Invalidation After Updates or Deletions ...........92
218 13.11 Write-Through Mandatory ...........................93
219 13.12 Cache Replacement .................................93
220 13.13 History Lists .....................................93
221 14 Header Field Definitions...............................94
222 14.1 Accept .............................................95
226 Fielding, et. al. Standards Track [Page 4]
228 RFC 2068 HTTP/1.1 January 1997
231 14.2 Accept-Charset .....................................97
232 14.3 Accept-Encoding ....................................97
233 14.4 Accept-Language ....................................98
234 14.5 Accept-Ranges ......................................99
235 14.6 Age ................................................99
236 14.7 Allow .............................................100
237 14.8 Authorization .....................................100
238 14.9 Cache-Control .....................................101
239 14.9.1 What is Cachable ...............................103
240 14.9.2 What May be Stored by Caches ...................103
241 14.9.3 Modifications of the Basic Expiration Mechanism 104
242 14.9.4 Cache Revalidation and Reload Controls .........105
243 14.9.5 No-Transform Directive .........................107
244 14.9.6 Cache Control Extensions .......................108
245 14.10 Connection .......................................109
246 14.11 Content-Base .....................................109
247 14.12 Content-Encoding .................................110
248 14.13 Content-Language .................................110
249 14.14 Content-Length ...................................111
250 14.15 Content-Location .................................112
251 14.16 Content-MD5 ......................................113
252 14.17 Content-Range ....................................114
253 14.18 Content-Type .....................................116
254 14.19 Date .............................................116
255 14.20 ETag .............................................117
256 14.21 Expires ..........................................117
257 14.22 From .............................................118
258 14.23 Host .............................................119
259 14.24 If-Modified-Since ................................119
260 14.25 If-Match .........................................121
261 14.26 If-None-Match ....................................122
262 14.27 If-Range .........................................123
263 14.28 If-Unmodified-Since ..............................124
264 14.29 Last-Modified ....................................124
265 14.30 Location .........................................125
266 14.31 Max-Forwards .....................................125
267 14.32 Pragma ...........................................126
268 14.33 Proxy-Authenticate ...............................127
269 14.34 Proxy-Authorization ..............................127
270 14.35 Public ...........................................127
271 14.36 Range ............................................128
272 14.36.1 Byte Ranges ...................................128
273 14.36.2 Range Retrieval Requests ......................130
274 14.37 Referer ..........................................131
275 14.38 Retry-After ......................................131
276 14.39 Server ...........................................132
277 14.40 Transfer-Encoding ................................132
278 14.41 Upgrade ..........................................132
282 Fielding, et. al. Standards Track [Page 5]
284 RFC 2068 HTTP/1.1 January 1997
287 14.42 User-Agent .......................................134
288 14.43 Vary .............................................134
289 14.44 Via ..............................................135
290 14.45 Warning ..........................................137
291 14.46 WWW-Authenticate .................................139
292 15 Security Considerations...............................139
293 15.1 Authentication of Clients .........................139
294 15.2 Offering a Choice of Authentication Schemes .......140
295 15.3 Abuse of Server Log Information ...................141
296 15.4 Transfer of Sensitive Information .................141
297 15.5 Attacks Based On File and Path Names ..............142
298 15.6 Personal Information ..............................143
299 15.7 Privacy Issues Connected to Accept Headers ........143
300 15.8 DNS Spoofing ......................................144
301 15.9 Location Headers and Spoofing .....................144
302 16 Acknowledgments.......................................144
303 17 References............................................146
304 18 Authors' Addresses....................................149
305 19 Appendices............................................150
306 19.1 Internet Media Type message/http ..................150
307 19.2 Internet Media Type multipart/byteranges ..........150
308 19.3 Tolerant Applications .............................151
309 19.4 Differences Between HTTP Entities and
310 MIME Entities...........................................152
311 19.4.1 Conversion to Canonical Form ...................152
312 19.4.2 Conversion of Date Formats .....................153
313 19.4.3 Introduction of Content-Encoding ...............153
314 19.4.4 No Content-Transfer-Encoding ...................153
315 19.4.5 HTTP Header Fields in Multipart Body-Parts .....153
316 19.4.6 Introduction of Transfer-Encoding ..............154
317 19.4.7 MIME-Version ...................................154
318 19.5 Changes from HTTP/1.0 .............................154
319 19.5.1 Changes to Simplify Multi-homed Web Servers and
320 Conserve IP Addresses .................................155
321 19.6 Additional Features ...............................156
322 19.6.1 Additional Request Methods .....................156
323 19.6.2 Additional Header Field Definitions ............156
324 19.7 Compatibility with Previous Versions ..............160
325 19.7.1 Compatibility with HTTP/1.0 Persistent
326 Connections............................................161
338 Fielding, et. al. Standards Track [Page 6]
340 RFC 2068 HTTP/1.1 January 1997
347 The Hypertext Transfer Protocol (HTTP) is an application-level
348 protocol for distributed, collaborative, hypermedia information
349 systems. HTTP has been in use by the World-Wide Web global
350 information initiative since 1990. The first version of HTTP,
351 referred to as HTTP/0.9, was a simple protocol for raw data transfer
352 across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
353 the protocol by allowing messages to be in the format of MIME-like
354 messages, containing metainformation about the data transferred and
355 modifiers on the request/response semantics. However, HTTP/1.0 does
356 not sufficiently take into consideration the effects of hierarchical
357 proxies, caching, the need for persistent connections, and virtual
358 hosts. In addition, the proliferation of incompletely-implemented
359 applications calling themselves "HTTP/1.0" has necessitated a
360 protocol version change in order for two communicating applications
361 to determine each other's true capabilities.
363 This specification defines the protocol referred to as "HTTP/1.1".
364 This protocol includes more stringent requirements than HTTP/1.0 in
365 order to ensure reliable implementation of its features.
367 Practical information systems require more functionality than simple
368 retrieval, including search, front-end update, and annotation. HTTP
369 allows an open-ended set of methods that indicate the purpose of a
370 request. It builds on the discipline of reference provided by the
371 Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or
372 name (URN) , for indicating the resource to which a method is to be
373 applied. Messages are passed in a format similar to that used by
374 Internet mail as defined by the Multipurpose Internet Mail Extensions
377 HTTP is also used as a generic protocol for communication between
378 user agents and proxies/gateways to other Internet systems, including
379 those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
380 and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
381 access to resources available from diverse applications.
385 This specification uses the same words as RFC 1123 [8] for defining
386 the significance of each particular requirement. These words are:
389 This word or the adjective "required" means that the item is an
390 absolute requirement of the specification.
394 Fielding, et. al. Standards Track [Page 7]
396 RFC 2068 HTTP/1.1 January 1997
400 This word or the adjective "recommended" means that there may
401 exist valid reasons in particular circumstances to ignore this
402 item, but the full implications should be understood and the case
403 carefully weighed before choosing a different course.
406 This word or the adjective "optional" means that this item is
407 truly optional. One vendor may choose to include the item because
408 a particular marketplace requires it or because it enhances the
409 product, for example; another vendor may omit the same item.
411 An implementation is not compliant if it fails to satisfy one or more
412 of the MUST requirements for the protocols it implements. An
413 implementation that satisfies all the MUST and all the SHOULD
414 requirements for its protocols is said to be "unconditionally
415 compliant"; one that satisfies all the MUST requirements but not all
416 the SHOULD requirements for its protocols is said to be
417 "conditionally compliant."
421 This specification uses a number of terms to refer to the roles
422 played by participants in, and objects of, the HTTP communication.
425 A transport layer virtual circuit established between two programs
426 for the purpose of communication.
429 The basic unit of HTTP communication, consisting of a structured
430 sequence of octets matching the syntax defined in section 4 and
431 transmitted via the connection.
434 An HTTP request message, as defined in section 5.
437 An HTTP response message, as defined in section 6.
440 A network data object or service that can be identified by a URI,
441 as defined in section 3.2. Resources may be available in multiple
442 representations (e.g. multiple languages, data formats, size,
443 resolutions) or vary in other ways.
450 Fielding, et. al. Standards Track [Page 8]
452 RFC 2068 HTTP/1.1 January 1997
456 The information transferred as the payload of a request or
457 response. An entity consists of metainformation in the form of
458 entity-header fields and content in the form of an entity-body, as
459 described in section 7.
462 An entity included with a response that is subject to content
463 negotiation, as described in section 12. There may exist multiple
464 representations associated with a particular response status.
467 The mechanism for selecting the appropriate representation when
468 servicing a request, as described in section 12. The
469 representation of entities in any response can be negotiated
470 (including error responses).
473 A resource may have one, or more than one, representation(s)
474 associated with it at any given instant. Each of these
475 representations is termed a `variant.' Use of the term `variant'
476 does not necessarily imply that the resource is subject to content
480 A program that establishes connections for the purpose of sending
484 The client which initiates a request. These are often browsers,
485 editors, spiders (web-traversing robots), or other end user tools.
488 An application program that accepts connections in order to
489 service requests by sending back responses. Any given program may
490 be capable of being both a client and a server; our use of these
491 terms refers only to the role being performed by the program for a
492 particular connection, rather than to the program's capabilities
493 in general. Likewise, any server may act as an origin server,
494 proxy, gateway, or tunnel, switching behavior based on the nature
498 The server on which a given resource resides or is to be created.
506 Fielding, et. al. Standards Track [Page 9]
508 RFC 2068 HTTP/1.1 January 1997
512 An intermediary program which acts as both a server and a client
513 for the purpose of making requests on behalf of other clients.
514 Requests are serviced internally or by passing them on, with
515 possible translation, to other servers. A proxy must implement
516 both the client and server requirements of this specification.
519 A server which acts as an intermediary for some other server.
520 Unlike a proxy, a gateway receives requests as if it were the
521 origin server for the requested resource; the requesting client
522 may not be aware that it is communicating with a gateway.
525 An intermediary program which is acting as a blind relay between
526 two connections. Once active, a tunnel is not considered a party
527 to the HTTP communication, though the tunnel may have been
528 initiated by an HTTP request. The tunnel ceases to exist when both
529 ends of the relayed connections are closed.
532 A program's local store of response messages and the subsystem
533 that controls its message storage, retrieval, and deletion. A
534 cache stores cachable responses in order to reduce the response
535 time and network bandwidth consumption on future, equivalent
536 requests. Any client or server may include a cache, though a cache
537 cannot be used by a server that is acting as a tunnel.
540 A response is cachable if a cache is allowed to store a copy of
541 the response message for use in answering subsequent requests. The
542 rules for determining the cachability of HTTP responses are
543 defined in section 13. Even if a resource is cachable, there may
544 be additional constraints on whether a cache can use the cached
545 copy for a particular request.
548 A response is first-hand if it comes directly and without
549 unnecessary delay from the origin server, perhaps via one or more
550 proxies. A response is also first-hand if its validity has just
551 been checked directly with the origin server.
553 explicit expiration time
554 The time at which the origin server intends that an entity should
555 no longer be returned by a cache without further validation.
562 Fielding, et. al. Standards Track [Page 10]
564 RFC 2068 HTTP/1.1 January 1997
567 heuristic expiration time
568 An expiration time assigned by a cache when no explicit expiration
572 The age of a response is the time since it was sent by, or
573 successfully validated with, the origin server.
576 The length of time between the generation of a response and its
580 A response is fresh if its age has not yet exceeded its freshness
584 A response is stale if its age has passed its freshness lifetime.
586 semantically transparent
587 A cache behaves in a "semantically transparent" manner, with
588 respect to a particular response, when its use affects neither the
589 requesting client nor the origin server, except to improve
590 performance. When a cache is semantically transparent, the client
591 receives exactly the same response (except for hop-by-hop headers)
592 that it would have received had its request been handled directly
593 by the origin server.
596 A protocol element (e.g., an entity tag or a Last-Modified time)
597 that is used to find out whether a cache entry is an equivalent
600 1.4 Overall Operation
602 The HTTP protocol is a request/response protocol. A client sends a
603 request to the server in the form of a request method, URI, and
604 protocol version, followed by a MIME-like message containing request
605 modifiers, client information, and possible body content over a
606 connection with a server. The server responds with a status line,
607 including the message's protocol version and a success or error code,
608 followed by a MIME-like message containing server information, entity
609 metainformation, and possible entity-body content. The relationship
610 between HTTP and MIME is described in appendix 19.4.
618 Fielding, et. al. Standards Track [Page 11]
620 RFC 2068 HTTP/1.1 January 1997
623 Most HTTP communication is initiated by a user agent and consists of
624 a request to be applied to a resource on some origin server. In the
625 simplest case, this may be accomplished via a single connection (v)
626 between the user agent (UA) and the origin server (O).
628 request chain ------------------------>
629 UA -------------------v------------------- O
630 <----------------------- response chain
632 A more complicated situation occurs when one or more intermediaries
633 are present in the request/response chain. There are three common
634 forms of intermediary: proxy, gateway, and tunnel. A proxy is a
635 forwarding agent, receiving requests for a URI in its absolute form,
636 rewriting all or part of the message, and forwarding the reformatted
637 request toward the server identified by the URI. A gateway is a
638 receiving agent, acting as a layer above some other server(s) and, if
639 necessary, translating the requests to the underlying server's
640 protocol. A tunnel acts as a relay point between two connections
641 without changing the messages; tunnels are used when the
642 communication needs to pass through an intermediary (such as a
643 firewall) even when the intermediary cannot understand the contents
646 request chain -------------------------------------->
647 UA -----v----- A -----v----- B -----v----- C -----v----- O
648 <------------------------------------- response chain
650 The figure above shows three intermediaries (A, B, and C) between the
651 user agent and origin server. A request or response message that
652 travels the whole chain will pass through four separate connections.
653 This distinction is important because some HTTP communication options
654 may apply only to the connection with the nearest, non-tunnel
655 neighbor, only to the end-points of the chain, or to all connections
656 along the chain. Although the diagram is linear, each participant
657 may be engaged in multiple, simultaneous communications. For example,
658 B may be receiving requests from many clients other than A, and/or
659 forwarding requests to servers other than C, at the same time that it
660 is handling A's request.
662 Any party to the communication which is not acting as a tunnel may
663 employ an internal cache for handling requests. The effect of a cache
664 is that the request/response chain is shortened if one of the
665 participants along the chain has a cached response applicable to that
666 request. The following illustrates the resulting chain if B has a
667 cached copy of an earlier response from O (via C) for a request which
668 has not been cached by UA or A.
674 Fielding, et. al. Standards Track [Page 12]
676 RFC 2068 HTTP/1.1 January 1997
679 request chain ---------->
680 UA -----v----- A -----v----- B - - - - - - C - - - - - - O
681 <--------- response chain
683 Not all responses are usefully cachable, and some requests may
684 contain modifiers which place special requirements on cache behavior.
685 HTTP requirements for cache behavior and cachable responses are
686 defined in section 13.
688 In fact, there are a wide variety of architectures and configurations
689 of caches and proxies currently being experimented with or deployed
690 across the World Wide Web; these systems include national hierarchies
691 of proxy caches to save transoceanic bandwidth, systems that
692 broadcast or multicast cache entries, organizations that distribute
693 subsets of cached data via CD-ROM, and so on. HTTP systems are used
694 in corporate intranets over high-bandwidth links, and for access via
695 PDAs with low-power radio links and intermittent connectivity. The
696 goal of HTTP/1.1 is to support the wide diversity of configurations
697 already deployed while introducing protocol constructs that meet the
698 needs of those who build web applications that require high
699 reliability and, failing that, at least reliable indications of
702 HTTP communication usually takes place over TCP/IP connections. The
703 default port is TCP 80, but other ports can be used. This does not
704 preclude HTTP from being implemented on top of any other protocol on
705 the Internet, or on other networks. HTTP only presumes a reliable
706 transport; any protocol that provides such guarantees can be used;
707 the mapping of the HTTP/1.1 request and response structures onto the
708 transport data units of the protocol in question is outside the scope
709 of this specification.
711 In HTTP/1.0, most implementations used a new connection for each
712 request/response exchange. In HTTP/1.1, a connection may be used for
713 one or more request/response exchanges, although connections may be
714 closed for a variety of reasons (see section 8.1).
716 2 Notational Conventions and Generic Grammar
720 All of the mechanisms specified in this document are described in
721 both prose and an augmented Backus-Naur Form (BNF) similar to that
722 used by RFC 822 [9]. Implementers will need to be familiar with the
723 notation in order to understand this specification. The augmented BNF
724 includes the following constructs:
730 Fielding, et. al. Standards Track [Page 13]
732 RFC 2068 HTTP/1.1 January 1997
736 The name of a rule is simply the name itself (without any enclosing
737 "<" and ">") and is separated from its definition by the equal "="
738 character. Whitespace is only significant in that indentation of
739 continuation lines is used to indicate a rule definition that spans
740 more than one line. Certain basic rules are in uppercase, such as
741 SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used
742 within definitions whenever their presence will facilitate
743 discerning the use of rule names.
746 Quotation marks surround literal text. Unless stated otherwise, the
747 text is case-insensitive.
750 Elements separated by a bar ("|") are alternatives, e.g., "yes |
751 no" will accept yes or no.
754 Elements enclosed in parentheses are treated as a single element.
755 Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
756 foo elem" and "elem bar elem".
759 The character "*" preceding an element indicates repetition. The
760 full form is "<n>*<m>element" indicating at least <n> and at most
761 <m> occurrences of element. Default values are 0 and infinity so
762 that "*(element)" allows any number, including zero; "1*element"
763 requires at least one; and "1*2element" allows one or two.
766 Square brackets enclose optional elements; "[foo bar]" is
767 equivalent to "*1(foo bar)".
770 Specific repetition: "<n>(element)" is equivalent to
771 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
772 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
773 alphabetic characters.
776 A construct "#" is defined, similar to "*", for defining lists of
777 elements. The full form is "<n>#<m>element " indicating at least
778 <n> and at most <m> elements, each separated by one or more commas
779 (",") and optional linear whitespace (LWS). This makes the usual
780 form of lists very easy; a rule such as "( *LWS element *( *LWS ","
781 *LWS element )) " can be shown as "1#element". Wherever this
782 construct is used, null elements are allowed, but do not contribute
786 Fielding, et. al. Standards Track [Page 14]
788 RFC 2068 HTTP/1.1 January 1997
791 to the count of elements present. That is, "(element), , (element)
792 " is permitted, but counts as only two elements. Therefore, where
793 at least one element is required, at least one non-null element
794 must be present. Default values are 0 and infinity so that
795 "#element" allows any number, including zero; "1#element" requires
796 at least one; and "1#2element" allows one or two.
799 A semi-colon, set off some distance to the right of rule text,
800 starts a comment that continues to the end of line. This is a
801 simple way of including useful notes in parallel with the
805 The grammar described by this specification is word-based. Except
806 where noted otherwise, linear whitespace (LWS) can be included
807 between any two adjacent words (token or quoted-string), and
808 between adjacent tokens and delimiters (tspecials), without
809 changing the interpretation of a field. At least one delimiter
810 (tspecials) must exist between any two tokens, since they would
811 otherwise be interpreted as a single token.
815 The following rules are used throughout this specification to
816 describe basic parsing constructs. The US-ASCII coded character set
817 is defined by ANSI X3.4-1986 [21].
819 OCTET = <any 8-bit sequence of data>
820 CHAR = <any US-ASCII character (octets 0 - 127)>
821 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
822 LOALPHA = <any US-ASCII lowercase letter "a".."z">
823 ALPHA = UPALPHA | LOALPHA
824 DIGIT = <any US-ASCII digit "0".."9">
825 CTL = <any US-ASCII control character
826 (octets 0 - 31) and DEL (127)>
827 CR = <US-ASCII CR, carriage return (13)>
828 LF = <US-ASCII LF, linefeed (10)>
829 SP = <US-ASCII SP, space (32)>
830 HT = <US-ASCII HT, horizontal-tab (9)>
831 <"> = <US-ASCII double-quote mark (34)>
842 Fielding, et. al. Standards Track [Page 15]
844 RFC 2068 HTTP/1.1 January 1997
847 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
848 protocol elements except the entity-body (see appendix 19.3 for
849 tolerant applications). The end-of-line marker within an entity-body
850 is defined by its associated media type, as described in section 3.7.
854 HTTP/1.1 headers can be folded onto multiple lines if the
855 continuation line begins with a space or horizontal tab. All linear
856 white space, including folding, has the same semantics as SP.
858 LWS = [CRLF] 1*( SP | HT )
860 The TEXT rule is only used for descriptive field contents and values
861 that are not intended to be interpreted by the message parser. Words
862 of *TEXT may contain characters from character sets other than ISO
863 8859-1 [22] only when encoded according to the rules of RFC 1522
866 TEXT = <any OCTET except CTLs,
869 Hexadecimal numeric characters are used in several protocol elements.
871 HEX = "A" | "B" | "C" | "D" | "E" | "F"
872 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
874 Many HTTP/1.1 header field values consist of words separated by LWS
875 or special characters. These special characters MUST be in a quoted
876 string to be used within a parameter value.
878 token = 1*<any CHAR except CTLs or tspecials>
880 tspecials = "(" | ")" | "<" | ">" | "@"
881 | "," | ";" | ":" | "\" | <">
882 | "/" | "[" | "]" | "?" | "="
883 | "{" | "}" | SP | HT
885 Comments can be included in some HTTP header fields by surrounding
886 the comment text with parentheses. Comments are only allowed in
887 fields containing "comment" as part of their field value definition.
888 In all other fields, parentheses are considered part of the field
891 comment = "(" *( ctext | comment ) ")"
892 ctext = <any TEXT excluding "(" and ")">
898 Fielding, et. al. Standards Track [Page 16]
900 RFC 2068 HTTP/1.1 January 1997
903 A string of text is parsed as a single word if it is quoted using
906 quoted-string = ( <"> *(qdtext) <"> )
908 qdtext = <any TEXT except <">>
910 The backslash character ("\") may be used as a single-character quoting
911 mechanism only within quoted-string and comment constructs.
913 quoted-pair = "\" CHAR
915 3 Protocol Parameters
919 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
920 of the protocol. The protocol versioning policy is intended to allow
921 the sender to indicate the format of a message and its capacity for
922 understanding further HTTP communication, rather than the features
923 obtained via that communication. No change is made to the version
924 number for the addition of message components which do not affect
925 communication behavior or which only add to extensible field values.
926 The <minor> number is incremented when the changes made to the
927 protocol add features which do not change the general message parsing
928 algorithm, but which may add to the message semantics and imply
929 additional capabilities of the sender. The <major> number is
930 incremented when the format of a message within the protocol is
933 The version of an HTTP message is indicated by an HTTP-Version field
934 in the first line of the message.
936 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
938 Note that the major and minor numbers MUST be treated as separate
939 integers and that each may be incremented higher than a single digit.
940 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
941 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
944 Applications sending Request or Response messages, as defined by this
945 specification, MUST include an HTTP-Version of "HTTP/1.1". Use of
946 this version number indicates that the sending application is at
947 least conditionally compliant with this specification.
949 The HTTP version of an application is the highest HTTP version for
950 which the application is at least conditionally compliant.
954 Fielding, et. al. Standards Track [Page 17]
956 RFC 2068 HTTP/1.1 January 1997
959 Proxy and gateway applications must be careful when forwarding
960 messages in protocol versions different from that of the application.
961 Since the protocol version indicates the protocol capability of the
962 sender, a proxy/gateway MUST never send a message with a version
963 indicator which is greater than its actual version; if a higher
964 version request is received, the proxy/gateway MUST either downgrade
965 the request version, respond with an error, or switch to tunnel
966 behavior. Requests with a version lower than that of the
967 proxy/gateway's version MAY be upgraded before being forwarded; the
968 proxy/gateway's response to that request MUST be in the same major
969 version as the request.
971 Note: Converting between versions of HTTP may involve modification
972 of header fields required or forbidden by the versions involved.
974 3.2 Uniform Resource Identifiers
976 URIs have been known by many names: WWW addresses, Universal Document
977 Identifiers, Universal Resource Identifiers , and finally the
978 combination of Uniform Resource Locators (URL) and Names (URN). As
979 far as HTTP is concerned, Uniform Resource Identifiers are simply
980 formatted strings which identify--via name, location, or any other
981 characteristic--a resource.
985 URIs in HTTP can be represented in absolute form or relative to some
986 known base URI, depending upon the context of their use. The two
987 forms are differentiated by the fact that absolute URIs always begin
988 with a scheme name followed by a colon.
990 URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
992 absoluteURI = scheme ":" *( uchar | reserved )
994 relativeURI = net_path | abs_path | rel_path
996 net_path = "//" net_loc [ abs_path ]
997 abs_path = "/" rel_path
998 rel_path = [ path ] [ ";" params ] [ "?" query ]
1000 path = fsegment *( "/" segment )
1004 params = param *( ";" param )
1005 param = *( pchar | "/" )
1010 Fielding, et. al. Standards Track [Page 18]
1012 RFC 2068 HTTP/1.1 January 1997
1015 scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
1016 net_loc = *( pchar | ";" | "?" )
1018 query = *( uchar | reserved )
1019 fragment = *( uchar | reserved )
1021 pchar = uchar | ":" | "@" | "&" | "=" | "+"
1022 uchar = unreserved | escape
1023 unreserved = ALPHA | DIGIT | safe | extra | national
1025 escape = "%" HEX HEX
1026 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
1027 extra = "!" | "*" | "'" | "(" | ")" | ","
1028 safe = "$" | "-" | "_" | "."
1029 unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
1030 national = <any OCTET excluding ALPHA, DIGIT,
1031 reserved, extra, safe, and unsafe>
1033 For definitive information on URL syntax and semantics, see RFC 1738
1034 [4] and RFC 1808 [11]. The BNF above includes national characters not
1035 allowed in valid URLs as specified by RFC 1738, since HTTP servers
1036 are not restricted in the set of unreserved characters allowed to
1037 represent the rel_path part of addresses, and HTTP proxies may
1038 receive requests for URIs not defined by RFC 1738.
1040 The HTTP protocol does not place any a priori limit on the length of
1041 a URI. Servers MUST be able to handle the URI of any resource they
1042 serve, and SHOULD be able to handle URIs of unbounded length if they
1043 provide GET-based forms that could generate such URIs. A server
1044 SHOULD return 414 (Request-URI Too Long) status if a URI is longer
1045 than the server can handle (see section 10.4.15).
1047 Note: Servers should be cautious about depending on URI lengths
1048 above 255 bytes, because some older client or proxy implementations
1049 may not properly support these lengths.
1053 The "http" scheme is used to locate network resources via the HTTP
1054 protocol. This section defines the scheme-specific syntax and
1055 semantics for http URLs.
1066 Fielding, et. al. Standards Track [Page 19]
1068 RFC 2068 HTTP/1.1 January 1997
1071 http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
1073 host = <A legal Internet host domain name
1074 or IP address (in dotted-decimal form),
1075 as defined by Section 2.1 of RFC 1123>
1079 If the port is empty or not given, port 80 is assumed. The semantics
1080 are that the identified resource is located at the server listening
1081 for TCP connections on that port of that host, and the Request-URI
1082 for the resource is abs_path. The use of IP addresses in URL's SHOULD
1083 be avoided whenever possible (see RFC 1900 [24]). If the abs_path is
1084 not present in the URL, it MUST be given as "/" when used as a
1085 Request-URI for a resource (section 5.1.2).
1087 3.2.3 URI Comparison
1089 When comparing two URIs to decide if they match or not, a client
1090 SHOULD use a case-sensitive octet-by-octet comparison of the entire
1091 URIs, with these exceptions:
1093 o A port that is empty or not given is equivalent to the default
1096 o Comparisons of host names MUST be case-insensitive;
1098 o Comparisons of scheme names MUST be case-insensitive;
1100 o An empty abs_path is equivalent to an abs_path of "/".
1102 Characters other than those in the "reserved" and "unsafe" sets (see
1103 section 3.2) are equivalent to their ""%" HEX HEX" encodings.
1105 For example, the following three URIs are equivalent:
1107 http://abc.com:80/~smith/home.html
1108 http://ABC.com/%7Esmith/home.html
1109 http://ABC.com:/%7esmith/home.html
1122 Fielding, et. al. Standards Track [Page 20]
1124 RFC 2068 HTTP/1.1 January 1997
1127 3.3 Date/Time Formats
1131 HTTP applications have historically allowed three different formats
1132 for the representation of date/time stamps:
1134 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
1135 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
1136 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
1138 The first format is preferred as an Internet standard and represents
1139 a fixed-length subset of that defined by RFC 1123 (an update to RFC
1140 822). The second format is in common use, but is based on the
1141 obsolete RFC 850 [12] date format and lacks a four-digit year.
1142 HTTP/1.1 clients and servers that parse the date value MUST accept
1143 all three formats (for compatibility with HTTP/1.0), though they MUST
1144 only generate the RFC 1123 format for representing HTTP-date values
1147 Note: Recipients of date values are encouraged to be robust in
1148 accepting date values that may have been sent by non-HTTP
1149 applications, as is sometimes the case when retrieving or posting
1150 messages via proxies/gateways to SMTP or NNTP.
1152 All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1153 (GMT), without exception. This is indicated in the first two formats
1154 by the inclusion of "GMT" as the three-letter abbreviation for time
1155 zone, and MUST be assumed when reading the asctime format.
1157 HTTP-date = rfc1123-date | rfc850-date | asctime-date
1159 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
1160 rfc850-date = weekday "," SP date2 SP time SP "GMT"
1161 asctime-date = wkday SP date3 SP time SP 4DIGIT
1163 date1 = 2DIGIT SP month SP 4DIGIT
1164 ; day month year (e.g., 02 Jun 1982)
1165 date2 = 2DIGIT "-" month "-" 2DIGIT
1166 ; day-month-year (e.g., 02-Jun-82)
1167 date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
1168 ; month day (e.g., Jun 2)
1170 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
1171 ; 00:00:00 - 23:59:59
1173 wkday = "Mon" | "Tue" | "Wed"
1174 | "Thu" | "Fri" | "Sat" | "Sun"
1178 Fielding, et. al. Standards Track [Page 21]
1180 RFC 2068 HTTP/1.1 January 1997
1183 weekday = "Monday" | "Tuesday" | "Wednesday"
1184 | "Thursday" | "Friday" | "Saturday" | "Sunday"
1186 month = "Jan" | "Feb" | "Mar" | "Apr"
1187 | "May" | "Jun" | "Jul" | "Aug"
1188 | "Sep" | "Oct" | "Nov" | "Dec"
1190 Note: HTTP requirements for the date/time stamp format apply only
1191 to their usage within the protocol stream. Clients and servers are
1192 not required to use these formats for user presentation, request
1197 Some HTTP header fields allow a time value to be specified as an
1198 integer number of seconds, represented in decimal, after the time
1199 that the message was received.
1201 delta-seconds = 1*DIGIT
1205 HTTP uses the same definition of the term "character set" as that
1208 The term "character set" is used in this document to refer to a
1209 method used with one or more tables to convert a sequence of octets
1210 into a sequence of characters. Note that unconditional conversion
1211 in the other direction is not required, in that not all characters
1212 may be available in a given character set and a character set may
1213 provide more than one sequence of octets to represent a particular
1214 character. This definition is intended to allow various kinds of
1215 character encodings, from simple single-table mappings such as US-
1216 ASCII to complex table switching methods such as those that use ISO
1217 2022's techniques. However, the definition associated with a MIME
1218 character set name MUST fully specify the mapping to be performed
1219 from octets to characters. In particular, use of external profiling
1220 information to determine the exact mapping is not permitted.
1222 Note: This use of the term "character set" is more commonly
1223 referred to as a "character encoding." However, since HTTP and MIME
1224 share the same registry, it is important that the terminology also
1234 Fielding, et. al. Standards Track [Page 22]
1236 RFC 2068 HTTP/1.1 January 1997
1239 HTTP character sets are identified by case-insensitive tokens. The
1240 complete set of tokens is defined by the IANA Character Set registry
1245 Although HTTP allows an arbitrary token to be used as a charset
1246 value, any token that has a predefined value within the IANA
1247 Character Set registry MUST represent the character set defined by
1248 that registry. Applications SHOULD limit their use of character sets
1249 to those defined by the IANA registry.
1253 Content coding values indicate an encoding transformation that has
1254 been or can be applied to an entity. Content codings are primarily
1255 used to allow a document to be compressed or otherwise usefully
1256 transformed without losing the identity of its underlying media type
1257 and without loss of information. Frequently, the entity is stored in
1258 coded form, transmitted directly, and only decoded by the recipient.
1260 content-coding = token
1262 All content-coding values are case-insensitive. HTTP/1.1 uses
1263 content-coding values in the Accept-Encoding (section 14.3) and
1264 Content-Encoding (section 14.12) header fields. Although the value
1265 describes the content-coding, what is more important is that it
1266 indicates what decoding mechanism will be required to remove the
1269 The Internet Assigned Numbers Authority (IANA) acts as a registry for
1270 content-coding value tokens. Initially, the registry contains the
1273 gzip An encoding format produced by the file compression program "gzip"
1274 (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-
1275 Ziv coding (LZ77) with a 32 bit CRC.
1278 The encoding format produced by the common UNIX file compression
1279 program "compress". This format is an adaptive Lempel-Ziv-Welch
1290 Fielding, et. al. Standards Track [Page 23]
1292 RFC 2068 HTTP/1.1 January 1997
1295 Note: Use of program names for the identification of encoding
1296 formats is not desirable and should be discouraged for future
1297 encodings. Their use here is representative of historical practice,
1298 not good design. For compatibility with previous implementations of
1299 HTTP, applications should consider "x-gzip" and "x-compress" to be
1300 equivalent to "gzip" and "compress" respectively.
1302 deflate The "zlib" format defined in RFC 1950[31] in combination with
1303 the "deflate" compression mechanism described in RFC 1951[29].
1305 New content-coding value tokens should be registered; to allow
1306 interoperability between clients and servers, specifications of the
1307 content coding algorithms needed to implement a new value should be
1308 publicly available and adequate for independent implementation, and
1309 conform to the purpose of content coding defined in this section.
1311 3.6 Transfer Codings
1313 Transfer coding values are used to indicate an encoding
1314 transformation that has been, can be, or may need to be applied to an
1315 entity-body in order to ensure "safe transport" through the network.
1316 This differs from a content coding in that the transfer coding is a
1317 property of the message, not of the original entity.
1319 transfer-coding = "chunked" | transfer-extension
1321 transfer-extension = token
1323 All transfer-coding values are case-insensitive. HTTP/1.1 uses
1324 transfer coding values in the Transfer-Encoding header field (section
1327 Transfer codings are analogous to the Content-Transfer-Encoding
1328 values of MIME , which were designed to enable safe transport of
1329 binary data over a 7-bit transport service. However, safe transport
1330 has a different focus for an 8bit-clean transfer protocol. In HTTP,
1331 the only unsafe characteristic of message-bodies is the difficulty in
1332 determining the exact body length (section 7.2.2), or the desire to
1333 encrypt data over a shared transport.
1335 The chunked encoding modifies the body of a message in order to
1336 transfer it as a series of chunks, each with its own size indicator,
1337 followed by an optional footer containing entity-header fields. This
1338 allows dynamically-produced content to be transferred along with the
1339 information necessary for the recipient to verify that it has
1340 received the full message.
1346 Fielding, et. al. Standards Track [Page 24]
1348 RFC 2068 HTTP/1.1 January 1997
1351 Chunked-Body = *chunk
1356 chunk = chunk-size [ chunk-ext ] CRLF
1359 hex-no-zero = <HEX excluding "0">
1361 chunk-size = hex-no-zero *HEX
1362 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
1363 chunk-ext-name = token
1364 chunk-ext-val = token | quoted-string
1365 chunk-data = chunk-size(OCTET)
1367 footer = *entity-header
1369 The chunked encoding is ended by a zero-sized chunk followed by the
1370 footer, which is terminated by an empty line. The purpose of the
1371 footer is to provide an efficient way to supply information about an
1372 entity that is generated dynamically; applications MUST NOT send
1373 header fields in the footer which are not explicitly defined as being
1374 appropriate for the footer, such as Content-MD5 or future extensions
1375 to HTTP for digital signatures or other facilities.
1377 An example process for decoding a Chunked-Body is presented in
1380 All HTTP/1.1 applications MUST be able to receive and decode the
1381 "chunked" transfer coding, and MUST ignore transfer coding extensions
1382 they do not understand. A server which receives an entity-body with a
1383 transfer-coding it does not understand SHOULD return 501
1384 (Unimplemented), and close the connection. A server MUST NOT send
1385 transfer-codings to an HTTP/1.0 client.
1389 HTTP uses Internet Media Types in the Content-Type (section 14.18)
1390 and Accept (section 14.1) header fields in order to provide open and
1391 extensible data typing and type negotiation.
1393 media-type = type "/" subtype *( ";" parameter )
1397 Parameters may follow the type/subtype in the form of attribute/value
1402 Fielding, et. al. Standards Track [Page 25]
1404 RFC 2068 HTTP/1.1 January 1997
1407 parameter = attribute "=" value
1409 value = token | quoted-string
1411 The type, subtype, and parameter attribute names are case-
1412 insensitive. Parameter values may or may not be case-sensitive,
1413 depending on the semantics of the parameter name. Linear white space
1414 (LWS) MUST NOT be used between the type and subtype, nor between an
1415 attribute and its value. User agents that recognize the media-type
1416 MUST process (or arrange to be processed by any external applications
1417 used to process that type/subtype by the user agent) the parameters
1418 for that MIME type as described by that type/subtype definition to
1419 the and inform the user of any problems discovered.
1421 Note: some older HTTP applications do not recognize media type
1422 parameters. When sending data to older HTTP applications,
1423 implementations should only use media type parameters when they are
1424 required by that type/subtype definition.
1426 Media-type values are registered with the Internet Assigned Number
1427 Authority (IANA). The media type registration process is outlined in
1428 RFC 2048 [17]. Use of non-registered media types is discouraged.
1430 3.7.1 Canonicalization and Text Defaults
1432 Internet media types are registered with a canonical form. In
1433 general, an entity-body transferred via HTTP messages MUST be
1434 represented in the appropriate canonical form prior to its
1435 transmission; the exception is "text" types, as defined in the next
1438 When in canonical form, media subtypes of the "text" type use CRLF as
1439 the text line break. HTTP relaxes this requirement and allows the
1440 transport of text media with plain CR or LF alone representing a line
1441 break when it is done consistently for an entire entity-body. HTTP
1442 applications MUST accept CRLF, bare CR, and bare LF as being
1443 representative of a line break in text media received via HTTP. In
1444 addition, if the text is represented in a character set that does not
1445 use octets 13 and 10 for CR and LF respectively, as is the case for
1446 some multi-byte character sets, HTTP allows the use of whatever octet
1447 sequences are defined by that character set to represent the
1448 equivalent of CR and LF for line breaks. This flexibility regarding
1449 line breaks applies only to text media in the entity-body; a bare CR
1450 or LF MUST NOT be substituted for CRLF within any of the HTTP control
1451 structures (such as header fields and multipart boundaries).
1453 If an entity-body is encoded with a Content-Encoding, the underlying
1454 data MUST be in a form defined above prior to being encoded.
1458 Fielding, et. al. Standards Track [Page 26]
1460 RFC 2068 HTTP/1.1 January 1997
1463 The "charset" parameter is used with some media types to define the
1464 character set (section 3.4) of the data. When no explicit charset
1465 parameter is provided by the sender, media subtypes of the "text"
1466 type are defined to have a default charset value of "ISO-8859-1" when
1467 received via HTTP. Data in character sets other than "ISO-8859-1" or
1468 its subsets MUST be labeled with an appropriate charset value.
1470 Some HTTP/1.0 software has interpreted a Content-Type header without
1471 charset parameter incorrectly to mean "recipient should guess."
1472 Senders wishing to defeat this behavior MAY include a charset
1473 parameter even when the charset is ISO-8859-1 and SHOULD do so when
1474 it is known that it will not confuse the recipient.
1476 Unfortunately, some older HTTP/1.0 clients did not deal properly with
1477 an explicit charset parameter. HTTP/1.1 recipients MUST respect the
1478 charset label provided by the sender; and those user agents that have
1479 a provision to "guess" a charset MUST use the charset from the
1480 content-type field if they support that charset, rather than the
1481 recipient's preference, when initially displaying a document.
1483 3.7.2 Multipart Types
1485 MIME provides for a number of "multipart" types -- encapsulations of
1486 one or more entities within a single message-body. All multipart
1487 types share a common syntax, as defined in MIME [7], and MUST
1488 include a boundary parameter as part of the media type value. The
1489 message body is itself a protocol element and MUST therefore use only
1490 CRLF to represent line breaks between body-parts. Unlike in MIME, the
1491 epilogue of any multipart message MUST be empty; HTTP applications
1492 MUST NOT transmit the epilogue (even if the original multipart
1493 contains an epilogue).
1495 In HTTP, multipart body-parts MAY contain header fields which are
1496 significant to the meaning of that part. A Content-Location header
1497 field (section 14.15) SHOULD be included in the body-part of each
1498 enclosed entity that can be identified by a URL.
1500 In general, an HTTP user agent SHOULD follow the same or similar
1501 behavior as a MIME user agent would upon receipt of a multipart type.
1502 If an application receives an unrecognized multipart subtype, the
1503 application MUST treat it as being equivalent to "multipart/mixed".
1505 Note: The "multipart/form-data" type has been specifically defined
1506 for carrying form data suitable for processing via the POST request
1507 method, as described in RFC 1867 [15].
1514 Fielding, et. al. Standards Track [Page 27]
1516 RFC 2068 HTTP/1.1 January 1997
1521 Product tokens are used to allow communicating applications to
1522 identify themselves by software name and version. Most fields using
1523 product tokens also allow sub-products which form a significant part
1524 of the application to be listed, separated by whitespace. By
1525 convention, the products are listed in order of their significance
1526 for identifying the application.
1528 product = token ["/" product-version]
1529 product-version = token
1533 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1534 Server: Apache/0.8.4
1536 Product tokens should be short and to the point -- use of them for
1537 advertising or other non-essential information is explicitly
1538 forbidden. Although any token character may appear in a product-
1539 version, this token SHOULD only be used for a version identifier
1540 (i.e., successive versions of the same product SHOULD only differ in
1541 the product-version portion of the product value).
1545 HTTP content negotiation (section 12) uses short "floating point"
1546 numbers to indicate the relative importance ("weight") of various
1547 negotiable parameters. A weight is normalized to a real number in the
1548 range 0 through 1, where 0 is the minimum and 1 the maximum value.
1549 HTTP/1.1 applications MUST NOT generate more than three digits after
1550 the decimal point. User configuration of these values SHOULD also be
1551 limited in this fashion.
1553 qvalue = ( "0" [ "." 0*3DIGIT ] )
1554 | ( "1" [ "." 0*3("0") ] )
1556 "Quality values" is a misnomer, since these values merely represent
1557 relative degradation in desired quality.
1561 A language tag identifies a natural language spoken, written, or
1562 otherwise conveyed by human beings for communication of information
1563 to other human beings. Computer languages are explicitly excluded.
1564 HTTP uses language tags within the Accept-Language and Content-
1570 Fielding, et. al. Standards Track [Page 28]
1572 RFC 2068 HTTP/1.1 January 1997
1575 The syntax and registry of HTTP language tags is the same as that
1576 defined by RFC 1766 [1]. In summary, a language tag is composed of 1
1577 or more parts: A primary language tag and a possibly empty series of
1580 language-tag = primary-tag *( "-" subtag )
1582 primary-tag = 1*8ALPHA
1585 Whitespace is not allowed within the tag and all tags are case-
1586 insensitive. The name space of language tags is administered by the
1587 IANA. Example tags include:
1589 en, en-US, en-cockney, i-cherokee, x-pig-latin
1591 where any two-letter primary-tag is an ISO 639 language abbreviation
1592 and any two-letter initial subtag is an ISO 3166 country code. (The
1593 last three tags above are not registered tags; all but the last are
1594 examples of tags which could be registered in future.)
1598 Entity tags are used for comparing two or more entities from the same
1599 requested resource. HTTP/1.1 uses entity tags in the ETag (section
1600 14.20), If-Match (section 14.25), If-None-Match (section 14.26), and
1601 If-Range (section 14.27) header fields. The definition of how they
1602 are used and compared as cache validators is in section 13.3.3. An
1603 entity tag consists of an opaque quoted string, possibly prefixed by
1604 a weakness indicator.
1606 entity-tag = [ weak ] opaque-tag
1609 opaque-tag = quoted-string
1611 A "strong entity tag" may be shared by two entities of a resource
1612 only if they are equivalent by octet equality.
1614 A "weak entity tag," indicated by the "W/" prefix, may be shared by
1615 two entities of a resource only if the entities are equivalent and
1616 could be substituted for each other with no significant change in
1617 semantics. A weak entity tag can only be used for weak comparison.
1619 An entity tag MUST be unique across all versions of all entities
1620 associated with a particular resource. A given entity tag value may
1621 be used for entities obtained by requests on different URIs without
1622 implying anything about the equivalence of those entities.
1626 Fielding, et. al. Standards Track [Page 29]
1628 RFC 2068 HTTP/1.1 January 1997
1633 HTTP/1.1 allows a client to request that only part (a range of) the
1634 response entity be included within the response. HTTP/1.1 uses range
1635 units in the Range (section 14.36) and Content-Range (section 14.17)
1636 header fields. An entity may be broken down into subranges according
1637 to various structural units.
1639 range-unit = bytes-unit | other-range-unit
1641 bytes-unit = "bytes"
1642 other-range-unit = token
1644 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
1645 implementations may ignore ranges specified using other units.
1646 HTTP/1.1 has been designed to allow implementations of applications
1647 that do not depend on knowledge of ranges.
1653 HTTP messages consist of requests from client to server and responses
1654 from server to client.
1656 HTTP-message = Request | Response ; HTTP/1.1 messages
1658 Request (section 5) and Response (section 6) messages use the generic
1659 message format of RFC 822 [9] for transferring entities (the payload
1660 of the message). Both types of message consist of a start-line, one
1661 or more header fields (also known as "headers"), an empty line (i.e.,
1662 a line with nothing preceding the CRLF) indicating the end of the
1663 header fields, and an optional message-body.
1665 generic-message = start-line
1670 start-line = Request-Line | Status-Line
1672 In the interest of robustness, servers SHOULD ignore any empty
1673 line(s) received where a Request-Line is expected. In other words, if
1674 the server is reading the protocol stream at the beginning of a
1675 message and receives a CRLF first, it should ignore the CRLF.
1682 Fielding, et. al. Standards Track [Page 30]
1684 RFC 2068 HTTP/1.1 January 1997
1687 Note: certain buggy HTTP/1.0 client implementations generate an
1688 extra CRLF's after a POST request. To restate what is explicitly
1689 forbidden by the BNF, an HTTP/1.1 client must not preface or follow
1690 a request with an extra CRLF.
1694 HTTP header fields, which include general-header (section 4.5),
1695 request-header (section 5.3), response-header (section 6.2), and
1696 entity-header (section 7.1) fields, follow the same generic format as
1697 that given in Section 3.1 of RFC 822 [9]. Each header field consists
1698 of a name followed by a colon (":") and the field value. Field names
1699 are case-insensitive. The field value may be preceded by any amount
1700 of LWS, though a single SP is preferred. Header fields can be
1701 extended over multiple lines by preceding each extra line with at
1702 least one SP or HT. Applications SHOULD follow "common form" when
1703 generating HTTP constructs, since there might exist some
1704 implementations that fail to accept anything beyond the common forms.
1706 message-header = field-name ":" [ field-value ] CRLF
1709 field-value = *( field-content | LWS )
1711 field-content = <the OCTETs making up the field-value
1712 and consisting of either *TEXT or combinations
1713 of token, tspecials, and quoted-string>
1715 The order in which header fields with differing field names are
1716 received is not significant. However, it is "good practice" to send
1717 general-header fields first, followed by request-header or response-
1718 header fields, and ending with the entity-header fields.
1720 Multiple message-header fields with the same field-name may be
1721 present in a message if and only if the entire field-value for that
1722 header field is defined as a comma-separated list [i.e., #(values)].
1723 It MUST be possible to combine the multiple header fields into one
1724 "field-name: field-value" pair, without changing the semantics of the
1725 message, by appending each subsequent field-value to the first, each
1726 separated by a comma. The order in which header fields with the same
1727 field-name are received is therefore significant to the
1728 interpretation of the combined field value, and thus a proxy MUST NOT
1729 change the order of these field values when a message is forwarded.
1738 Fielding, et. al. Standards Track [Page 31]
1740 RFC 2068 HTTP/1.1 January 1997
1745 The message-body (if any) of an HTTP message is used to carry the
1746 entity-body associated with the request or response. The message-body
1747 differs from the entity-body only when a transfer coding has been
1748 applied, as indicated by the Transfer-Encoding header field (section
1751 message-body = entity-body
1752 | <entity-body encoded as per Transfer-Encoding>
1754 Transfer-Encoding MUST be used to indicate any transfer codings
1755 applied by an application to ensure safe and proper transfer of the
1756 message. Transfer-Encoding is a property of the message, not of the
1757 entity, and thus can be added or removed by any application along the
1758 request/response chain.
1760 The rules for when a message-body is allowed in a message differ for
1761 requests and responses.
1763 The presence of a message-body in a request is signaled by the
1764 inclusion of a Content-Length or Transfer-Encoding header field in
1765 the request's message-headers. A message-body MAY be included in a
1766 request only when the request method (section 5.1.1) allows an
1769 For response messages, whether or not a message-body is included with
1770 a message is dependent on both the request method and the response
1771 status code (section 6.1.1). All responses to the HEAD request method
1772 MUST NOT include a message-body, even though the presence of entity-
1773 header fields might lead one to believe they do. All 1xx
1774 (informational), 204 (no content), and 304 (not modified) responses
1775 MUST NOT include a message-body. All other responses do include a
1776 message-body, although it may be of zero length.
1780 When a message-body is included with a message, the length of that
1781 body is determined by one of the following (in order of precedence):
1783 1. Any response message which MUST NOT include a message-body
1784 (such as the 1xx, 204, and 304 responses and any response to a HEAD
1785 request) is always terminated by the first empty line after the
1786 header fields, regardless of the entity-header fields present in the
1789 2. If a Transfer-Encoding header field (section 14.40) is present and
1790 indicates that the "chunked" transfer coding has been applied, then
1794 Fielding, et. al. Standards Track [Page 32]
1796 RFC 2068 HTTP/1.1 January 1997
1799 the length is defined by the chunked encoding (section 3.6).
1801 3. If a Content-Length header field (section 14.14) is present, its
1802 value in bytes represents the length of the message-body.
1804 4. If the message uses the media type "multipart/byteranges", which is
1805 self-delimiting, then that defines the length. This media type MUST
1806 NOT be used unless the sender knows that the recipient can parse it;
1807 the presence in a request of a Range header with multiple byte-range
1808 specifiers implies that the client can parse multipart/byteranges
1811 5. By the server closing the connection. (Closing the connection
1812 cannot be used to indicate the end of a request body, since that
1813 would leave no possibility for the server to send back a response.)
1815 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
1816 containing a message-body MUST include a valid Content-Length header
1817 field unless the server is known to be HTTP/1.1 compliant. If a
1818 request contains a message-body and a Content-Length is not given,
1819 the server SHOULD respond with 400 (bad request) if it cannot
1820 determine the length of the message, or with 411 (length required) if
1821 it wishes to insist on receiving a valid Content-Length.
1823 All HTTP/1.1 applications that receive entities MUST accept the
1824 "chunked" transfer coding (section 3.6), thus allowing this mechanism
1825 to be used for messages when the message length cannot be determined
1828 Messages MUST NOT include both a Content-Length header field and the
1829 "chunked" transfer coding. If both are received, the Content-Length
1832 When a Content-Length is given in a message where a message-body is
1833 allowed, its field value MUST exactly match the number of OCTETs in
1834 the message-body. HTTP/1.1 user agents MUST notify the user when an
1835 invalid length is received and detected.
1850 Fielding, et. al. Standards Track [Page 33]
1852 RFC 2068 HTTP/1.1 January 1997
1855 4.5 General Header Fields
1857 There are a few header fields which have general applicability for
1858 both request and response messages, but which do not apply to the
1859 entity being transferred. These header fields apply only to the
1860 message being transmitted.
1862 general-header = Cache-Control ; Section 14.9
1863 | Connection ; Section 14.10
1864 | Date ; Section 14.19
1865 | Pragma ; Section 14.32
1866 | Transfer-Encoding ; Section 14.40
1867 | Upgrade ; Section 14.41
1868 | Via ; Section 14.44
1870 General-header field names can be extended reliably only in
1871 combination with a change in the protocol version. However, new or
1872 experimental header fields may be given the semantics of general
1873 header fields if all parties in the communication recognize them to
1874 be general-header fields. Unrecognized header fields are treated as
1875 entity-header fields.
1879 A request message from a client to a server includes, within the
1880 first line of that message, the method to be applied to the resource,
1881 the identifier of the resource, and the protocol version in use.
1883 Request = Request-Line ; Section 5.1
1884 *( general-header ; Section 4.5
1885 | request-header ; Section 5.3
1886 | entity-header ) ; Section 7.1
1888 [ message-body ] ; Section 7.2
1892 The Request-Line begins with a method token, followed by the
1893 Request-URI and the protocol version, and ending with CRLF. The
1894 elements are separated by SP characters. No CR or LF are allowed
1895 except in the final CRLF sequence.
1897 Request-Line = Method SP Request-URI SP HTTP-Version CRLF
1906 Fielding, et. al. Standards Track [Page 34]
1908 RFC 2068 HTTP/1.1 January 1997
1913 The Method token indicates the method to be performed on the resource
1914 identified by the Request-URI. The method is case-sensitive.
1916 Method = "OPTIONS" ; Section 9.2
1917 | "GET" ; Section 9.3
1918 | "HEAD" ; Section 9.4
1919 | "POST" ; Section 9.5
1920 | "PUT" ; Section 9.6
1921 | "DELETE" ; Section 9.7
1922 | "TRACE" ; Section 9.8
1925 extension-method = token
1927 The list of methods allowed by a resource can be specified in an
1928 Allow header field (section 14.7). The return code of the response
1929 always notifies the client whether a method is currently allowed on a
1930 resource, since the set of allowed methods can change dynamically.
1931 Servers SHOULD return the status code 405 (Method Not Allowed) if the
1932 method is known by the server but not allowed for the requested
1933 resource, and 501 (Not Implemented) if the method is unrecognized or
1934 not implemented by the server. The list of methods known by a server
1935 can be listed in a Public response-header field (section 14.35).
1937 The methods GET and HEAD MUST be supported by all general-purpose
1938 servers. All other methods are optional; however, if the above
1939 methods are implemented, they MUST be implemented with the same
1940 semantics as those specified in section 9.
1944 The Request-URI is a Uniform Resource Identifier (section 3.2) and
1945 identifies the resource upon which to apply the request.
1947 Request-URI = "*" | absoluteURI | abs_path
1949 The three options for Request-URI are dependent on the nature of the
1950 request. The asterisk "*" means that the request does not apply to a
1951 particular resource, but to the server itself, and is only allowed
1952 when the method used does not necessarily apply to a resource. One
1957 The absoluteURI form is required when the request is being made to a
1958 proxy. The proxy is requested to forward the request or service it
1962 Fielding, et. al. Standards Track [Page 35]
1964 RFC 2068 HTTP/1.1 January 1997
1967 from a valid cache, and return the response. Note that the proxy MAY
1968 forward the request on to another proxy or directly to the server
1969 specified by the absoluteURI. In order to avoid request loops, a
1970 proxy MUST be able to recognize all of its server names, including
1971 any aliases, local variations, and the numeric IP address. An example
1972 Request-Line would be:
1974 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
1976 To allow for transition to absoluteURIs in all requests in future
1977 versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
1978 form in requests, even though HTTP/1.1 clients will only generate
1979 them in requests to proxies.
1981 The most common form of Request-URI is that used to identify a
1982 resource on an origin server or gateway. In this case the absolute
1983 path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
1984 the Request-URI, and the network location of the URI (net_loc) MUST
1985 be transmitted in a Host header field. For example, a client wishing
1986 to retrieve the resource above directly from the origin server would
1987 create a TCP connection to port 80 of the host "www.w3.org" and send
1990 GET /pub/WWW/TheProject.html HTTP/1.1
1993 followed by the remainder of the Request. Note that the absolute path
1994 cannot be empty; if none is present in the original URI, it MUST be
1995 given as "/" (the server root).
1997 If a proxy receives a request without any path in the Request-URI and
1998 the method specified is capable of supporting the asterisk form of
1999 request, then the last proxy on the request chain MUST forward the
2000 request with "*" as the final Request-URI. For example, the request
2002 OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
2004 would be forwarded by the proxy as
2007 Host: www.ics.uci.edu:8001
2009 after connecting to port 8001 of host "www.ics.uci.edu".
2011 The Request-URI is transmitted in the format specified in section
2012 3.2.1. The origin server MUST decode the Request-URI in order to
2013 properly interpret the request. Servers SHOULD respond to invalid
2014 Request-URIs with an appropriate status code.
2018 Fielding, et. al. Standards Track [Page 36]
2020 RFC 2068 HTTP/1.1 January 1997
2023 In requests that they forward, proxies MUST NOT rewrite the
2024 "abs_path" part of a Request-URI in any way except as noted above to
2025 replace a null abs_path with "*", no matter what the proxy does in
2026 its internal implementation.
2028 Note: The "no rewrite" rule prevents the proxy from changing the
2029 meaning of the request when the origin server is improperly using a
2030 non-reserved URL character for a reserved purpose. Implementers
2031 should be aware that some pre-HTTP/1.1 proxies have been known to
2032 rewrite the Request-URI.
2034 5.2 The Resource Identified by a Request
2036 HTTP/1.1 origin servers SHOULD be aware that the exact resource
2037 identified by an Internet request is determined by examining both the
2038 Request-URI and the Host header field.
2040 An origin server that does not allow resources to differ by the
2041 requested host MAY ignore the Host header field value. (But see
2042 section 19.5.1 for other requirements on Host support in HTTP/1.1.)
2044 An origin server that does differentiate resources based on the host
2045 requested (sometimes referred to as virtual hosts or vanity
2046 hostnames) MUST use the following rules for determining the requested
2047 resource on an HTTP/1.1 request:
2049 1. If Request-URI is an absoluteURI, the host is part of the
2050 Request-URI. Any Host header field value in the request MUST be
2053 2. If the Request-URI is not an absoluteURI, and the request
2054 includes a Host header field, the host is determined by the Host
2057 3. If the host as determined by rule 1 or 2 is not a valid host on
2058 the server, the response MUST be a 400 (Bad Request) error
2061 Recipients of an HTTP/1.0 request that lacks a Host header field MAY
2062 attempt to use heuristics (e.g., examination of the URI path for
2063 something unique to a particular host) in order to determine what
2064 exact resource is being requested.
2066 5.3 Request Header Fields
2068 The request-header fields allow the client to pass additional
2069 information about the request, and about the client itself, to the
2070 server. These fields act as request modifiers, with semantics
2074 Fielding, et. al. Standards Track [Page 37]
2076 RFC 2068 HTTP/1.1 January 1997
2079 equivalent to the parameters on a programming language method
2082 request-header = Accept ; Section 14.1
2083 | Accept-Charset ; Section 14.2
2084 | Accept-Encoding ; Section 14.3
2085 | Accept-Language ; Section 14.4
2086 | Authorization ; Section 14.8
2087 | From ; Section 14.22
2088 | Host ; Section 14.23
2089 | If-Modified-Since ; Section 14.24
2090 | If-Match ; Section 14.25
2091 | If-None-Match ; Section 14.26
2092 | If-Range ; Section 14.27
2093 | If-Unmodified-Since ; Section 14.28
2094 | Max-Forwards ; Section 14.31
2095 | Proxy-Authorization ; Section 14.34
2096 | Range ; Section 14.36
2097 | Referer ; Section 14.37
2098 | User-Agent ; Section 14.42
2100 Request-header field names can be extended reliably only in
2101 combination with a change in the protocol version. However, new or
2102 experimental header fields MAY be given the semantics of request-
2103 header fields if all parties in the communication recognize them to
2104 be request-header fields. Unrecognized header fields are treated as
2105 entity-header fields.
2109 After receiving and interpreting a request message, a server responds
2110 with an HTTP response message.
2112 Response = Status-Line ; Section 6.1
2113 *( general-header ; Section 4.5
2114 | response-header ; Section 6.2
2115 | entity-header ) ; Section 7.1
2117 [ message-body ] ; Section 7.2
2121 The first line of a Response message is the Status-Line, consisting
2122 of the protocol version followed by a numeric status code and its
2123 associated textual phrase, with each element separated by SP
2124 characters. No CR or LF is allowed except in the final CRLF
2130 Fielding, et. al. Standards Track [Page 38]
2132 RFC 2068 HTTP/1.1 January 1997
2135 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
2137 6.1.1 Status Code and Reason Phrase
2139 The Status-Code element is a 3-digit integer result code of the
2140 attempt to understand and satisfy the request. These codes are fully
2141 defined in section 10. The Reason-Phrase is intended to give a short
2142 textual description of the Status-Code. The Status-Code is intended
2143 for use by automata and the Reason-Phrase is intended for the human
2144 user. The client is not required to examine or display the Reason-
2147 The first digit of the Status-Code defines the class of response. The
2148 last two digits do not have any categorization role. There are 5
2149 values for the first digit:
2151 o 1xx: Informational - Request received, continuing process
2153 o 2xx: Success - The action was successfully received, understood,
2156 o 3xx: Redirection - Further action must be taken in order to
2157 complete the request
2159 o 4xx: Client Error - The request contains bad syntax or cannot be
2162 o 5xx: Server Error - The server failed to fulfill an apparently
2165 The individual values of the numeric status codes defined for
2166 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
2167 presented below. The reason phrases listed here are only recommended
2168 -- they may be replaced by local equivalents without affecting the
2171 Status-Code = "100" ; Continue
2172 | "101" ; Switching Protocols
2176 | "203" ; Non-Authoritative Information
2177 | "204" ; No Content
2178 | "205" ; Reset Content
2179 | "206" ; Partial Content
2180 | "300" ; Multiple Choices
2181 | "301" ; Moved Permanently
2182 | "302" ; Moved Temporarily
2186 Fielding, et. al. Standards Track [Page 39]
2188 RFC 2068 HTTP/1.1 January 1997
2192 | "304" ; Not Modified
2194 | "400" ; Bad Request
2195 | "401" ; Unauthorized
2196 | "402" ; Payment Required
2199 | "405" ; Method Not Allowed
2200 | "406" ; Not Acceptable
2201 | "407" ; Proxy Authentication Required
2202 | "408" ; Request Time-out
2205 | "411" ; Length Required
2206 | "412" ; Precondition Failed
2207 | "413" ; Request Entity Too Large
2208 | "414" ; Request-URI Too Large
2209 | "415" ; Unsupported Media Type
2210 | "500" ; Internal Server Error
2211 | "501" ; Not Implemented
2212 | "502" ; Bad Gateway
2213 | "503" ; Service Unavailable
2214 | "504" ; Gateway Time-out
2215 | "505" ; HTTP Version not supported
2218 extension-code = 3DIGIT
2220 Reason-Phrase = *<TEXT, excluding CR, LF>
2222 HTTP status codes are extensible. HTTP applications are not required
2223 to understand the meaning of all registered status codes, though such
2224 understanding is obviously desirable. However, applications MUST
2225 understand the class of any status code, as indicated by the first
2226 digit, and treat any unrecognized response as being equivalent to the
2227 x00 status code of that class, with the exception that an
2228 unrecognized response MUST NOT be cached. For example, if an
2229 unrecognized status code of 431 is received by the client, it can
2230 safely assume that there was something wrong with its request and
2231 treat the response as if it had received a 400 status code. In such
2232 cases, user agents SHOULD present to the user the entity returned
2233 with the response, since that entity is likely to include human-
2234 readable information which will explain the unusual status.
2242 Fielding, et. al. Standards Track [Page 40]
2244 RFC 2068 HTTP/1.1 January 1997
2247 6.2 Response Header Fields
2249 The response-header fields allow the server to pass additional
2250 information about the response which cannot be placed in the Status-
2251 Line. These header fields give information about the server and about
2252 further access to the resource identified by the Request-URI.
2254 response-header = Age ; Section 14.6
2255 | Location ; Section 14.30
2256 | Proxy-Authenticate ; Section 14.33
2257 | Public ; Section 14.35
2258 | Retry-After ; Section 14.38
2259 | Server ; Section 14.39
2260 | Vary ; Section 14.43
2261 | Warning ; Section 14.45
2262 | WWW-Authenticate ; Section 14.46
2264 Response-header field names can be extended reliably only in
2265 combination with a change in the protocol version. However, new or
2266 experimental header fields MAY be given the semantics of response-
2267 header fields if all parties in the communication recognize them to
2268 be response-header fields. Unrecognized header fields are treated as
2269 entity-header fields.
2273 Request and Response messages MAY transfer an entity if not otherwise
2274 restricted by the request method or response status code. An entity
2275 consists of entity-header fields and an entity-body, although some
2276 responses will only include the entity-headers.
2278 In this section, both sender and recipient refer to either the client
2279 or the server, depending on who sends and who receives the entity.
2281 7.1 Entity Header Fields
2283 Entity-header fields define optional metainformation about the
2284 entity-body or, if no body is present, about the resource identified
2298 Fielding, et. al. Standards Track [Page 41]
2300 RFC 2068 HTTP/1.1 January 1997
2303 entity-header = Allow ; Section 14.7
2304 | Content-Base ; Section 14.11
2305 | Content-Encoding ; Section 14.12
2306 | Content-Language ; Section 14.13
2307 | Content-Length ; Section 14.14
2308 | Content-Location ; Section 14.15
2309 | Content-MD5 ; Section 14.16
2310 | Content-Range ; Section 14.17
2311 | Content-Type ; Section 14.18
2312 | ETag ; Section 14.20
2313 | Expires ; Section 14.21
2314 | Last-Modified ; Section 14.29
2317 extension-header = message-header
2319 The extension-header mechanism allows additional entity-header fields
2320 to be defined without changing the protocol, but these fields cannot
2321 be assumed to be recognizable by the recipient. Unrecognized header
2322 fields SHOULD be ignored by the recipient and forwarded by proxies.
2326 The entity-body (if any) sent with an HTTP request or response is in
2327 a format and encoding defined by the entity-header fields.
2329 entity-body = *OCTET
2331 An entity-body is only present in a message when a message-body is
2332 present, as described in section 4.3. The entity-body is obtained
2333 from the message-body by decoding any Transfer-Encoding that may have
2334 been applied to ensure safe and proper transfer of the message.
2338 When an entity-body is included with a message, the data type of that
2339 body is determined via the header fields Content-Type and Content-
2340 Encoding. These define a two-layer, ordered encoding model:
2342 entity-body := Content-Encoding( Content-Type( data ) )
2344 Content-Type specifies the media type of the underlying data.
2345 Content-Encoding may be used to indicate any additional content
2346 codings applied to the data, usually for the purpose of data
2347 compression, that are a property of the requested resource. There is
2348 no default encoding.
2354 Fielding, et. al. Standards Track [Page 42]
2356 RFC 2068 HTTP/1.1 January 1997
2359 Any HTTP/1.1 message containing an entity-body SHOULD include a
2360 Content-Type header field defining the media type of that body. If
2361 and only if the media type is not given by a Content-Type field, the
2362 recipient MAY attempt to guess the media type via inspection of its
2363 content and/or the name extension(s) of the URL used to identify the
2364 resource. If the media type remains unknown, the recipient SHOULD
2365 treat it as type "application/octet-stream".
2369 The length of an entity-body is the length of the message-body after
2370 any transfer codings have been removed. Section 4.4 defines how the
2371 length of a message-body is determined.
2375 8.1 Persistent Connections
2379 Prior to persistent connections, a separate TCP connection was
2380 established to fetch each URL, increasing the load on HTTP servers
2381 and causing congestion on the Internet. The use of inline images and
2382 other associated data often requires a client to make multiple
2383 requests of the same server in a short amount of time. Analyses of
2384 these performance problems are available [30][27]; analysis and
2385 results from a prototype implementation are in [26].
2387 Persistent HTTP connections have a number of advantages:
2389 o By opening and closing fewer TCP connections, CPU time is saved,
2390 and memory used for TCP protocol control blocks is also saved.
2391 o HTTP requests and responses can be pipelined on a connection.
2392 Pipelining allows a client to make multiple requests without
2393 waiting for each response, allowing a single TCP connection to be
2394 used much more efficiently, with much lower elapsed time.
2395 o Network congestion is reduced by reducing the number of packets
2396 caused by TCP opens, and by allowing TCP sufficient time to
2397 determine the congestion state of the network.
2398 o HTTP can evolve more gracefully; since errors can be reported
2399 without the penalty of closing the TCP connection. Clients using
2400 future versions of HTTP might optimistically try a new feature, but
2401 if communicating with an older server, retry with old semantics
2402 after an error is reported.
2404 HTTP implementations SHOULD implement persistent connections.
2410 Fielding, et. al. Standards Track [Page 43]
2412 RFC 2068 HTTP/1.1 January 1997
2415 8.1.2 Overall Operation
2417 A significant difference between HTTP/1.1 and earlier versions of
2418 HTTP is that persistent connections are the default behavior of any
2419 HTTP connection. That is, unless otherwise indicated, the client may
2420 assume that the server will maintain a persistent connection.
2422 Persistent connections provide a mechanism by which a client and a
2423 server can signal the close of a TCP connection. This signaling takes
2424 place using the Connection header field. Once a close has been
2425 signaled, the client MUST not send any more requests on that
2430 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2431 maintain a persistent connection unless a Connection header including
2432 the connection-token "close" was sent in the request. If the server
2433 chooses to close the connection immediately after sending the
2434 response, it SHOULD send a Connection header including the
2435 connection-token close.
2437 An HTTP/1.1 client MAY expect a connection to remain open, but would
2438 decide to keep it open based on whether the response from a server
2439 contains a Connection header with the connection-token close. In case
2440 the client does not want to maintain a connection for more than that
2441 request, it SHOULD send a Connection header including the
2442 connection-token close.
2444 If either the client or the server sends the close token in the
2445 Connection header, that request becomes the last one for the
2448 Clients and servers SHOULD NOT assume that a persistent connection is
2449 maintained for HTTP versions less than 1.1 unless it is explicitly
2450 signaled. See section 19.7.1 for more information on backwards
2451 compatibility with HTTP/1.0 clients.
2453 In order to remain persistent, all messages on the connection must
2454 have a self-defined message length (i.e., one not defined by closure
2455 of the connection), as described in section 4.4.
2459 A client that supports persistent connections MAY "pipeline" its
2460 requests (i.e., send multiple requests without waiting for each
2461 response). A server MUST send its responses to those requests in the
2462 same order that the requests were received.
2466 Fielding, et. al. Standards Track [Page 44]
2468 RFC 2068 HTTP/1.1 January 1997
2471 Clients which assume persistent connections and pipeline immediately
2472 after connection establishment SHOULD be prepared to retry their
2473 connection if the first pipelined attempt fails. If a client does
2474 such a retry, it MUST NOT pipeline before it knows the connection is
2475 persistent. Clients MUST also be prepared to resend their requests if
2476 the server closes the connection before sending all of the
2477 corresponding responses.
2481 It is especially important that proxies correctly implement the
2482 properties of the Connection header field as specified in 14.2.1.
2484 The proxy server MUST signal persistent connections separately with
2485 its clients and the origin servers (or other proxy servers) that it
2486 connects to. Each persistent connection applies to only one transport
2489 A proxy server MUST NOT establish a persistent connection with an
2492 8.1.4 Practical Considerations
2494 Servers will usually have some time-out value beyond which they will
2495 no longer maintain an inactive connection. Proxy servers might make
2496 this a higher value since it is likely that the client will be making
2497 more connections through the same server. The use of persistent
2498 connections places no requirements on the length of this time-out for
2499 either the client or the server.
2501 When a client or server wishes to time-out it SHOULD issue a graceful
2502 close on the transport connection. Clients and servers SHOULD both
2503 constantly watch for the other side of the transport close, and
2504 respond to it as appropriate. If a client or server does not detect
2505 the other side's close promptly it could cause unnecessary resource
2506 drain on the network.
2508 A client, server, or proxy MAY close the transport connection at any
2509 time. For example, a client MAY have started to send a new request at
2510 the same time that the server has decided to close the "idle"
2511 connection. From the server's point of view, the connection is being
2512 closed while it was idle, but from the client's point of view, a
2513 request is in progress.
2515 This means that clients, servers, and proxies MUST be able to recover
2516 from asynchronous close events. Client software SHOULD reopen the
2517 transport connection and retransmit the aborted request without user
2518 interaction so long as the request method is idempotent (see section
2522 Fielding, et. al. Standards Track [Page 45]
2524 RFC 2068 HTTP/1.1 January 1997
2527 9.1.2); other methods MUST NOT be automatically retried, although
2528 user agents MAY offer a human operator the choice of retrying the
2531 However, this automatic retry SHOULD NOT be repeated if the second
2534 Servers SHOULD always respond to at least one request per connection,
2535 if at all possible. Servers SHOULD NOT close a connection in the
2536 middle of transmitting a response, unless a network or client failure
2539 Clients that use persistent connections SHOULD limit the number of
2540 simultaneous connections that they maintain to a given server. A
2541 single-user client SHOULD maintain AT MOST 2 connections with any
2542 server or proxy. A proxy SHOULD use up to 2*N connections to another
2543 server or proxy, where N is the number of simultaneously active
2544 users. These guidelines are intended to improve HTTP response times
2545 and avoid congestion of the Internet or other networks.
2547 8.2 Message Transmission Requirements
2549 General requirements:
2551 o HTTP/1.1 servers SHOULD maintain persistent connections and use
2552 TCP's flow control mechanisms to resolve temporary overloads,
2553 rather than terminating connections with the expectation that
2554 clients will retry. The latter technique can exacerbate network
2557 o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
2558 the network connection for an error status while it is transmitting
2559 the request. If the client sees an error status, it SHOULD
2560 immediately cease transmitting the body. If the body is being sent
2561 using a "chunked" encoding (section 3.6), a zero length chunk and
2562 empty footer MAY be used to prematurely mark the end of the
2563 message. If the body was preceded by a Content-Length header, the
2564 client MUST close the connection.
2566 o An HTTP/1.1 (or later) client MUST be prepared to accept a 100
2567 (Continue) status followed by a regular response.
2569 o An HTTP/1.1 (or later) server that receives a request from a
2570 HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
2571 response; it SHOULD either wait for the request to be completed
2572 normally (thus avoiding an interrupted request) or close the
2573 connection prematurely.
2578 Fielding, et. al. Standards Track [Page 46]
2580 RFC 2068 HTTP/1.1 January 1997
2583 Upon receiving a method subject to these requirements from an
2584 HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
2585 respond with 100 (Continue) status and continue to read from the
2586 input stream, or respond with an error status. If it responds with an
2587 error status, it MAY close the transport (TCP) connection or it MAY
2588 continue to read and discard the rest of the request. It MUST NOT
2589 perform the requested method if it returns an error status.
2591 Clients SHOULD remember the version number of at least the most
2592 recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
2593 later response from the server, and it sees the connection close
2594 before receiving any status from the server, the client SHOULD retry
2595 the request without user interaction so long as the request method is
2596 idempotent (see section 9.1.2); other methods MUST NOT be
2597 automatically retried, although user agents MAY offer a human
2598 operator the choice of retrying the request.. If the client does
2599 retry the request, the client
2601 o MUST first send the request header fields, and then
2603 o MUST wait for the server to respond with either a 100 (Continue)
2604 response, in which case the client should continue, or with an
2607 If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
2608 the server, it should assume that the server implements HTTP/1.0 or
2609 older and will not use the 100 (Continue) response. If in this case
2610 the client sees the connection close before receiving any status from
2611 the server, the client SHOULD retry the request. If the client does
2612 retry the request to this HTTP/1.0 server, it should use the
2613 following "binary exponential backoff" algorithm to be assured of
2614 obtaining a reliable response:
2616 1. Initiate a new connection to the server
2618 2. Transmit the request-headers
2620 3. Initialize a variable R to the estimated round-trip time to the
2621 server (e.g., based on the time it took to establish the
2622 connection), or to a constant value of 5 seconds if the round-trip
2623 time is not available.
2625 4. Compute T = R * (2**N), where N is the number of previous retries
2628 5. Wait either for an error response from the server, or for T seconds
2629 (whichever comes first)
2634 Fielding, et. al. Standards Track [Page 47]
2636 RFC 2068 HTTP/1.1 January 1997
2639 6. If no error response is received, after T seconds transmit the body
2642 7. If client sees that the connection is closed prematurely, repeat
2643 from step 1 until the request is accepted, an error response is
2644 received, or the user becomes impatient and terminates the retry
2647 No matter what the server version, if an error status is received,
2650 o MUST NOT continue and
2652 o MUST close the connection if it has not completed sending the
2655 An HTTP/1.1 (or later) client that sees the connection close after
2656 receiving a 100 (Continue) but before receiving any other status
2657 SHOULD retry the request, and need not wait for 100 (Continue)
2658 response (but MAY do so if this simplifies the implementation).
2660 9 Method Definitions
2662 The set of common methods for HTTP/1.1 is defined below. Although
2663 this set can be expanded, additional methods cannot be assumed to
2664 share the same semantics for separately extended clients and servers.
2666 The Host request-header field (section 14.23) MUST accompany all
2669 9.1 Safe and Idempotent Methods
2673 Implementers should be aware that the software represents the user in
2674 their interactions over the Internet, and should be careful to allow
2675 the user to be aware of any actions they may take which may have an
2676 unexpected significance to themselves or others.
2678 In particular, the convention has been established that the GET and
2679 HEAD methods should never have the significance of taking an action
2680 other than retrieval. These methods should be considered "safe." This
2681 allows user agents to represent other methods, such as POST, PUT and
2682 DELETE, in a special way, so that the user is made aware of the fact
2683 that a possibly unsafe action is being requested.
2685 Naturally, it is not possible to ensure that the server does not
2686 generate side-effects as a result of performing a GET request; in
2690 Fielding, et. al. Standards Track [Page 48]
2692 RFC 2068 HTTP/1.1 January 1997
2695 fact, some dynamic resources consider that a feature. The important
2696 distinction here is that the user did not request the side-effects,
2697 so therefore cannot be held accountable for them.
2699 9.1.2 Idempotent Methods
2701 Methods may also have the property of "idempotence" in that (aside
2702 from error or expiration issues) the side-effects of N > 0 identical
2703 requests is the same as for a single request. The methods GET, HEAD,
2704 PUT and DELETE share this property.
2708 The OPTIONS method represents a request for information about the
2709 communication options available on the request/response chain
2710 identified by the Request-URI. This method allows the client to
2711 determine the options and/or requirements associated with a resource,
2712 or the capabilities of a server, without implying a resource action
2713 or initiating a resource retrieval.
2715 Unless the server's response is an error, the response MUST NOT
2716 include entity information other than what can be considered as
2717 communication options (e.g., Allow is appropriate, but Content-Type
2718 is not). Responses to this method are not cachable.
2720 If the Request-URI is an asterisk ("*"), the OPTIONS request is
2721 intended to apply to the server as a whole. A 200 response SHOULD
2722 include any header fields which indicate optional features
2723 implemented by the server (e.g., Public), including any extensions
2724 not defined by this specification, in addition to any applicable
2725 general or response-header fields. As described in section 5.1.2, an
2726 "OPTIONS *" request can be applied through a proxy by specifying the
2727 destination server in the Request-URI without any path information.
2729 If the Request-URI is not an asterisk, the OPTIONS request applies
2730 only to the options that are available when communicating with that
2731 resource. A 200 response SHOULD include any header fields which
2732 indicate optional features implemented by the server and applicable
2733 to that resource (e.g., Allow), including any extensions not defined
2734 by this specification, in addition to any applicable general or
2735 response-header fields. If the OPTIONS request passes through a
2736 proxy, the proxy MUST edit the response to exclude those options
2737 which apply to a proxy's capabilities and which are known to be
2738 unavailable through that proxy.
2746 Fielding, et. al. Standards Track [Page 49]
2748 RFC 2068 HTTP/1.1 January 1997
2753 The GET method means retrieve whatever information (in the form of an
2754 entity) is identified by the Request-URI. If the Request-URI refers
2755 to a data-producing process, it is the produced data which shall be
2756 returned as the entity in the response and not the source text of the
2757 process, unless that text happens to be the output of the process.
2759 The semantics of the GET method change to a "conditional GET" if the
2760 request message includes an If-Modified-Since, If-Unmodified-Since,
2761 If-Match, If-None-Match, or If-Range header field. A conditional GET
2762 method requests that the entity be transferred only under the
2763 circumstances described by the conditional header field(s). The
2764 conditional GET method is intended to reduce unnecessary network
2765 usage by allowing cached entities to be refreshed without requiring
2766 multiple requests or transferring data already held by the client.
2768 The semantics of the GET method change to a "partial GET" if the
2769 request message includes a Range header field. A partial GET requests
2770 that only part of the entity be transferred, as described in section
2771 14.36. The partial GET method is intended to reduce unnecessary
2772 network usage by allowing partially-retrieved entities to be
2773 completed without transferring data already held by the client.
2775 The response to a GET request is cachable if and only if it meets the
2776 requirements for HTTP caching described in section 13.
2780 The HEAD method is identical to GET except that the server MUST NOT
2781 return a message-body in the response. The metainformation contained
2782 in the HTTP headers in response to a HEAD request SHOULD be identical
2783 to the information sent in response to a GET request. This method can
2784 be used for obtaining metainformation about the entity implied by the
2785 request without transferring the entity-body itself. This method is
2786 often used for testing hypertext links for validity, accessibility,
2787 and recent modification.
2789 The response to a HEAD request may be cachable in the sense that the
2790 information contained in the response may be used to update a
2791 previously cached entity from that resource. If the new field values
2792 indicate that the cached entity differs from the current entity (as
2793 would be indicated by a change in Content-Length, Content-MD5, ETag
2794 or Last-Modified), then the cache MUST treat the cache entry as
2802 Fielding, et. al. Standards Track [Page 50]
2804 RFC 2068 HTTP/1.1 January 1997
2809 The POST method is used to request that the destination server accept
2810 the entity enclosed in the request as a new subordinate of the
2811 resource identified by the Request-URI in the Request-Line. POST is
2812 designed to allow a uniform method to cover the following functions:
2814 o Annotation of existing resources;
2816 o Posting a message to a bulletin board, newsgroup, mailing list,
2817 or similar group of articles;
2819 o Providing a block of data, such as the result of submitting a
2820 form, to a data-handling process;
2822 o Extending a database through an append operation.
2824 The actual function performed by the POST method is determined by the
2825 server and is usually dependent on the Request-URI. The posted entity
2826 is subordinate to that URI in the same way that a file is subordinate
2827 to a directory containing it, a news article is subordinate to a
2828 newsgroup to which it is posted, or a record is subordinate to a
2831 The action performed by the POST method might not result in a
2832 resource that can be identified by a URI. In this case, either 200
2833 (OK) or 204 (No Content) is the appropriate response status,
2834 depending on whether or not the response includes an entity that
2835 describes the result.
2837 If a resource has been created on the origin server, the response
2838 SHOULD be 201 (Created) and contain an entity which describes the
2839 status of the request and refers to the new resource, and a Location
2840 header (see section 14.30).
2842 Responses to this method are not cachable, unless the response
2843 includes appropriate Cache-Control or Expires header fields. However,
2844 the 303 (See Other) response can be used to direct the user agent to
2845 retrieve a cachable resource.
2847 POST requests must obey the message transmission requirements set out
2858 Fielding, et. al. Standards Track [Page 51]
2860 RFC 2068 HTTP/1.1 January 1997
2865 The PUT method requests that the enclosed entity be stored under the
2866 supplied Request-URI. If the Request-URI refers to an already
2867 existing resource, the enclosed entity SHOULD be considered as a
2868 modified version of the one residing on the origin server. If the
2869 Request-URI does not point to an existing resource, and that URI is
2870 capable of being defined as a new resource by the requesting user
2871 agent, the origin server can create the resource with that URI. If a
2872 new resource is created, the origin server MUST inform the user agent
2873 via the 201 (Created) response. If an existing resource is modified,
2874 either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
2875 to indicate successful completion of the request. If the resource
2876 could not be created or modified with the Request-URI, an appropriate
2877 error response SHOULD be given that reflects the nature of the
2878 problem. The recipient of the entity MUST NOT ignore any Content-*
2879 (e.g. Content-Range) headers that it does not understand or implement
2880 and MUST return a 501 (Not Implemented) response in such cases.
2882 If the request passes through a cache and the Request-URI identifies
2883 one or more currently cached entities, those entries should be
2884 treated as stale. Responses to this method are not cachable.
2886 The fundamental difference between the POST and PUT requests is
2887 reflected in the different meaning of the Request-URI. The URI in a
2888 POST request identifies the resource that will handle the enclosed
2889 entity. That resource may be a data-accepting process, a gateway to
2890 some other protocol, or a separate entity that accepts annotations.
2891 In contrast, the URI in a PUT request identifies the entity enclosed
2892 with the request -- the user agent knows what URI is intended and the
2893 server MUST NOT attempt to apply the request to some other resource.
2894 If the server desires that the request be applied to a different URI,
2895 it MUST send a 301 (Moved Permanently) response; the user agent MAY
2896 then make its own decision regarding whether or not to redirect the
2899 A single resource MAY be identified by many different URIs. For
2900 example, an article may have a URI for identifying "the current
2901 version" which is separate from the URI identifying each particular
2902 version. In this case, a PUT request on a general URI may result in
2903 several other URIs being defined by the origin server.
2905 HTTP/1.1 does not define how a PUT method affects the state of an
2908 PUT requests must obey the message transmission requirements set out
2914 Fielding, et. al. Standards Track [Page 52]
2916 RFC 2068 HTTP/1.1 January 1997
2921 The DELETE method requests that the origin server delete the resource
2922 identified by the Request-URI. This method MAY be overridden by human
2923 intervention (or other means) on the origin server. The client cannot
2924 be guaranteed that the operation has been carried out, even if the
2925 status code returned from the origin server indicates that the action
2926 has been completed successfully. However, the server SHOULD not
2927 indicate success unless, at the time the response is given, it
2928 intends to delete the resource or move it to an inaccessible
2931 A successful response SHOULD be 200 (OK) if the response includes an
2932 entity describing the status, 202 (Accepted) if the action has not
2933 yet been enacted, or 204 (No Content) if the response is OK but does
2934 not include an entity.
2936 If the request passes through a cache and the Request-URI identifies
2937 one or more currently cached entities, those entries should be
2938 treated as stale. Responses to this method are not cachable.
2942 The TRACE method is used to invoke a remote, application-layer loop-
2943 back of the request message. The final recipient of the request
2944 SHOULD reflect the message received back to the client as the
2945 entity-body of a 200 (OK) response. The final recipient is either the
2946 origin server or the first proxy or gateway to receive a Max-Forwards
2947 value of zero (0) in the request (see section 14.31). A TRACE request
2948 MUST NOT include an entity.
2950 TRACE allows the client to see what is being received at the other
2951 end of the request chain and use that data for testing or diagnostic
2952 information. The value of the Via header field (section 14.44) is of
2953 particular interest, since it acts as a trace of the request chain.
2954 Use of the Max-Forwards header field allows the client to limit the
2955 length of the request chain, which is useful for testing a chain of
2956 proxies forwarding messages in an infinite loop.
2958 If successful, the response SHOULD contain the entire request message
2959 in the entity-body, with a Content-Type of "message/http". Responses
2960 to this method MUST NOT be cached.
2962 10 Status Code Definitions
2964 Each Status-Code is described below, including a description of which
2965 method(s) it can follow and any metainformation required in the
2970 Fielding, et. al. Standards Track [Page 53]
2972 RFC 2068 HTTP/1.1 January 1997
2975 10.1 Informational 1xx
2977 This class of status code indicates a provisional response,
2978 consisting only of the Status-Line and optional headers, and is
2979 terminated by an empty line. Since HTTP/1.0 did not define any 1xx
2980 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
2981 client except under experimental conditions.
2985 The client may continue with its request. This interim response is
2986 used to inform the client that the initial part of the request has
2987 been received and has not yet been rejected by the server. The client
2988 SHOULD continue by sending the remainder of the request or, if the
2989 request has already been completed, ignore this response. The server
2990 MUST send a final response after the request has been completed.
2992 10.1.2 101 Switching Protocols
2994 The server understands and is willing to comply with the client's
2995 request, via the Upgrade message header field (section 14.41), for a
2996 change in the application protocol being used on this connection. The
2997 server will switch protocols to those defined by the response's
2998 Upgrade header field immediately after the empty line which
2999 terminates the 101 response.
3001 The protocol should only be switched when it is advantageous to do
3002 so. For example, switching to a newer version of HTTP is
3003 advantageous over older versions, and switching to a real-time,
3004 synchronous protocol may be advantageous when delivering resources
3005 that use such features.
3009 This class of status code indicates that the client's request was
3010 successfully received, understood, and accepted.
3014 The request has succeeded. The information returned with the response
3015 is dependent on the method used in the request, for example:
3017 GET an entity corresponding to the requested resource is sent in the
3020 HEAD the entity-header fields corresponding to the requested resource
3021 are sent in the response without any message-body;
3026 Fielding, et. al. Standards Track [Page 54]
3028 RFC 2068 HTTP/1.1 January 1997
3031 POST an entity describing or containing the result of the action;
3033 TRACE an entity containing the request message as received by the end
3038 The request has been fulfilled and resulted in a new resource being
3039 created. The newly created resource can be referenced by the URI(s)
3040 returned in the entity of the response, with the most specific URL
3041 for the resource given by a Location header field. The origin server
3042 MUST create the resource before returning the 201 status code. If the
3043 action cannot be carried out immediately, the server should respond
3044 with 202 (Accepted) response instead.
3048 The request has been accepted for processing, but the processing has
3049 not been completed. The request MAY or MAY NOT eventually be acted
3050 upon, as it MAY be disallowed when processing actually takes place.
3051 There is no facility for re-sending a status code from an
3052 asynchronous operation such as this.
3054 The 202 response is intentionally non-committal. Its purpose is to
3055 allow a server to accept a request for some other process (perhaps a
3056 batch-oriented process that is only run once per day) without
3057 requiring that the user agent's connection to the server persist
3058 until the process is completed. The entity returned with this
3059 response SHOULD include an indication of the request's current status
3060 and either a pointer to a status monitor or some estimate of when the
3061 user can expect the request to be fulfilled.
3063 10.2.4 203 Non-Authoritative Information
3065 The returned metainformation in the entity-header is not the
3066 definitive set as available from the origin server, but is gathered
3067 from a local or a third-party copy. The set presented MAY be a subset
3068 or superset of the original version. For example, including local
3069 annotation information about the resource MAY result in a superset of
3070 the metainformation known by the origin server. Use of this response
3071 code is not required and is only appropriate when the response would
3072 otherwise be 200 (OK).
3074 10.2.5 204 No Content
3076 The server has fulfilled the request but there is no new information
3077 to send back. If the client is a user agent, it SHOULD NOT change its
3078 document view from that which caused the request to be sent. This
3082 Fielding, et. al. Standards Track [Page 55]
3084 RFC 2068 HTTP/1.1 January 1997
3087 response is primarily intended to allow input for actions to take
3088 place without causing a change to the user agent's active document
3089 view. The response MAY include new metainformation in the form of
3090 entity-headers, which SHOULD apply to the document currently in the
3091 user agent's active view.
3093 The 204 response MUST NOT include a message-body, and thus is always
3094 terminated by the first empty line after the header fields.
3096 10.2.6 205 Reset Content
3098 The server has fulfilled the request and the user agent SHOULD reset
3099 the document view which caused the request to be sent. This response
3100 is primarily intended to allow input for actions to take place via
3101 user input, followed by a clearing of the form in which the input is
3102 given so that the user can easily initiate another input action. The
3103 response MUST NOT include an entity.
3105 10.2.7 206 Partial Content
3107 The server has fulfilled the partial GET request for the resource.
3108 The request must have included a Range header field (section 14.36)
3109 indicating the desired range. The response MUST include either a
3110 Content-Range header field (section 14.17) indicating the range
3111 included with this response, or a multipart/byteranges Content-Type
3112 including Content-Range fields for each part. If multipart/byteranges
3113 is not used, the Content-Length header field in the response MUST
3114 match the actual number of OCTETs transmitted in the message-body.
3116 A cache that does not support the Range and Content-Range headers
3117 MUST NOT cache 206 (Partial) responses.
3119 10.3 Redirection 3xx
3121 This class of status code indicates that further action needs to be
3122 taken by the user agent in order to fulfill the request. The action
3123 required MAY be carried out by the user agent without interaction
3124 with the user if and only if the method used in the second request is
3125 GET or HEAD. A user agent SHOULD NOT automatically redirect a request
3126 more than 5 times, since such redirections usually indicate an
3138 Fielding, et. al. Standards Track [Page 56]
3140 RFC 2068 HTTP/1.1 January 1997
3143 10.3.1 300 Multiple Choices
3145 The requested resource corresponds to any one of a set of
3146 representations, each with its own specific location, and agent-
3147 driven negotiation information (section 12) is being provided so that
3148 the user (or user agent) can select a preferred representation and
3149 redirect its request to that location.
3151 Unless it was a HEAD request, the response SHOULD include an entity
3152 containing a list of resource characteristics and location(s) from
3153 which the user or user agent can choose the one most appropriate. The
3154 entity format is specified by the media type given in the Content-
3155 Type header field. Depending upon the format and the capabilities of
3156 the user agent, selection of the most appropriate choice may be
3157 performed automatically. However, this specification does not define
3158 any standard for such automatic selection.
3160 If the server has a preferred choice of representation, it SHOULD
3161 include the specific URL for that representation in the Location
3162 field; user agents MAY use the Location field value for automatic
3163 redirection. This response is cachable unless indicated otherwise.
3165 10.3.2 301 Moved Permanently
3167 The requested resource has been assigned a new permanent URI and any
3168 future references to this resource SHOULD be done using one of the
3169 returned URIs. Clients with link editing capabilities SHOULD
3170 automatically re-link references to the Request-URI to one or more of
3171 the new references returned by the server, where possible. This
3172 response is cachable unless indicated otherwise.
3174 If the new URI is a location, its URL SHOULD be given by the Location
3175 field in the response. Unless the request method was HEAD, the entity
3176 of the response SHOULD contain a short hypertext note with a
3177 hyperlink to the new URI(s).
3179 If the 301 status code is received in response to a request other
3180 than GET or HEAD, the user agent MUST NOT automatically redirect the
3181 request unless it can be confirmed by the user, since this might
3182 change the conditions under which the request was issued.
3184 Note: When automatically redirecting a POST request after receiving
3185 a 301 status code, some existing HTTP/1.0 user agents will
3186 erroneously change it into a GET request.
3194 Fielding, et. al. Standards Track [Page 57]
3196 RFC 2068 HTTP/1.1 January 1997
3199 10.3.3 302 Moved Temporarily
3201 The requested resource resides temporarily under a different URI.
3202 Since the redirection may be altered on occasion, the client SHOULD
3203 continue to use the Request-URI for future requests. This response is
3204 only cachable if indicated by a Cache-Control or Expires header
3207 If the new URI is a location, its URL SHOULD be given by the Location
3208 field in the response. Unless the request method was HEAD, the entity
3209 of the response SHOULD contain a short hypertext note with a
3210 hyperlink to the new URI(s).
3212 If the 302 status code is received in response to a request other
3213 than GET or HEAD, the user agent MUST NOT automatically redirect the
3214 request unless it can be confirmed by the user, since this might
3215 change the conditions under which the request was issued.
3217 Note: When automatically redirecting a POST request after receiving
3218 a 302 status code, some existing HTTP/1.0 user agents will
3219 erroneously change it into a GET request.
3221 10.3.4 303 See Other
3223 The response to the request can be found under a different URI and
3224 SHOULD be retrieved using a GET method on that resource. This method
3225 exists primarily to allow the output of a POST-activated script to
3226 redirect the user agent to a selected resource. The new URI is not a
3227 substitute reference for the originally requested resource. The 303
3228 response is not cachable, but the response to the second (redirected)
3229 request MAY be cachable.
3231 If the new URI is a location, its URL SHOULD be given by the Location
3232 field in the response. Unless the request method was HEAD, the entity
3233 of the response SHOULD contain a short hypertext note with a
3234 hyperlink to the new URI(s).
3236 10.3.5 304 Not Modified
3238 If the client has performed a conditional GET request and access is
3239 allowed, but the document has not been modified, the server SHOULD
3240 respond with this status code. The response MUST NOT contain a
3250 Fielding, et. al. Standards Track [Page 58]
3252 RFC 2068 HTTP/1.1 January 1997
3255 The response MUST include the following header fields:
3259 o ETag and/or Content-Location, if the header would have been sent in
3260 a 200 response to the same request
3262 o Expires, Cache-Control, and/or Vary, if the field-value might
3263 differ from that sent in any previous response for the same variant
3265 If the conditional GET used a strong cache validator (see section
3266 13.3.3), the response SHOULD NOT include other entity-headers.
3267 Otherwise (i.e., the conditional GET used a weak validator), the
3268 response MUST NOT include other entity-headers; this prevents
3269 inconsistencies between cached entity-bodies and updated headers.
3271 If a 304 response indicates an entity not currently cached, then the
3272 cache MUST disregard the response and repeat the request without the
3275 If a cache uses a received 304 response to update a cache entry, the
3276 cache MUST update the entry to reflect any new field values given in
3279 The 304 response MUST NOT include a message-body, and thus is always
3280 terminated by the first empty line after the header fields.
3282 10.3.6 305 Use Proxy
3284 The requested resource MUST be accessed through the proxy given by
3285 the Location field. The Location field gives the URL of the proxy.
3286 The recipient is expected to repeat the request via the proxy.
3288 10.4 Client Error 4xx
3290 The 4xx class of status code is intended for cases in which the
3291 client seems to have erred. Except when responding to a HEAD request,
3292 the server SHOULD include an entity containing an explanation of the
3293 error situation, and whether it is a temporary or permanent
3294 condition. These status codes are applicable to any request method.
3295 User agents SHOULD display any included entity to the user.
3297 Note: If the client is sending data, a server implementation using
3298 TCP should be careful to ensure that the client acknowledges
3299 receipt of the packet(s) containing the response, before the server
3300 closes the input connection. If the client continues sending data
3301 to the server after the close, the server's TCP stack will send a
3302 reset packet to the client, which may erase the client's
3306 Fielding, et. al. Standards Track [Page 59]
3308 RFC 2068 HTTP/1.1 January 1997
3311 unacknowledged input buffers before they can be read and
3312 interpreted by the HTTP application.
3314 10.4.1 400 Bad Request
3316 The request could not be understood by the server due to malformed
3317 syntax. The client SHOULD NOT repeat the request without
3320 10.4.2 401 Unauthorized
3322 The request requires user authentication. The response MUST include a
3323 WWW-Authenticate header field (section 14.46) containing a challenge
3324 applicable to the requested resource. The client MAY repeat the
3325 request with a suitable Authorization header field (section 14.8). If
3326 the request already included Authorization credentials, then the 401
3327 response indicates that authorization has been refused for those
3328 credentials. If the 401 response contains the same challenge as the
3329 prior response, and the user agent has already attempted
3330 authentication at least once, then the user SHOULD be presented the
3331 entity that was given in the response, since that entity MAY include
3332 relevant diagnostic information. HTTP access authentication is
3333 explained in section 11.
3335 10.4.3 402 Payment Required
3337 This code is reserved for future use.
3339 10.4.4 403 Forbidden
3341 The server understood the request, but is refusing to fulfill it.
3342 Authorization will not help and the request SHOULD NOT be repeated.
3343 If the request method was not HEAD and the server wishes to make
3344 public why the request has not been fulfilled, it SHOULD describe the
3345 reason for the refusal in the entity. This status code is commonly
3346 used when the server does not wish to reveal exactly why the request
3347 has been refused, or when no other response is applicable.
3349 10.4.5 404 Not Found
3351 The server has not found anything matching the Request-URI. No
3352 indication is given of whether the condition is temporary or
3362 Fielding, et. al. Standards Track [Page 60]
3364 RFC 2068 HTTP/1.1 January 1997
3367 If the server does not wish to make this information available to the
3368 client, the status code 403 (Forbidden) can be used instead. The 410
3369 (Gone) status code SHOULD be used if the server knows, through some
3370 internally configurable mechanism, that an old resource is
3371 permanently unavailable and has no forwarding address.
3373 10.4.6 405 Method Not Allowed
3375 The method specified in the Request-Line is not allowed for the
3376 resource identified by the Request-URI. The response MUST include an
3377 Allow header containing a list of valid methods for the requested
3380 10.4.7 406 Not Acceptable
3382 The resource identified by the request is only capable of generating
3383 response entities which have content characteristics not acceptable
3384 according to the accept headers sent in the request.
3386 Unless it was a HEAD request, the response SHOULD include an entity
3387 containing a list of available entity characteristics and location(s)
3388 from which the user or user agent can choose the one most
3389 appropriate. The entity format is specified by the media type given
3390 in the Content-Type header field. Depending upon the format and the
3391 capabilities of the user agent, selection of the most appropriate
3392 choice may be performed automatically. However, this specification
3393 does not define any standard for such automatic selection.
3395 Note: HTTP/1.1 servers are allowed to return responses which are
3396 not acceptable according to the accept headers sent in the request.
3397 In some cases, this may even be preferable to sending a 406
3398 response. User agents are encouraged to inspect the headers of an
3399 incoming response to determine if it is acceptable. If the response
3400 could be unacceptable, a user agent SHOULD temporarily stop receipt
3401 of more data and query the user for a decision on further actions.
3403 10.4.8 407 Proxy Authentication Required
3405 This code is similar to 401 (Unauthorized), but indicates that the
3406 client MUST first authenticate itself with the proxy. The proxy MUST
3407 return a Proxy-Authenticate header field (section 14.33) containing a
3408 challenge applicable to the proxy for the requested resource. The
3409 client MAY repeat the request with a suitable Proxy-Authorization
3410 header field (section 14.34). HTTP access authentication is explained
3418 Fielding, et. al. Standards Track [Page 61]
3420 RFC 2068 HTTP/1.1 January 1997
3423 10.4.9 408 Request Timeout
3425 The client did not produce a request within the time that the server
3426 was prepared to wait. The client MAY repeat the request without
3427 modifications at any later time.
3429 10.4.10 409 Conflict
3431 The request could not be completed due to a conflict with the current
3432 state of the resource. This code is only allowed in situations where
3433 it is expected that the user might be able to resolve the conflict
3434 and resubmit the request. The response body SHOULD include enough
3435 information for the user to recognize the source of the conflict.
3436 Ideally, the response entity would include enough information for the
3437 user or user agent to fix the problem; however, that may not be
3438 possible and is not required.
3440 Conflicts are most likely to occur in response to a PUT request. If
3441 versioning is being used and the entity being PUT includes changes to
3442 a resource which conflict with those made by an earlier (third-party)
3443 request, the server MAY use the 409 response to indicate that it
3444 can't complete the request. In this case, the response entity SHOULD
3445 contain a list of the differences between the two versions in a
3446 format defined by the response Content-Type.
3450 The requested resource is no longer available at the server and no
3451 forwarding address is known. This condition SHOULD be considered
3452 permanent. Clients with link editing capabilities SHOULD delete
3453 references to the Request-URI after user approval. If the server does
3454 not know, or has no facility to determine, whether or not the
3455 condition is permanent, the status code 404 (Not Found) SHOULD be
3456 used instead. This response is cachable unless indicated otherwise.
3458 The 410 response is primarily intended to assist the task of web
3459 maintenance by notifying the recipient that the resource is
3460 intentionally unavailable and that the server owners desire that
3461 remote links to that resource be removed. Such an event is common for
3462 limited-time, promotional services and for resources belonging to
3463 individuals no longer working at the server's site. It is not
3464 necessary to mark all permanently unavailable resources as "gone" or
3465 to keep the mark for any length of time -- that is left to the
3466 discretion of the server owner.
3474 Fielding, et. al. Standards Track [Page 62]
3476 RFC 2068 HTTP/1.1 January 1997
3479 10.4.12 411 Length Required
3481 The server refuses to accept the request without a defined Content-
3482 Length. The client MAY repeat the request if it adds a valid
3483 Content-Length header field containing the length of the message-body
3484 in the request message.
3486 10.4.13 412 Precondition Failed
3488 The precondition given in one or more of the request-header fields
3489 evaluated to false when it was tested on the server. This response
3490 code allows the client to place preconditions on the current resource
3491 metainformation (header field data) and thus prevent the requested
3492 method from being applied to a resource other than the one intended.
3494 10.4.14 413 Request Entity Too Large
3496 The server is refusing to process a request because the request
3497 entity is larger than the server is willing or able to process. The
3498 server may close the connection to prevent the client from continuing
3501 If the condition is temporary, the server SHOULD include a Retry-
3502 After header field to indicate that it is temporary and after what
3503 time the client may try again.
3505 10.4.15 414 Request-URI Too Long
3507 The server is refusing to service the request because the Request-URI
3508 is longer than the server is willing to interpret. This rare
3509 condition is only likely to occur when a client has improperly
3510 converted a POST request to a GET request with long query
3511 information, when the client has descended into a URL "black hole" of
3512 redirection (e.g., a redirected URL prefix that points to a suffix of
3513 itself), or when the server is under attack by a client attempting to
3514 exploit security holes present in some servers using fixed-length
3515 buffers for reading or manipulating the Request-URI.
3517 10.4.16 415 Unsupported Media Type
3519 The server is refusing to service the request because the entity of
3520 the request is in a format not supported by the requested resource
3521 for the requested method.
3530 Fielding, et. al. Standards Track [Page 63]
3532 RFC 2068 HTTP/1.1 January 1997
3535 10.5 Server Error 5xx
3537 Response status codes beginning with the digit "5" indicate cases in
3538 which the server is aware that it has erred or is incapable of
3539 performing the request. Except when responding to a HEAD request, the
3540 server SHOULD include an entity containing an explanation of the
3541 error situation, and whether it is a temporary or permanent
3542 condition. User agents SHOULD display any included entity to the
3543 user. These response codes are applicable to any request method.
3545 10.5.1 500 Internal Server Error
3547 The server encountered an unexpected condition which prevented it
3548 from fulfilling the request.
3550 10.5.2 501 Not Implemented
3552 The server does not support the functionality required to fulfill the
3553 request. This is the appropriate response when the server does not
3554 recognize the request method and is not capable of supporting it for
3557 10.5.3 502 Bad Gateway
3559 The server, while acting as a gateway or proxy, received an invalid
3560 response from the upstream server it accessed in attempting to
3561 fulfill the request.
3563 10.5.4 503 Service Unavailable
3565 The server is currently unable to handle the request due to a
3566 temporary overloading or maintenance of the server. The implication
3567 is that this is a temporary condition which will be alleviated after
3568 some delay. If known, the length of the delay may be indicated in a
3569 Retry-After header. If no Retry-After is given, the client SHOULD
3570 handle the response as it would for a 500 response.
3572 Note: The existence of the 503 status code does not imply that a
3573 server must use it when becoming overloaded. Some servers may wish
3574 to simply refuse the connection.
3576 10.5.5 504 Gateway Timeout
3578 The server, while acting as a gateway or proxy, did not receive a
3579 timely response from the upstream server it accessed in attempting to
3580 complete the request.
3586 Fielding, et. al. Standards Track [Page 64]
3588 RFC 2068 HTTP/1.1 January 1997
3591 10.5.6 505 HTTP Version Not Supported
3593 The server does not support, or refuses to support, the HTTP protocol
3594 version that was used in the request message. The server is
3595 indicating that it is unable or unwilling to complete the request
3596 using the same major version as the client, as described in section
3597 3.1, other than with this error message. The response SHOULD contain
3598 an entity describing why that version is not supported and what other
3599 protocols are supported by that server.
3601 11 Access Authentication
3603 HTTP provides a simple challenge-response authentication mechanism
3604 which MAY be used by a server to challenge a client request and by a
3605 client to provide authentication information. It uses an extensible,
3606 case-insensitive token to identify the authentication scheme,
3607 followed by a comma-separated list of attribute-value pairs which
3608 carry the parameters necessary for achieving authentication via that
3613 auth-param = token "=" quoted-string
3615 The 401 (Unauthorized) response message is used by an origin server
3616 to challenge the authorization of a user agent. This response MUST
3617 include a WWW-Authenticate header field containing at least one
3618 challenge applicable to the requested resource.
3620 challenge = auth-scheme 1*SP realm *( "," auth-param )
3622 realm = "realm" "=" realm-value
3623 realm-value = quoted-string
3625 The realm attribute (case-insensitive) is required for all
3626 authentication schemes which issue a challenge. The realm value
3627 (case-sensitive), in combination with the canonical root URL (see
3628 section 5.1.2) of the server being accessed, defines the protection
3629 space. These realms allow the protected resources on a server to be
3630 partitioned into a set of protection spaces, each with its own
3631 authentication scheme and/or authorization database. The realm value
3632 is a string, generally assigned by the origin server, which may have
3633 additional semantics specific to the authentication scheme.
3635 A user agent that wishes to authenticate itself with a server--
3636 usually, but not necessarily, after receiving a 401 or 411 response-
3637 -MAY do so by including an Authorization header field with the
3638 request. The Authorization field value consists of credentials
3642 Fielding, et. al. Standards Track [Page 65]
3644 RFC 2068 HTTP/1.1 January 1997
3647 containing the authentication information of the user agent for the
3648 realm of the resource being requested.
3650 credentials = basic-credentials
3651 | auth-scheme #auth-param
3653 The domain over which credentials can be automatically applied by a
3654 user agent is determined by the protection space. If a prior request
3655 has been authorized, the same credentials MAY be reused for all other
3656 requests within that protection space for a period of time determined
3657 by the authentication scheme, parameters, and/or user preference.
3658 Unless otherwise defined by the authentication scheme, a single
3659 protection space cannot extend outside the scope of its server.
3661 If the server does not wish to accept the credentials sent with a
3662 request, it SHOULD return a 401 (Unauthorized) response. The response
3663 MUST include a WWW-Authenticate header field containing the (possibly
3664 new) challenge applicable to the requested resource and an entity
3665 explaining the refusal.
3667 The HTTP protocol does not restrict applications to this simple
3668 challenge-response mechanism for access authentication. Additional
3669 mechanisms MAY be used, such as encryption at the transport level or
3670 via message encapsulation, and with additional header fields
3671 specifying authentication information. However, these additional
3672 mechanisms are not defined by this specification.
3674 Proxies MUST be completely transparent regarding user agent
3675 authentication. That is, they MUST forward the WWW-Authenticate and
3676 Authorization headers untouched, and follow the rules found in
3679 HTTP/1.1 allows a client to pass authentication information to and
3680 from a proxy via the Proxy-Authenticate and Proxy-Authorization
3683 11.1 Basic Authentication Scheme
3685 The "basic" authentication scheme is based on the model that the user
3686 agent must authenticate itself with a user-ID and a password for each
3687 realm. The realm value should be considered an opaque string which
3688 can only be compared for equality with other realms on that server.
3689 The server will service the request only if it can validate the
3690 user-ID and password for the protection space of the Request-URI.
3691 There are no optional authentication parameters.
3698 Fielding, et. al. Standards Track [Page 66]
3700 RFC 2068 HTTP/1.1 January 1997
3703 Upon receipt of an unauthorized request for a URI within the
3704 protection space, the server MAY respond with a challenge like the
3707 WWW-Authenticate: Basic realm="WallyWorld"
3709 where "WallyWorld" is the string assigned by the server to identify
3710 the protection space of the Request-URI.
3712 To receive authorization, the client sends the userid and password,
3713 separated by a single colon (":") character, within a base64 encoded
3714 string in the credentials.
3716 basic-credentials = "Basic" SP basic-cookie
3718 basic-cookie = <base64 [7] encoding of user-pass,
3719 except not limited to 76 char/line>
3721 user-pass = userid ":" password
3723 userid = *<TEXT excluding ":">
3727 Userids might be case sensitive.
3729 If the user agent wishes to send the userid "Aladdin" and password
3730 "open sesame", it would use the following header field:
3732 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
3734 See section 15 for security considerations associated with Basic
3737 11.2 Digest Authentication Scheme
3739 A digest authentication for HTTP is specified in RFC 2069 [32].
3741 12 Content Negotiation
3743 Most HTTP responses include an entity which contains information for
3744 interpretation by a human user. Naturally, it is desirable to supply
3745 the user with the "best available" entity corresponding to the
3746 request. Unfortunately for servers and caches, not all users have
3747 the same preferences for what is "best," and not all user agents are
3748 equally capable of rendering all entity types. For that reason, HTTP
3749 has provisions for several mechanisms for "content negotiation" --
3750 the process of selecting the best representation for a given response
3754 Fielding, et. al. Standards Track [Page 67]
3756 RFC 2068 HTTP/1.1 January 1997
3759 when there are multiple representations available.
3761 Note: This is not called "format negotiation" because the alternate
3762 representations may be of the same media type, but use different
3763 capabilities of that type, be in different languages, etc.
3765 Any response containing an entity-body MAY be subject to negotiation,
3766 including error responses.
3768 There are two kinds of content negotiation which are possible in
3769 HTTP: server-driven and agent-driven negotiation. These two kinds of
3770 negotiation are orthogonal and thus may be used separately or in
3771 combination. One method of combination, referred to as transparent
3772 negotiation, occurs when a cache uses the agent-driven negotiation
3773 information provided by the origin server in order to provide
3774 server-driven negotiation for subsequent requests.
3776 12.1 Server-driven Negotiation
3778 If the selection of the best representation for a response is made by
3779 an algorithm located at the server, it is called server-driven
3780 negotiation. Selection is based on the available representations of
3781 the response (the dimensions over which it can vary; e.g. language,
3782 content-coding, etc.) and the contents of particular header fields in
3783 the request message or on other information pertaining to the request
3784 (such as the network address of the client).
3786 Server-driven negotiation is advantageous when the algorithm for
3787 selecting from among the available representations is difficult to
3788 describe to the user agent, or when the server desires to send its
3789 "best guess" to the client along with the first response (hoping to
3790 avoid the round-trip delay of a subsequent request if the "best
3791 guess" is good enough for the user). In order to improve the server's
3792 guess, the user agent MAY include request header fields (Accept,
3793 Accept-Language, Accept-Encoding, etc.) which describe its
3794 preferences for such a response.
3796 Server-driven negotiation has disadvantages:
3798 1. It is impossible for the server to accurately determine what might be
3799 "best" for any given user, since that would require complete
3800 knowledge of both the capabilities of the user agent and the intended
3801 use for the response (e.g., does the user want to view it on screen
3802 or print it on paper?).
3804 2. Having the user agent describe its capabilities in every request can
3805 be both very inefficient (given that only a small percentage of
3806 responses have multiple representations) and a potential violation of
3810 Fielding, et. al. Standards Track [Page 68]
3812 RFC 2068 HTTP/1.1 January 1997
3817 3. It complicates the implementation of an origin server and the
3818 algorithms for generating responses to a request.
3820 4. It may limit a public cache's ability to use the same response for
3821 multiple user's requests.
3823 HTTP/1.1 includes the following request-header fields for enabling
3824 server-driven negotiation through description of user agent
3825 capabilities and user preferences: Accept (section 14.1), Accept-
3826 Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
3827 Language (section 14.4), and User-Agent (section 14.42). However, an
3828 origin server is not limited to these dimensions and MAY vary the
3829 response based on any aspect of the request, including information
3830 outside the request-header fields or within extension header fields
3831 not defined by this specification.
3833 HTTP/1.1 origin servers MUST include an appropriate Vary header field
3834 (section 14.43) in any cachable response based on server-driven
3835 negotiation. The Vary header field describes the dimensions over
3836 which the response might vary (i.e. the dimensions over which the
3837 origin server picks its "best guess" response from multiple
3840 HTTP/1.1 public caches MUST recognize the Vary header field when it
3841 is included in a response and obey the requirements described in
3842 section 13.6 that describes the interactions between caching and
3843 content negotiation.
3845 12.2 Agent-driven Negotiation
3847 With agent-driven negotiation, selection of the best representation
3848 for a response is performed by the user agent after receiving an
3849 initial response from the origin server. Selection is based on a list
3850 of the available representations of the response included within the
3851 header fields (this specification reserves the field-name Alternates,
3852 as described in appendix 19.6.2.1) or entity-body of the initial
3853 response, with each representation identified by its own URI.
3854 Selection from among the representations may be performed
3855 automatically (if the user agent is capable of doing so) or manually
3856 by the user selecting from a generated (possibly hypertext) menu.
3858 Agent-driven negotiation is advantageous when the response would vary
3859 over commonly-used dimensions (such as type, language, or encoding),
3860 when the origin server is unable to determine a user agent's
3861 capabilities from examining the request, and generally when public
3862 caches are used to distribute server load and reduce network usage.
3866 Fielding, et. al. Standards Track [Page 69]
3868 RFC 2068 HTTP/1.1 January 1997
3871 Agent-driven negotiation suffers from the disadvantage of needing a
3872 second request to obtain the best alternate representation. This
3873 second request is only efficient when caching is used. In addition,
3874 this specification does not define any mechanism for supporting
3875 automatic selection, though it also does not prevent any such
3876 mechanism from being developed as an extension and used within
3879 HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
3880 status codes for enabling agent-driven negotiation when the server is
3881 unwilling or unable to provide a varying response using server-driven
3884 12.3 Transparent Negotiation
3886 Transparent negotiation is a combination of both server-driven and
3887 agent-driven negotiation. When a cache is supplied with a form of the
3888 list of available representations of the response (as in agent-driven
3889 negotiation) and the dimensions of variance are completely understood
3890 by the cache, then the cache becomes capable of performing server-
3891 driven negotiation on behalf of the origin server for subsequent
3892 requests on that resource.
3894 Transparent negotiation has the advantage of distributing the
3895 negotiation work that would otherwise be required of the origin
3896 server and also removing the second request delay of agent-driven
3897 negotiation when the cache is able to correctly guess the right
3900 This specification does not define any mechanism for transparent
3901 negotiation, though it also does not prevent any such mechanism from
3902 being developed as an extension and used within HTTP/1.1. An HTTP/1.1
3903 cache performing transparent negotiation MUST include a Vary header
3904 field in the response (defining the dimensions of its variance) if it
3905 is cachable to ensure correct interoperation with all HTTP/1.1
3906 clients. The agent-driven negotiation information supplied by the
3907 origin server SHOULD be included with the transparently negotiated
3912 HTTP is typically used for distributed information systems, where
3913 performance can be improved by the use of response caches. The
3914 HTTP/1.1 protocol includes a number of elements intended to make
3915 caching work as well as possible. Because these elements are
3916 inextricable from other aspects of the protocol, and because they
3917 interact with each other, it is useful to describe the basic caching
3918 design of HTTP separately from the detailed descriptions of methods,
3922 Fielding, et. al. Standards Track [Page 70]
3924 RFC 2068 HTTP/1.1 January 1997
3927 headers, response codes, etc.
3929 Caching would be useless if it did not significantly improve
3930 performance. The goal of caching in HTTP/1.1 is to eliminate the need
3931 to send requests in many cases, and to eliminate the need to send
3932 full responses in many other cases. The former reduces the number of
3933 network round-trips required for many operations; we use an
3934 "expiration" mechanism for this purpose (see section 13.2). The
3935 latter reduces network bandwidth requirements; we use a "validation"
3936 mechanism for this purpose (see section 13.3).
3938 Requirements for performance, availability, and disconnected
3939 operation require us to be able to relax the goal of semantic
3940 transparency. The HTTP/1.1 protocol allows origin servers, caches,
3941 and clients to explicitly reduce transparency when necessary.
3942 However, because non-transparent operation may confuse non-expert
3943 users, and may be incompatible with certain server applications (such
3944 as those for ordering merchandise), the protocol requires that
3945 transparency be relaxed
3947 o only by an explicit protocol-level request when relaxed by client
3950 o only with an explicit warning to the end user when relaxed by cache
3978 Fielding, et. al. Standards Track [Page 71]
3980 RFC 2068 HTTP/1.1 January 1997
3983 Therefore, the HTTP/1.1 protocol provides these important elements:
3985 1. Protocol features that provide full semantic transparency when this
3986 is required by all parties.
3988 2. Protocol features that allow an origin server or user agent to
3989 explicitly request and control non-transparent operation.
3991 3. Protocol features that allow a cache to attach warnings to
3992 responses that do not preserve the requested approximation of
3993 semantic transparency.
3995 A basic principle is that it must be possible for the clients to
3996 detect any potential relaxation of semantic transparency.
3998 Note: The server, cache, or client implementer may be faced with
3999 design decisions not explicitly discussed in this specification. If
4000 a decision may affect semantic transparency, the implementer ought
4001 to err on the side of maintaining transparency unless a careful and
4002 complete analysis shows significant benefits in breaking
4005 13.1.1 Cache Correctness
4007 A correct cache MUST respond to a request with the most up-to-date
4008 response held by the cache that is appropriate to the request (see
4009 sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
4012 1. It has been checked for equivalence with what the origin server
4013 would have returned by revalidating the response with the origin
4014 server (section 13.3);
4016 2. It is "fresh enough" (see section 13.2). In the default case, this
4017 means it meets the least restrictive freshness requirement of the
4018 client, server, and cache (see section 14.9); if the origin server
4019 so specifies, it is the freshness requirement of the origin server
4022 3. It includes a warning if the freshness demand of the client or the
4023 origin server is violated (see section 13.1.5 and 14.45).
4025 4. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or
4026 error (4xx or 5xx) response message.
4028 If the cache can not communicate with the origin server, then a
4029 correct cache SHOULD respond as above if the response can be
4030 correctly served from the cache; if not it MUST return an error or
4034 Fielding, et. al. Standards Track [Page 72]
4036 RFC 2068 HTTP/1.1 January 1997
4039 warning indicating that there was a communication failure.
4041 If a cache receives a response (either an entire response, or a 304
4042 (Not Modified) response) that it would normally forward to the
4043 requesting client, and the received response is no longer fresh, the
4044 cache SHOULD forward it to the requesting client without adding a new
4045 Warning (but without removing any existing Warning headers). A cache
4046 SHOULD NOT attempt to revalidate a response simply because that
4047 response became stale in transit; this might lead to an infinite
4048 loop. An user agent that receives a stale response without a Warning
4049 MAY display a warning indication to the user.
4053 Whenever a cache returns a response that is neither first-hand nor
4054 "fresh enough" (in the sense of condition 2 in section 13.1.1), it
4055 must attach a warning to that effect, using a Warning response-
4056 header. This warning allows clients to take appropriate action.
4058 Warnings may be used for other purposes, both cache-related and
4059 otherwise. The use of a warning, rather than an error status code,
4060 distinguish these responses from true failures.
4062 Warnings are always cachable, because they never weaken the
4063 transparency of a response. This means that warnings can be passed to
4064 HTTP/1.0 caches without danger; such caches will simply pass the
4065 warning along as an entity-header in the response.
4067 Warnings are assigned numbers between 0 and 99. This specification
4068 defines the code numbers and meanings of each currently assigned
4069 warnings, allowing a client or cache to take automated action in some
4070 (but not all) cases.
4072 Warnings also carry a warning text. The text may be in any
4073 appropriate natural language (perhaps based on the client's Accept
4074 headers), and include an optional indication of what character set is
4077 Multiple warnings may be attached to a response (either by the origin
4078 server or by a cache), including multiple warnings with the same code
4079 number. For example, a server may provide the same warning with texts
4080 in both English and Basque.
4082 When multiple warnings are attached to a response, it may not be
4083 practical or reasonable to display all of them to the user. This
4084 version of HTTP does not specify strict priority rules for deciding
4085 which warnings to display and in what order, but does suggest some
4090 Fielding, et. al. Standards Track [Page 73]
4092 RFC 2068 HTTP/1.1 January 1997
4095 The Warning header and the currently defined warnings are described
4098 13.1.3 Cache-control Mechanisms
4100 The basic cache mechanisms in HTTP/1.1 (server-specified expiration
4101 times and validators) are implicit directives to caches. In some
4102 cases, a server or client may need to provide explicit directives to
4103 the HTTP caches. We use the Cache-Control header for this purpose.
4105 The Cache-Control header allows a client or server to transmit a
4106 variety of directives in either requests or responses. These
4107 directives typically override the default caching algorithms. As a
4108 general rule, if there is any apparent conflict between header
4109 values, the most restrictive interpretation should be applied (that
4110 is, the one that is most likely to preserve semantic transparency).
4111 However, in some cases, Cache-Control directives are explicitly
4112 specified as weakening the approximation of semantic transparency
4113 (for example, "max-stale" or "public").
4115 The Cache-Control directives are described in detail in section 14.9.
4117 13.1.4 Explicit User Agent Warnings
4119 Many user agents make it possible for users to override the basic
4120 caching mechanisms. For example, the user agent may allow the user to
4121 specify that cached entities (even explicitly stale ones) are never
4122 validated. Or the user agent might habitually add "Cache-Control:
4123 max-stale=3600" to every request. The user should have to explicitly
4124 request either non-transparent behavior, or behavior that results in
4125 abnormally ineffective caching.
4127 If the user has overridden the basic caching mechanisms, the user
4128 agent should explicitly indicate to the user whenever this results in
4129 the display of information that might not meet the server's
4130 transparency requirements (in particular, if the displayed entity is
4131 known to be stale). Since the protocol normally allows the user agent
4132 to determine if responses are stale or not, this indication need only
4133 be displayed when this actually happens. The indication need not be a
4134 dialog box; it could be an icon (for example, a picture of a rotting
4135 fish) or some other visual indicator.
4137 If the user has overridden the caching mechanisms in a way that would
4138 abnormally reduce the effectiveness of caches, the user agent should
4139 continually display an indication (for example, a picture of currency
4140 in flames) so that the user does not inadvertently consume excess
4141 resources or suffer from excessive latency.
4146 Fielding, et. al. Standards Track [Page 74]
4148 RFC 2068 HTTP/1.1 January 1997
4151 13.1.5 Exceptions to the Rules and Warnings
4153 In some cases, the operator of a cache may choose to configure it to
4154 return stale responses even when not requested by clients. This
4155 decision should not be made lightly, but may be necessary for reasons
4156 of availability or performance, especially when the cache is poorly
4157 connected to the origin server. Whenever a cache returns a stale
4158 response, it MUST mark it as such (using a Warning header). This
4159 allows the client software to alert the user that there may be a
4162 It also allows the user agent to take steps to obtain a first-hand or
4163 fresh response. For this reason, a cache SHOULD NOT return a stale
4164 response if the client explicitly requests a first-hand or fresh one,
4165 unless it is impossible to comply for technical or policy reasons.
4167 13.1.6 Client-controlled Behavior
4169 While the origin server (and to a lesser extent, intermediate caches,
4170 by their contribution to the age of a response) are the primary
4171 source of expiration information, in some cases the client may need
4172 to control a cache's decision about whether to return a cached
4173 response without validating it. Clients do this using several
4174 directives of the Cache-Control header.
4176 A client's request may specify the maximum age it is willing to
4177 accept of an unvalidated response; specifying a value of zero forces
4178 the cache(s) to revalidate all responses. A client may also specify
4179 the minimum time remaining before a response expires. Both of these
4180 options increase constraints on the behavior of caches, and so cannot
4181 further relax the cache's approximation of semantic transparency.
4183 A client may also specify that it will accept stale responses, up to
4184 some maximum amount of staleness. This loosens the constraints on the
4185 caches, and so may violate the origin server's specified constraints
4186 on semantic transparency, but may be necessary to support
4187 disconnected operation, or high availability in the face of poor
4190 13.2 Expiration Model
4192 13.2.1 Server-Specified Expiration
4194 HTTP caching works best when caches can entirely avoid making
4195 requests to the origin server. The primary mechanism for avoiding
4196 requests is for an origin server to provide an explicit expiration
4197 time in the future, indicating that a response may be used to satisfy
4198 subsequent requests. In other words, a cache can return a fresh
4202 Fielding, et. al. Standards Track [Page 75]
4204 RFC 2068 HTTP/1.1 January 1997
4207 response without first contacting the server.
4209 Our expectation is that servers will assign future explicit
4210 expiration times to responses in the belief that the entity is not
4211 likely to change, in a semantically significant way, before the
4212 expiration time is reached. This normally preserves semantic
4213 transparency, as long as the server's expiration times are carefully
4216 The expiration mechanism applies only to responses taken from a cache
4217 and not to first-hand responses forwarded immediately to the
4220 If an origin server wishes to force a semantically transparent cache
4221 to validate every request, it may assign an explicit expiration time
4222 in the past. This means that the response is always stale, and so the
4223 cache SHOULD validate it before using it for subsequent requests. See
4224 section 14.9.4 for a more restrictive way to force revalidation.
4226 If an origin server wishes to force any HTTP/1.1 cache, no matter how
4227 it is configured, to validate every request, it should use the
4228 "must-revalidate" Cache-Control directive (see section 14.9).
4230 Servers specify explicit expiration times using either the Expires
4231 header, or the max-age directive of the Cache-Control header.
4233 An expiration time cannot be used to force a user agent to refresh
4234 its display or reload a resource; its semantics apply only to caching
4235 mechanisms, and such mechanisms need only check a resource's
4236 expiration status when a new request for that resource is initiated.
4237 See section 13.13 for explanation of the difference between caches
4238 and history mechanisms.
4240 13.2.2 Heuristic Expiration
4242 Since origin servers do not always provide explicit expiration times,
4243 HTTP caches typically assign heuristic expiration times, employing
4244 algorithms that use other header values (such as the Last-Modified
4245 time) to estimate a plausible expiration time. The HTTP/1.1
4246 specification does not provide specific algorithms, but does impose
4247 worst-case constraints on their results. Since heuristic expiration
4248 times may compromise semantic transparency, they should be used
4249 cautiously, and we encourage origin servers to provide explicit
4250 expiration times as much as possible.
4258 Fielding, et. al. Standards Track [Page 76]
4260 RFC 2068 HTTP/1.1 January 1997
4263 13.2.3 Age Calculations
4265 In order to know if a cached entry is fresh, a cache needs to know if
4266 its age exceeds its freshness lifetime. We discuss how to calculate
4267 the latter in section 13.2.4; this section describes how to calculate
4268 the age of a response or cache entry.
4270 In this discussion, we use the term "now" to mean "the current value
4271 of the clock at the host performing the calculation." Hosts that use
4272 HTTP, but especially hosts running origin servers and caches, should
4273 use NTP [28] or some similar protocol to synchronize their clocks to
4274 a globally accurate time standard.
4276 Also note that HTTP/1.1 requires origin servers to send a Date header
4277 with every response, giving the time at which the response was
4278 generated. We use the term "date_value" to denote the value of the
4279 Date header, in a form appropriate for arithmetic operations.
4281 HTTP/1.1 uses the Age response-header to help convey age information
4282 between caches. The Age header value is the sender's estimate of the
4283 amount of time since the response was generated at the origin server.
4284 In the case of a cached response that has been revalidated with the
4285 origin server, the Age value is based on the time of revalidation,
4286 not of the original response.
4288 In essence, the Age value is the sum of the time that the response
4289 has been resident in each of the caches along the path from the
4290 origin server, plus the amount of time it has been in transit along
4293 We use the term "age_value" to denote the value of the Age header, in
4294 a form appropriate for arithmetic operations.
4296 A response's age can be calculated in two entirely independent ways:
4298 1. now minus date_value, if the local clock is reasonably well
4299 synchronized to the origin server's clock. If the result is
4300 negative, the result is replaced by zero.
4302 2. age_value, if all of the caches along the response path
4305 Given that we have two independent ways to compute the age of a
4306 response when it is received, we can combine these as
4308 corrected_received_age = max(now - date_value, age_value)
4310 and as long as we have either nearly synchronized clocks or all-
4314 Fielding, et. al. Standards Track [Page 77]
4316 RFC 2068 HTTP/1.1 January 1997
4319 HTTP/1.1 paths, one gets a reliable (conservative) result.
4321 Note that this correction is applied at each HTTP/1.1 cache along the
4322 path, so that if there is an HTTP/1.0 cache in the path, the correct
4323 received age is computed as long as the receiving cache's clock is
4324 nearly in sync. We don't need end-to-end clock synchronization
4325 (although it is good to have), and there is no explicit clock
4326 synchronization step.
4328 Because of network-imposed delays, some significant interval may pass
4329 from the time that a server generates a response and the time it is
4330 received at the next outbound cache or client. If uncorrected, this
4331 delay could result in improperly low ages.
4333 Because the request that resulted in the returned Age value must have
4334 been initiated prior to that Age value's generation, we can correct
4335 for delays imposed by the network by recording the time at which the
4336 request was initiated. Then, when an Age value is received, it MUST
4337 be interpreted relative to the time the request was initiated, not
4338 the time that the response was received. This algorithm results in
4339 conservative behavior no matter how much delay is experienced. So, we
4342 corrected_initial_age = corrected_received_age
4343 + (now - request_time)
4345 where "request_time" is the time (according to the local clock) when
4346 the request that elicited this response was sent.
4348 Summary of age calculation algorithm, when a cache receives a
4353 * is the value of Age: header received by the cache with
4356 * is the value of the origin server's Date: header
4358 * is the (local) time when the cache made the request
4359 * that resulted in this cached response
4361 * is the (local) time when the cache received the
4364 * is the current (local) time
4366 apparent_age = max(0, response_time - date_value);
4370 Fielding, et. al. Standards Track [Page 78]
4372 RFC 2068 HTTP/1.1 January 1997
4375 corrected_received_age = max(apparent_age, age_value);
4376 response_delay = response_time - request_time;
4377 corrected_initial_age = corrected_received_age + response_delay;
4378 resident_time = now - response_time;
4379 current_age = corrected_initial_age + resident_time;
4381 When a cache sends a response, it must add to the
4382 corrected_initial_age the amount of time that the response was
4383 resident locally. It must then transmit this total age, using the Age
4384 header, to the next recipient cache.
4386 Note that a client cannot reliably tell that a response is first-
4387 hand, but the presence of an Age header indicates that a response
4388 is definitely not first-hand. Also, if the Date in a response is
4389 earlier than the client's local request time, the response is
4390 probably not first-hand (in the absence of serious clock skew).
4392 13.2.4 Expiration Calculations
4394 In order to decide whether a response is fresh or stale, we need to
4395 compare its freshness lifetime to its age. The age is calculated as
4396 described in section 13.2.3; this section describes how to calculate
4397 the freshness lifetime, and to determine if a response has expired.
4398 In the discussion below, the values can be represented in any form
4399 appropriate for arithmetic operations.
4401 We use the term "expires_value" to denote the value of the Expires
4402 header. We use the term "max_age_value" to denote an appropriate
4403 value of the number of seconds carried by the max-age directive of
4404 the Cache-Control header in a response (see section 14.10.
4406 The max-age directive takes priority over Expires, so if max-age is
4407 present in a response, the calculation is simply:
4409 freshness_lifetime = max_age_value
4411 Otherwise, if Expires is present in the response, the calculation is:
4413 freshness_lifetime = expires_value - date_value
4415 Note that neither of these calculations is vulnerable to clock skew,
4416 since all of the information comes from the origin server.
4418 If neither Expires nor Cache-Control: max-age appears in the
4419 response, and the response does not include other restrictions on
4420 caching, the cache MAY compute a freshness lifetime using a
4421 heuristic. If the value is greater than 24 hours, the cache must
4422 attach Warning 13 to any response whose age is more than 24 hours if
4426 Fielding, et. al. Standards Track [Page 79]
4428 RFC 2068 HTTP/1.1 January 1997
4431 such warning has not already been added.
4433 Also, if the response does have a Last-Modified time, the heuristic
4434 expiration value SHOULD be no more than some fraction of the interval
4435 since that time. A typical setting of this fraction might be 10%.
4437 The calculation to determine if a response has expired is quite
4440 response_is_fresh = (freshness_lifetime > current_age)
4442 13.2.5 Disambiguating Expiration Values
4444 Because expiration values are assigned optimistically, it is possible
4445 for two caches to contain fresh values for the same resource that are
4448 If a client performing a retrieval receives a non-first-hand response
4449 for a request that was already fresh in its own cache, and the Date
4450 header in its existing cache entry is newer than the Date on the new
4451 response, then the client MAY ignore the response. If so, it MAY
4452 retry the request with a "Cache-Control: max-age=0" directive (see
4453 section 14.9), to force a check with the origin server.
4455 If a cache has two fresh responses for the same representation with
4456 different validators, it MUST use the one with the more recent Date
4457 header. This situation may arise because the cache is pooling
4458 responses from other caches, or because a client has asked for a
4459 reload or a revalidation of an apparently fresh cache entry.
4461 13.2.6 Disambiguating Multiple Responses
4463 Because a client may be receiving responses via multiple paths, so
4464 that some responses flow through one set of caches and other
4465 responses flow through a different set of caches, a client may
4466 receive responses in an order different from that in which the origin
4467 server sent them. We would like the client to use the most recently
4468 generated response, even if older responses are still apparently
4471 Neither the entity tag nor the expiration value can impose an
4472 ordering on responses, since it is possible that a later response
4473 intentionally carries an earlier expiration time. However, the
4474 HTTP/1.1 specification requires the transmission of Date headers on
4475 every response, and the Date values are ordered to a granularity of
4482 Fielding, et. al. Standards Track [Page 80]
4484 RFC 2068 HTTP/1.1 January 1997
4487 When a client tries to revalidate a cache entry, and the response it
4488 receives contains a Date header that appears to be older than the one
4489 for the existing entry, then the client SHOULD repeat the request
4490 unconditionally, and include
4492 Cache-Control: max-age=0
4494 to force any intermediate caches to validate their copies directly
4495 with the origin server, or
4497 Cache-Control: no-cache
4499 to force any intermediate caches to obtain a new copy from the origin
4502 If the Date values are equal, then the client may use either response
4503 (or may, if it is being extremely prudent, request a new response).
4504 Servers MUST NOT depend on clients being able to choose
4505 deterministically between responses generated during the same second,
4506 if their expiration times overlap.
4508 13.3 Validation Model
4510 When a cache has a stale entry that it would like to use as a
4511 response to a client's request, it first has to check with the origin
4512 server (or possibly an intermediate cache with a fresh response) to
4513 see if its cached entry is still usable. We call this "validating"
4514 the cache entry. Since we do not want to have to pay the overhead of
4515 retransmitting the full response if the cached entry is good, and we
4516 do not want to pay the overhead of an extra round trip if the cached
4517 entry is invalid, the HTTP/1.1 protocol supports the use of
4518 conditional methods.
4520 The key protocol features for supporting conditional methods are
4521 those concerned with "cache validators." When an origin server
4522 generates a full response, it attaches some sort of validator to it,
4523 which is kept with the cache entry. When a client (user agent or
4524 proxy cache) makes a conditional request for a resource for which it
4525 has a cache entry, it includes the associated validator in the
4528 The server then checks that validator against the current validator
4529 for the entity, and, if they match, it responds with a special status
4530 code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
4531 returns a full response (including entity-body). Thus, we avoid
4532 transmitting the full response if the validator matches, and we avoid
4533 an extra round trip if it does not match.
4538 Fielding, et. al. Standards Track [Page 81]
4540 RFC 2068 HTTP/1.1 January 1997
4543 Note: the comparison functions used to decide if validators match
4544 are defined in section 13.3.3.
4546 In HTTP/1.1, a conditional request looks exactly the same as a normal
4547 request for the same resource, except that it carries a special
4548 header (which includes the validator) that implicitly turns the
4549 method (usually, GET) into a conditional.
4551 The protocol includes both positive and negative senses of cache-
4552 validating conditions. That is, it is possible to request either that
4553 a method be performed if and only if a validator matches or if and
4554 only if no validators match.
4556 Note: a response that lacks a validator may still be cached, and
4557 served from cache until it expires, unless this is explicitly
4558 prohibited by a Cache-Control directive. However, a cache cannot do
4559 a conditional retrieval if it does not have a validator for the
4560 entity, which means it will not be refreshable after it expires.
4562 13.3.1 Last-modified Dates
4564 The Last-Modified entity-header field value is often used as a cache
4565 validator. In simple terms, a cache entry is considered to be valid
4566 if the entity has not been modified since the Last-Modified value.
4568 13.3.2 Entity Tag Cache Validators
4570 The ETag entity-header field value, an entity tag, provides for an
4571 "opaque" cache validator. This may allow more reliable validation in
4572 situations where it is inconvenient to store modification dates,
4573 where the one-second resolution of HTTP date values is not
4574 sufficient, or where the origin server wishes to avoid certain
4575 paradoxes that may arise from the use of modification dates.
4577 Entity Tags are described in section 3.11. The headers used with
4578 entity tags are described in sections 14.20, 14.25, 14.26 and 14.43.
4580 13.3.3 Weak and Strong Validators
4582 Since both origin servers and caches will compare two validators to
4583 decide if they represent the same or different entities, one normally
4584 would expect that if the entity (the entity-body or any entity-
4585 headers) changes in any way, then the associated validator would
4586 change as well. If this is true, then we call this validator a
4589 However, there may be cases when a server prefers to change the
4590 validator only on semantically significant changes, and not when
4594 Fielding, et. al. Standards Track [Page 82]
4596 RFC 2068 HTTP/1.1 January 1997
4599 insignificant aspects of the entity change. A validator that does not
4600 always change when the resource changes is a "weak validator."
4602 Entity tags are normally "strong validators," but the protocol
4603 provides a mechanism to tag an entity tag as "weak." One can think of
4604 a strong validator as one that changes whenever the bits of an entity
4605 changes, while a weak value changes whenever the meaning of an entity
4606 changes. Alternatively, one can think of a strong validator as part
4607 of an identifier for a specific entity, while a weak validator is
4608 part of an identifier for a set of semantically equivalent entities.
4610 Note: One example of a strong validator is an integer that is
4611 incremented in stable storage every time an entity is changed.
4613 An entity's modification time, if represented with one-second
4614 resolution, could be a weak validator, since it is possible that
4615 the resource may be modified twice during a single second.
4617 Support for weak validators is optional; however, weak validators
4618 allow for more efficient caching of equivalent objects; for
4619 example, a hit counter on a site is probably good enough if it is
4620 updated every few days or weeks, and any value during that period
4621 is likely "good enough" to be equivalent.
4623 A "use" of a validator is either when a client generates a request
4624 and includes the validator in a validating header field, or when a
4625 server compares two validators.
4627 Strong validators are usable in any context. Weak validators are only
4628 usable in contexts that do not depend on exact equality of an entity.
4629 For example, either kind is usable for a conditional GET of a full
4630 entity. However, only a strong validator is usable for a sub-range
4631 retrieval, since otherwise the client may end up with an internally
4632 inconsistent entity.
4634 The only function that the HTTP/1.1 protocol defines on validators is
4635 comparison. There are two validator comparison functions, depending
4636 on whether the comparison context allows the use of weak validators
4639 o The strong comparison function: in order to be considered equal,
4640 both validators must be identical in every way, and neither may be
4642 o The weak comparison function: in order to be considered equal, both
4643 validators must be identical in every way, but either or both of
4644 them may be tagged as "weak" without affecting the result.
4646 The weak comparison function MAY be used for simple (non-subrange)
4650 Fielding, et. al. Standards Track [Page 83]
4652 RFC 2068 HTTP/1.1 January 1997
4655 GET requests. The strong comparison function MUST be used in all
4658 An entity tag is strong unless it is explicitly tagged as weak.
4659 Section 3.11 gives the syntax for entity tags.
4661 A Last-Modified time, when used as a validator in a request, is
4662 implicitly weak unless it is possible to deduce that it is strong,
4663 using the following rules:
4665 o The validator is being compared by an origin server to the actual
4666 current validator for the entity and,
4667 o That origin server reliably knows that the associated entity did
4668 not change twice during the second covered by the presented
4672 o The validator is about to be used by a client in an If-Modified-
4673 Since or If-Unmodified-Since header, because the client has a cache
4674 entry for the associated entity, and
4675 o That cache entry includes a Date value, which gives the time when
4676 the origin server sent the original response, and
4677 o The presented Last-Modified time is at least 60 seconds before the
4681 o The validator is being compared by an intermediate cache to the
4682 validator stored in its cache entry for the entity, and
4683 o That cache entry includes a Date value, which gives the time when
4684 the origin server sent the original response, and
4685 o The presented Last-Modified time is at least 60 seconds before the
4688 This method relies on the fact that if two different responses were
4689 sent by the origin server during the same second, but both had the
4690 same Last-Modified time, then at least one of those responses would
4691 have a Date value equal to its Last-Modified time. The arbitrary 60-
4692 second limit guards against the possibility that the Date and Last-
4693 Modified values are generated from different clocks, or at somewhat
4694 different times during the preparation of the response. An
4695 implementation may use a value larger than 60 seconds, if it is
4696 believed that 60 seconds is too short.
4698 If a client wishes to perform a sub-range retrieval on a value for
4699 which it has only a Last-Modified time and no opaque validator, it
4700 may do this only if the Last-Modified time is strong in the sense
4706 Fielding, et. al. Standards Track [Page 84]
4708 RFC 2068 HTTP/1.1 January 1997
4711 A cache or origin server receiving a cache-conditional request, other
4712 than a full-body GET request, MUST use the strong comparison function
4713 to evaluate the condition.
4715 These rules allow HTTP/1.1 caches and clients to safely perform sub-
4716 range retrievals on values that have been obtained from HTTP/1.0
4719 13.3.4 Rules for When to Use Entity Tags and Last-modified Dates
4721 We adopt a set of rules and recommendations for origin servers,
4722 clients, and caches regarding when various validator types should be
4723 used, and for what purposes.
4725 HTTP/1.1 origin servers:
4727 o SHOULD send an entity tag validator unless it is not feasible to
4729 o MAY send a weak entity tag instead of a strong entity tag, if
4730 performance considerations support the use of weak entity tags, or
4731 if it is unfeasible to send a strong entity tag.
4732 o SHOULD send a Last-Modified value if it is feasible to send one,
4733 unless the risk of a breakdown in semantic transparency that could
4734 result from using this date in an If-Modified-Since header would
4735 lead to serious problems.
4737 In other words, the preferred behavior for an HTTP/1.1 origin server
4738 is to send both a strong entity tag and a Last-Modified value.
4740 In order to be legal, a strong entity tag MUST change whenever the
4741 associated entity value changes in any way. A weak entity tag SHOULD
4742 change whenever the associated entity changes in a semantically
4745 Note: in order to provide semantically transparent caching, an
4746 origin server must avoid reusing a specific strong entity tag value
4747 for two different entities, or reusing a specific weak entity tag
4748 value for two semantically different entities. Cache entries may
4749 persist for arbitrarily long periods, regardless of expiration
4750 times, so it may be inappropriate to expect that a cache will never
4751 again attempt to validate an entry using a validator that it
4752 obtained at some point in the past.
4756 o If an entity tag has been provided by the origin server, MUST
4757 use that entity tag in any cache-conditional request (using
4758 If-Match or If-None-Match).
4762 Fielding, et. al. Standards Track [Page 85]
4764 RFC 2068 HTTP/1.1 January 1997
4767 o If only a Last-Modified value has been provided by the origin
4768 server, SHOULD use that value in non-subrange cache-conditional
4769 requests (using If-Modified-Since).
4770 o If only a Last-Modified value has been provided by an HTTP/1.0
4771 origin server, MAY use that value in subrange cache-conditional
4772 requests (using If-Unmodified-Since:). The user agent should
4773 provide a way to disable this, in case of difficulty.
4774 o If both an entity tag and a Last-Modified value have been
4775 provided by the origin server, SHOULD use both validators in
4776 cache-conditional requests. This allows both HTTP/1.0 and
4777 HTTP/1.1 caches to respond appropriately.
4779 An HTTP/1.1 cache, upon receiving a request, MUST use the most
4780 restrictive validator when deciding whether the client's cache entry
4781 matches the cache's own cache entry. This is only an issue when the
4782 request contains both an entity tag and a last-modified-date
4783 validator (If-Modified-Since or If-Unmodified-Since).
4785 A note on rationale: The general principle behind these rules is
4786 that HTTP/1.1 servers and clients should transmit as much non-
4787 redundant information as is available in their responses and
4788 requests. HTTP/1.1 systems receiving this information will make the
4789 most conservative assumptions about the validators they receive.
4791 HTTP/1.0 clients and caches will ignore entity tags. Generally,
4792 last-modified values received or used by these systems will support
4793 transparent and efficient caching, and so HTTP/1.1 origin servers
4794 should provide Last-Modified values. In those rare cases where the
4795 use of a Last-Modified value as a validator by an HTTP/1.0 system
4796 could result in a serious problem, then HTTP/1.1 origin servers
4797 should not provide one.
4799 13.3.5 Non-validating Conditionals
4801 The principle behind entity tags is that only the service author
4802 knows the semantics of a resource well enough to select an
4803 appropriate cache validation mechanism, and the specification of any
4804 validator comparison function more complex than byte-equality would
4805 open up a can of worms. Thus, comparisons of any other headers
4806 (except Last-Modified, for compatibility with HTTP/1.0) are never
4807 used for purposes of validating a cache entry.
4809 13.4 Response Cachability
4811 Unless specifically constrained by a Cache-Control (section 14.9)
4812 directive, a caching system may always store a successful response
4813 (see section 13.8) as a cache entry, may return it without validation
4814 if it is fresh, and may return it after successful validation. If
4818 Fielding, et. al. Standards Track [Page 86]
4820 RFC 2068 HTTP/1.1 January 1997
4823 there is neither a cache validator nor an explicit expiration time
4824 associated with a response, we do not expect it to be cached, but
4825 certain caches may violate this expectation (for example, when little
4826 or no network connectivity is available). A client can usually detect
4827 that such a response was taken from a cache by comparing the Date
4828 header to the current time.
4830 Note that some HTTP/1.0 caches are known to violate this
4831 expectation without providing any Warning.
4833 However, in some cases it may be inappropriate for a cache to retain
4834 an entity, or to return it in response to a subsequent request. This
4835 may be because absolute semantic transparency is deemed necessary by
4836 the service author, or because of security or privacy considerations.
4837 Certain Cache-Control directives are therefore provided so that the
4838 server can indicate that certain resource entities, or portions
4839 thereof, may not be cached regardless of other considerations.
4841 Note that section 14.8 normally prevents a shared cache from saving
4842 and returning a response to a previous request if that request
4843 included an Authorization header.
4845 A response received with a status code of 200, 203, 206, 300, 301 or
4846 410 may be stored by a cache and used in reply to a subsequent
4847 request, subject to the expiration mechanism, unless a Cache-Control
4848 directive prohibits caching. However, a cache that does not support
4849 the Range and Content-Range headers MUST NOT cache 206 (Partial
4852 A response received with any other status code MUST NOT be returned
4853 in a reply to a subsequent request unless there are Cache-Control
4854 directives or another header(s) that explicitly allow it. For
4855 example, these include the following: an Expires header (section
4856 14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public"
4857 or "private" Cache-Control directive (section 14.9).
4859 13.5 Constructing Responses From Caches
4861 The purpose of an HTTP cache is to store information received in
4862 response to requests, for use in responding to future requests. In
4863 many cases, a cache simply returns the appropriate parts of a
4864 response to the requester. However, if the cache holds a cache entry
4865 based on a previous response, it may have to combine parts of a new
4866 response with what is held in the cache entry.
4874 Fielding, et. al. Standards Track [Page 87]
4876 RFC 2068 HTTP/1.1 January 1997
4879 13.5.1 End-to-end and Hop-by-hop Headers
4881 For the purpose of defining the behavior of caches and non-caching
4882 proxies, we divide HTTP headers into two categories:
4884 o End-to-end headers, which must be transmitted to the
4885 ultimate recipient of a request or response. End-to-end
4886 headers in responses must be stored as part of a cache entry
4887 and transmitted in any response formed from a cache entry.
4888 o Hop-by-hop headers, which are meaningful only for a single
4889 transport-level connection, and are not stored by caches or
4890 forwarded by proxies.
4892 The following HTTP/1.1 headers are hop-by-hop headers:
4897 o Proxy-Authenticate
4901 All other headers defined by HTTP/1.1 are end-to-end headers.
4903 Hop-by-hop headers introduced in future versions of HTTP MUST be
4904 listed in a Connection header, as described in section 14.10.
4906 13.5.2 Non-modifiable Headers
4908 Some features of the HTTP/1.1 protocol, such as Digest
4909 Authentication, depend on the value of certain end-to-end headers. A
4910 cache or non-caching proxy SHOULD NOT modify an end-to-end header
4911 unless the definition of that header requires or specifically allows
4914 A cache or non-caching proxy MUST NOT modify any of the following
4915 fields in a request or response, nor may it add any of these fields
4916 if not already present:
4930 Fielding, et. al. Standards Track [Page 88]
4932 RFC 2068 HTTP/1.1 January 1997
4935 A cache or non-caching proxy MUST NOT modify or add any of the
4936 following fields in a response that contains the no-transform Cache-
4937 Control directive, or in any request:
4944 A cache or non-caching proxy MAY modify or add these fields in a
4945 response that does not include no-transform, but if it does so, it
4946 MUST add a Warning 14 (Transformation applied) if one does not
4947 already appear in the response.
4949 Warning: unnecessary modification of end-to-end headers may cause
4950 authentication failures if stronger authentication mechanisms are
4951 introduced in later versions of HTTP. Such authentication
4952 mechanisms may rely on the values of header fields not listed here.
4954 13.5.3 Combining Headers
4956 When a cache makes a validating request to a server, and the server
4957 provides a 304 (Not Modified) response, the cache must construct a
4958 response to send to the requesting client. The cache uses the
4959 entity-body stored in the cache entry as the entity-body of this
4960 outgoing response. The end-to-end headers stored in the cache entry
4961 are used for the constructed response, except that any end-to-end
4962 headers provided in the 304 response MUST replace the corresponding
4963 headers from the cache entry. Unless the cache decides to remove the
4964 cache entry, it MUST also replace the end-to-end headers stored with
4965 the cache entry with corresponding headers received in the incoming
4968 In other words, the set of end-to-end headers received in the
4969 incoming response overrides all corresponding end-to-end headers
4970 stored with the cache entry. The cache may add Warning headers (see
4971 section 14.45) to this set.
4973 If a header field-name in the incoming response matches more than one
4974 header in the cache entry, all such old headers are replaced.
4976 Note: this rule allows an origin server to use a 304 (Not Modified)
4977 response to update any header associated with a previous response
4978 for the same entity, although it might not always be meaningful or
4979 correct to do so. This rule does not allow an origin server to use
4980 a 304 (not Modified) response to entirely delete a header that it
4981 had provided with a previous response.
4986 Fielding, et. al. Standards Track [Page 89]
4988 RFC 2068 HTTP/1.1 January 1997
4991 13.5.4 Combining Byte Ranges
4993 A response may transfer only a subrange of the bytes of an entity-
4994 body, either because the request included one or more Range
4995 specifications, or because a connection was broken prematurely. After
4996 several such transfers, a cache may have received several ranges of
4997 the same entity-body.
4999 If a cache has a stored non-empty set of subranges for an entity, and
5000 an incoming response transfers another subrange, the cache MAY
5001 combine the new subrange with the existing set if both the following
5004 o Both the incoming response and the cache entry must have a cache
5006 o The two cache validators must match using the strong comparison
5007 function (see section 13.3.3).
5009 If either requirement is not meant, the cache must use only the most
5010 recent partial response (based on the Date values transmitted with
5011 every response, and using the incoming response if these values are
5012 equal or missing), and must discard the other partial information.
5014 13.6 Caching Negotiated Responses
5016 Use of server-driven content negotiation (section 12), as indicated
5017 by the presence of a Vary header field in a response, alters the
5018 conditions and procedure by which a cache can use the response for
5019 subsequent requests.
5021 A server MUST use the Vary header field (section 14.43) to inform a
5022 cache of what header field dimensions are used to select among
5023 multiple representations of a cachable response. A cache may use the
5024 selected representation (the entity included with that particular
5025 response) for replying to subsequent requests on that resource only
5026 when the subsequent requests have the same or equivalent values for
5027 all header fields specified in the Vary response-header. Requests
5028 with a different value for one or more of those header fields would
5029 be forwarded toward the origin server.
5031 If an entity tag was assigned to the representation, the forwarded
5032 request SHOULD be conditional and include the entity tags in an If-
5033 None-Match header field from all its cache entries for the Request-
5034 URI. This conveys to the server the set of entities currently held by
5035 the cache, so that if any one of these entities matches the requested
5036 entity, the server can use the ETag header in its 304 (Not Modified)
5037 response to tell the cache which entry is appropriate. If the
5038 entity-tag of the new response matches that of an existing entry, the
5042 Fielding, et. al. Standards Track [Page 90]
5044 RFC 2068 HTTP/1.1 January 1997
5047 new response SHOULD be used to update the header fields of the
5048 existing entry, and the result MUST be returned to the client.
5050 The Vary header field may also inform the cache that the
5051 representation was selected using criteria not limited to the
5052 request-headers; in this case, a cache MUST NOT use the response in a
5053 reply to a subsequent request unless the cache relays the new request
5054 to the origin server in a conditional request and the server responds
5055 with 304 (Not Modified), including an entity tag or Content-Location
5056 that indicates which entity should be used.
5058 If any of the existing cache entries contains only partial content
5059 for the associated entity, its entity-tag SHOULD NOT be included in
5060 the If-None-Match header unless the request is for a range that would
5061 be fully satisfied by that entry.
5063 If a cache receives a successful response whose Content-Location
5064 field matches that of an existing cache entry for the same Request-
5065 URI, whose entity-tag differs from that of the existing entry, and
5066 whose Date is more recent than that of the existing entry, the
5067 existing entry SHOULD NOT be returned in response to future requests,
5068 and should be deleted from the cache.
5070 13.7 Shared and Non-Shared Caches
5072 For reasons of security and privacy, it is necessary to make a
5073 distinction between "shared" and "non-shared" caches. A non-shared
5074 cache is one that is accessible only to a single user. Accessibility
5075 in this case SHOULD be enforced by appropriate security mechanisms.
5076 All other caches are considered to be "shared." Other sections of
5077 this specification place certain constraints on the operation of
5078 shared caches in order to prevent loss of privacy or failure of
5081 13.8 Errors or Incomplete Response Cache Behavior
5083 A cache that receives an incomplete response (for example, with fewer
5084 bytes of data than specified in a Content-Length header) may store
5085 the response. However, the cache MUST treat this as a partial
5086 response. Partial responses may be combined as described in section
5087 13.5.4; the result might be a full response or might still be
5088 partial. A cache MUST NOT return a partial response to a client
5089 without explicitly marking it as such, using the 206 (Partial
5090 Content) status code. A cache MUST NOT return a partial response
5091 using a status code of 200 (OK).
5093 If a cache receives a 5xx response while attempting to revalidate an
5094 entry, it may either forward this response to the requesting client,
5098 Fielding, et. al. Standards Track [Page 91]
5100 RFC 2068 HTTP/1.1 January 1997
5103 or act as if the server failed to respond. In the latter case, it MAY
5104 return a previously received response unless the cached entry
5105 includes the "must-revalidate" Cache-Control directive (see section
5108 13.9 Side Effects of GET and HEAD
5110 Unless the origin server explicitly prohibits the caching of their
5111 responses, the application of GET and HEAD methods to any resources
5112 SHOULD NOT have side effects that would lead to erroneous behavior if
5113 these responses are taken from a cache. They may still have side
5114 effects, but a cache is not required to consider such side effects in
5115 its caching decisions. Caches are always expected to observe an
5116 origin server's explicit restrictions on caching.
5118 We note one exception to this rule: since some applications have
5119 traditionally used GETs and HEADs with query URLs (those containing a
5120 "?" in the rel_path part) to perform operations with significant side
5121 effects, caches MUST NOT treat responses to such URLs as fresh unless
5122 the server provides an explicit expiration time. This specifically
5123 means that responses from HTTP/1.0 servers for such URIs should not
5124 be taken from a cache. See section 9.1.1 for related information.
5126 13.10 Invalidation After Updates or Deletions
5128 The effect of certain methods at the origin server may cause one or
5129 more existing cache entries to become non-transparently invalid. That
5130 is, although they may continue to be "fresh," they do not accurately
5131 reflect what the origin server would return for a new request.
5133 There is no way for the HTTP protocol to guarantee that all such
5134 cache entries are marked invalid. For example, the request that
5135 caused the change at the origin server may not have gone through the
5136 proxy where a cache entry is stored. However, several rules help
5137 reduce the likelihood of erroneous behavior.
5139 In this section, the phrase "invalidate an entity" means that the
5140 cache should either remove all instances of that entity from its
5141 storage, or should mark these as "invalid" and in need of a mandatory
5142 revalidation before they can be returned in response to a subsequent
5154 Fielding, et. al. Standards Track [Page 92]
5156 RFC 2068 HTTP/1.1 January 1997
5159 Some HTTP methods may invalidate an entity. This is either the entity
5160 referred to by the Request-URI, or by the Location or Content-
5161 Location response-headers (if present). These methods are:
5167 In order to prevent denial of service attacks, an invalidation based
5168 on the URI in a Location or Content-Location header MUST only be
5169 performed if the host part is the same as in the Request-URI.
5171 13.11 Write-Through Mandatory
5173 All methods that may be expected to cause modifications to the origin
5174 server's resources MUST be written through to the origin server. This
5175 currently includes all methods except for GET and HEAD. A cache MUST
5176 NOT reply to such a request from a client before having transmitted
5177 the request to the inbound server, and having received a
5178 corresponding response from the inbound server. This does not prevent
5179 a cache from sending a 100 (Continue) response before the inbound
5182 The alternative (known as "write-back" or "copy-back" caching) is not
5183 allowed in HTTP/1.1, due to the difficulty of providing consistent
5184 updates and the problems arising from server, cache, or network
5185 failure prior to write-back.
5187 13.12 Cache Replacement
5189 If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
5190 response is received from a resource while any existing responses for
5191 the same resource are cached, the cache SHOULD use the new response
5192 to reply to the current request. It may insert it into cache storage
5193 and may, if it meets all other requirements, use it to respond to any
5194 future requests that would previously have caused the old response to
5195 be returned. If it inserts the new response into cache storage it
5196 should follow the rules in section 13.5.3.
5198 Note: a new response that has an older Date header value than
5199 existing cached responses is not cachable.
5203 User agents often have history mechanisms, such as "Back" buttons and
5204 history lists, which can be used to redisplay an entity retrieved
5205 earlier in a session.
5210 Fielding, et. al. Standards Track [Page 93]
5212 RFC 2068 HTTP/1.1 January 1997
5215 History mechanisms and caches are different. In particular history
5216 mechanisms SHOULD NOT try to show a semantically transparent view of
5217 the current state of a resource. Rather, a history mechanism is meant
5218 to show exactly what the user saw at the time when the resource was
5221 By default, an expiration time does not apply to history mechanisms.
5222 If the entity is still in storage, a history mechanism should display
5223 it even if the entity has expired, unless the user has specifically
5224 configured the agent to refresh expired history documents.
5226 This should not be construed to prohibit the history mechanism from
5227 telling the user that a view may be stale.
5229 Note: if history list mechanisms unnecessarily prevent users from
5230 viewing stale resources, this will tend to force service authors to
5231 avoid using HTTP expiration controls and cache controls when they
5232 would otherwise like to. Service authors may consider it important
5233 that users not be presented with error messages or warning messages
5234 when they use navigation controls (such as BACK) to view previously
5235 fetched resources. Even though sometimes such resources ought not
5236 to cached, or ought to expire quickly, user interface
5237 considerations may force service authors to resort to other means
5238 of preventing caching (e.g. "once-only" URLs) in order not to
5239 suffer the effects of improperly functioning history mechanisms.
5241 14 Header Field Definitions
5243 This section defines the syntax and semantics of all standard
5244 HTTP/1.1 header fields. For entity-header fields, both sender and
5245 recipient refer to either the client or the server, depending on who
5246 sends and who receives the entity.
5266 Fielding, et. al. Standards Track [Page 94]
5268 RFC 2068 HTTP/1.1 January 1997
5273 The Accept request-header field can be used to specify certain media
5274 types which are acceptable for the response. Accept headers can be
5275 used to indicate that the request is specifically limited to a small
5276 set of desired types, as in the case of a request for an in-line
5279 Accept = "Accept" ":"
5280 #( media-range [ accept-params ] )
5282 media-range = ( "*/*"
5284 | ( type "/" subtype )
5285 ) *( ";" parameter )
5287 accept-params = ";" "q" "=" qvalue *( accept-extension )
5289 accept-extension = ";" token [ "=" ( token | quoted-string ) ]
5291 The asterisk "*" character is used to group media types into ranges,
5292 with "*/*" indicating all media types and "type/*" indicating all
5293 subtypes of that type. The media-range MAY include media type
5294 parameters that are applicable to that range.
5296 Each media-range MAY be followed by one or more accept-params,
5297 beginning with the "q" parameter for indicating a relative quality
5298 factor. The first "q" parameter (if any) separates the media-range
5299 parameter(s) from the accept-params. Quality factors allow the user
5300 or user agent to indicate the relative degree of preference for that
5301 media-range, using the qvalue scale from 0 to 1 (section 3.9). The
5302 default value is q=1.
5304 Note: Use of the "q" parameter name to separate media type
5305 parameters from Accept extension parameters is due to historical
5306 practice. Although this prevents any media type parameter named
5307 "q" from being used with a media range, such an event is believed
5308 to be unlikely given the lack of any "q" parameters in the IANA
5309 media type registry and the rare usage of any media type parameters
5310 in Accept. Future media types should be discouraged from
5311 registering any parameter named "q".
5315 Accept: audio/*; q=0.2, audio/basic
5317 SHOULD be interpreted as "I prefer audio/basic, but send me any audio
5318 type if it is the best available after an 80% mark-down in quality."
5322 Fielding, et. al. Standards Track [Page 95]
5324 RFC 2068 HTTP/1.1 January 1997
5327 If no Accept header field is present, then it is assumed that the
5328 client accepts all media types. If an Accept header field is present,
5329 and if the server cannot send a response which is acceptable
5330 according to the combined Accept field value, then the server SHOULD
5331 send a 406 (not acceptable) response.
5333 A more elaborate example is
5335 Accept: text/plain; q=0.5, text/html,
5336 text/x-dvi; q=0.8, text/x-c
5338 Verbally, this would be interpreted as "text/html and text/x-c are
5339 the preferred media types, but if they do not exist, then send the
5340 text/x-dvi entity, and if that does not exist, send the text/plain
5343 Media ranges can be overridden by more specific media ranges or
5344 specific media types. If more than one media range applies to a given
5345 type, the most specific reference has precedence. For example,
5347 Accept: text/*, text/html, text/html;level=1, */*
5349 have the following precedence:
5351 1) text/html;level=1
5356 The media type quality factor associated with a given type is
5357 determined by finding the media range with the highest precedence
5358 which matches that type. For example,
5360 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
5361 text/html;level=2;q=0.4, */*;q=0.5
5363 would cause the following values to be associated:
5365 text/html;level=1 = 1
5369 text/html;level=2 = 0.4
5370 text/html;level=3 = 0.7
5372 Note: A user agent may be provided with a default set of quality
5373 values for certain media ranges. However, unless the user agent is
5374 a closed system which cannot interact with other rendering agents,
5378 Fielding, et. al. Standards Track [Page 96]
5380 RFC 2068 HTTP/1.1 January 1997
5383 this default set should be configurable by the user.
5387 The Accept-Charset request-header field can be used to indicate what
5388 character sets are acceptable for the response. This field allows
5389 clients capable of understanding more comprehensive or special-
5390 purpose character sets to signal that capability to a server which is
5391 capable of representing documents in those character sets. The ISO-
5392 8859-1 character set can be assumed to be acceptable to all user
5395 Accept-Charset = "Accept-Charset" ":"
5396 1#( charset [ ";" "q" "=" qvalue ] )
5398 Character set values are described in section 3.4. Each charset may
5399 be given an associated quality value which represents the user's
5400 preference for that charset. The default value is q=1. An example is
5402 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
5404 If no Accept-Charset header is present, the default is that any
5405 character set is acceptable. If an Accept-Charset header is present,
5406 and if the server cannot send a response which is acceptable
5407 according to the Accept-Charset header, then the server SHOULD send
5408 an error response with the 406 (not acceptable) status code, though
5409 the sending of an unacceptable response is also allowed.
5411 14.3 Accept-Encoding
5413 The Accept-Encoding request-header field is similar to Accept, but
5414 restricts the content-coding values (section 14.12) which are
5415 acceptable in the response.
5417 Accept-Encoding = "Accept-Encoding" ":"
5420 An example of its use is
5422 Accept-Encoding: compress, gzip
5424 If no Accept-Encoding header is present in a request, the server MAY
5425 assume that the client will accept any content coding. If an Accept-
5426 Encoding header is present, and if the server cannot send a response
5427 which is acceptable according to the Accept-Encoding header, then the
5428 server SHOULD send an error response with the 406 (Not Acceptable)
5434 Fielding, et. al. Standards Track [Page 97]
5436 RFC 2068 HTTP/1.1 January 1997
5439 An empty Accept-Encoding value indicates none are acceptable.
5441 14.4 Accept-Language
5443 The Accept-Language request-header field is similar to Accept, but
5444 restricts the set of natural languages that are preferred as a
5445 response to the request.
5447 Accept-Language = "Accept-Language" ":"
5448 1#( language-range [ ";" "q" "=" qvalue ] )
5450 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
5452 Each language-range MAY be given an associated quality value which
5453 represents an estimate of the user's preference for the languages
5454 specified by that range. The quality value defaults to "q=1". For
5457 Accept-Language: da, en-gb;q=0.8, en;q=0.7
5459 would mean: "I prefer Danish, but will accept British English and
5460 other types of English." A language-range matches a language-tag if
5461 it exactly equals the tag, or if it exactly equals a prefix of the
5462 tag such that the first tag character following the prefix is "-".
5463 The special range "*", if present in the Accept-Language field,
5464 matches every tag not matched by any other range present in the
5465 Accept-Language field.
5467 Note: This use of a prefix matching rule does not imply that
5468 language tags are assigned to languages in such a way that it is
5469 always true that if a user understands a language with a certain
5470 tag, then this user will also understand all languages with tags
5471 for which this tag is a prefix. The prefix rule simply allows the
5472 use of prefix tags if this is the case.
5474 The language quality factor assigned to a language-tag by the
5475 Accept-Language field is the quality value of the longest language-
5476 range in the field that matches the language-tag. If no language-
5477 range in the field matches the tag, the language quality factor
5478 assigned is 0. If no Accept-Language header is present in the
5479 request, the server SHOULD assume that all languages are equally
5480 acceptable. If an Accept-Language header is present, then all
5481 languages which are assigned a quality factor greater than 0 are
5484 It may be contrary to the privacy expectations of the user to send an
5485 Accept-Language header with the complete linguistic preferences of
5486 the user in every request. For a discussion of this issue, see
5490 Fielding, et. al. Standards Track [Page 98]
5492 RFC 2068 HTTP/1.1 January 1997
5497 Note: As intelligibility is highly dependent on the individual
5498 user, it is recommended that client applications make the choice of
5499 linguistic preference available to the user. If the choice is not
5500 made available, then the Accept-Language header field must not be
5501 given in the request.
5505 The Accept-Ranges response-header field allows the server to indicate
5506 its acceptance of range requests for a resource:
5508 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
5510 acceptable-ranges = 1#range-unit | "none"
5512 Origin servers that accept byte-range requests MAY send
5514 Accept-Ranges: bytes
5516 but are not required to do so. Clients MAY generate byte-range
5517 requests without having received this header for the resource
5520 Servers that do not accept any kind of range request for a resource
5525 to advise the client not to attempt a range request.
5529 The Age response-header field conveys the sender's estimate of the
5530 amount of time since the response (or its revalidation) was generated
5531 at the origin server. A cached response is "fresh" if its age does
5532 not exceed its freshness lifetime. Age values are calculated as
5533 specified in section 13.2.3.
5535 Age = "Age" ":" age-value
5537 age-value = delta-seconds
5539 Age values are non-negative decimal integers, representing time in
5546 Fielding, et. al. Standards Track [Page 99]
5548 RFC 2068 HTTP/1.1 January 1997
5551 If a cache receives a value larger than the largest positive integer
5552 it can represent, or if any of its age calculations overflows, it
5553 MUST transmit an Age header with a value of 2147483648 (2^31).
5554 HTTP/1.1 caches MUST send an Age header in every response. Caches
5555 SHOULD use an arithmetic type of at least 31 bits of range.
5559 The Allow entity-header field lists the set of methods supported by
5560 the resource identified by the Request-URI. The purpose of this field
5561 is strictly to inform the recipient of valid methods associated with
5562 the resource. An Allow header field MUST be present in a 405 (Method
5563 Not Allowed) response.
5565 Allow = "Allow" ":" 1#method
5569 Allow: GET, HEAD, PUT
5571 This field cannot prevent a client from trying other methods.
5572 However, the indications given by the Allow header field value SHOULD
5573 be followed. The actual set of allowed methods is defined by the
5574 origin server at the time of each request.
5576 The Allow header field MAY be provided with a PUT request to
5577 recommend the methods to be supported by the new or modified
5578 resource. The server is not required to support these methods and
5579 SHOULD include an Allow header in the response giving the actual
5582 A proxy MUST NOT modify the Allow header field even if it does not
5583 understand all the methods specified, since the user agent MAY have
5584 other means of communicating with the origin server.
5586 The Allow header field does not indicate what methods are implemented
5587 at the server level. Servers MAY use the Public response-header field
5588 (section 14.35) to describe what methods are implemented on the
5593 A user agent that wishes to authenticate itself with a server--
5594 usually, but not necessarily, after receiving a 401 response--MAY do
5595 so by including an Authorization request-header field with the
5596 request. The Authorization field value consists of credentials
5597 containing the authentication information of the user agent for the
5598 realm of the resource being requested.
5602 Fielding, et. al. Standards Track [Page 100]
5604 RFC 2068 HTTP/1.1 January 1997
5607 Authorization = "Authorization" ":" credentials
5609 HTTP access authentication is described in section 11. If a request
5610 is authenticated and a realm specified, the same credentials SHOULD
5611 be valid for all other requests within this realm.
5613 When a shared cache (see section 13.7) receives a request containing
5614 an Authorization field, it MUST NOT return the corresponding response
5615 as a reply to any other request, unless one of the following specific
5618 1. If the response includes the "proxy-revalidate" Cache-Control
5619 directive, the cache MAY use that response in replying to a
5620 subsequent request, but a proxy cache MUST first revalidate it with
5621 the origin server, using the request-headers from the new request
5622 to allow the origin server to authenticate the new request.
5623 2. If the response includes the "must-revalidate" Cache-Control
5624 directive, the cache MAY use that response in replying to a
5625 subsequent request, but all caches MUST first revalidate it with
5626 the origin server, using the request-headers from the new request
5627 to allow the origin server to authenticate the new request.
5628 3. If the response includes the "public" Cache-Control directive, it
5629 may be returned in reply to any subsequent request.
5633 The Cache-Control general-header field is used to specify directives
5634 that MUST be obeyed by all caching mechanisms along the
5635 request/response chain. The directives specify behavior intended to
5636 prevent caches from adversely interfering with the request or
5637 response. These directives typically override the default caching
5638 algorithms. Cache directives are unidirectional in that the presence
5639 of a directive in a request does not imply that the same directive
5640 should be given in the response.
5642 Note that HTTP/1.0 caches may not implement Cache-Control and may
5643 only implement Pragma: no-cache (see section 14.32).
5645 Cache directives must be passed through by a proxy or gateway
5646 application, regardless of their significance to that application,
5647 since the directives may be applicable to all recipients along the
5648 request/response chain. It is not possible to specify a cache-
5649 directive for a specific cache.
5651 Cache-Control = "Cache-Control" ":" 1#cache-directive
5653 cache-directive = cache-request-directive
5654 | cache-response-directive
5658 Fielding, et. al. Standards Track [Page 101]
5660 RFC 2068 HTTP/1.1 January 1997
5663 cache-request-directive =
5664 "no-cache" [ "=" <"> 1#field-name <"> ]
5666 | "max-age" "=" delta-seconds
5667 | "max-stale" [ "=" delta-seconds ]
5668 | "min-fresh" "=" delta-seconds
5672 cache-response-directive =
5674 | "private" [ "=" <"> 1#field-name <"> ]
5675 | "no-cache" [ "=" <"> 1#field-name <"> ]
5679 | "proxy-revalidate"
5680 | "max-age" "=" delta-seconds
5683 cache-extension = token [ "=" ( token | quoted-string ) ]
5685 When a directive appears without any 1#field-name parameter, the
5686 directive applies to the entire request or response. When such a
5687 directive appears with a 1#field-name parameter, it applies only to
5688 the named field or fields, and not to the rest of the request or
5689 response. This mechanism supports extensibility; implementations of
5690 future versions of the HTTP protocol may apply these directives to
5691 header fields not defined in HTTP/1.1.
5693 The cache-control directives can be broken down into these general
5696 o Restrictions on what is cachable; these may only be imposed by the
5698 o Restrictions on what may be stored by a cache; these may be imposed
5699 by either the origin server or the user agent.
5700 o Modifications of the basic expiration mechanism; these may be
5701 imposed by either the origin server or the user agent.
5702 o Controls over cache revalidation and reload; these may only be
5703 imposed by a user agent.
5704 o Control over transformation of entities.
5705 o Extensions to the caching system.
5714 Fielding, et. al. Standards Track [Page 102]
5716 RFC 2068 HTTP/1.1 January 1997
5719 14.9.1 What is Cachable
5721 By default, a response is cachable if the requirements of the request
5722 method, request header fields, and the response status indicate that
5723 it is cachable. Section 13.4 summarizes these defaults for
5724 cachability. The following Cache-Control response directives allow an
5725 origin server to override the default cachability of a response:
5728 Indicates that the response is cachable by any cache, even if it
5729 would normally be non-cachable or cachable only within a non-shared
5730 cache. (See also Authorization, section 14.8, for additional
5734 Indicates that all or part of the response message is intended for a
5735 single user and MUST NOT be cached by a shared cache. This allows an
5736 origin server to state that the specified parts of the response are
5737 intended for only one user and are not a valid response for requests
5738 by other users. A private (non-shared) cache may cache the response.
5740 Note: This usage of the word private only controls where the
5741 response may be cached, and cannot ensure the privacy of the
5745 Indicates that all or part of the response message MUST NOT be cached
5746 anywhere. This allows an origin server to prevent caching even by
5747 caches that have been configured to return stale responses to client
5750 Note: Most HTTP/1.0 caches will not recognize or obey this
5753 14.9.2 What May be Stored by Caches
5755 The purpose of the no-store directive is to prevent the inadvertent
5756 release or retention of sensitive information (for example, on backup
5757 tapes). The no-store directive applies to the entire message, and may
5758 be sent either in a response or in a request. If sent in a request, a
5759 cache MUST NOT store any part of either this request or any response
5760 to it. If sent in a response, a cache MUST NOT store any part of
5761 either this response or the request that elicited it. This directive
5762 applies to both non-shared and shared caches. "MUST NOT store" in
5763 this context means that the cache MUST NOT intentionally store the
5764 information in non-volatile storage, and MUST make a best-effort
5765 attempt to remove the information from volatile storage as promptly
5766 as possible after forwarding it.
5770 Fielding, et. al. Standards Track [Page 103]
5772 RFC 2068 HTTP/1.1 January 1997
5775 Even when this directive is associated with a response, users may
5776 explicitly store such a response outside of the caching system (e.g.,
5777 with a "Save As" dialog). History buffers may store such responses as
5778 part of their normal operation.
5780 The purpose of this directive is to meet the stated requirements of
5781 certain users and service authors who are concerned about accidental
5782 releases of information via unanticipated accesses to cache data
5783 structures. While the use of this directive may improve privacy in
5784 some cases, we caution that it is NOT in any way a reliable or
5785 sufficient mechanism for ensuring privacy. In particular, malicious
5786 or compromised caches may not recognize or obey this directive; and
5787 communications networks may be vulnerable to eavesdropping.
5789 14.9.3 Modifications of the Basic Expiration Mechanism
5791 The expiration time of an entity may be specified by the origin
5792 server using the Expires header (see section 14.21). Alternatively,
5793 it may be specified using the max-age directive in a response.
5795 If a response includes both an Expires header and a max-age
5796 directive, the max-age directive overrides the Expires header, even
5797 if the Expires header is more restrictive. This rule allows an origin
5798 server to provide, for a given response, a longer expiration time to
5799 an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
5800 useful if certain HTTP/1.0 caches improperly calculate ages or
5801 expiration times, perhaps due to desynchronized clocks.
5803 Note: most older caches, not compliant with this specification, do
5804 not implement any Cache-Control directives. An origin server
5805 wishing to use a Cache-Control directive that restricts, but does
5806 not prevent, caching by an HTTP/1.1-compliant cache may exploit the
5807 requirement that the max-age directive overrides the Expires
5808 header, and the fact that non-HTTP/1.1-compliant caches do not
5809 observe the max-age directive.
5811 Other directives allow an user agent to modify the basic expiration
5812 mechanism. These directives may be specified on a request:
5815 Indicates that the client is willing to accept a response whose age
5816 is no greater than the specified time in seconds. Unless max-stale
5817 directive is also included, the client is not willing to accept a
5821 Indicates that the client is willing to accept a response whose
5822 freshness lifetime is no less than its current age plus the
5826 Fielding, et. al. Standards Track [Page 104]
5828 RFC 2068 HTTP/1.1 January 1997
5831 specified time in seconds. That is, the client wants a response
5832 that will still be fresh for at least the specified number of
5836 Indicates that the client is willing to accept a response that has
5837 exceeded its expiration time. If max-stale is assigned a value,
5838 then the client is willing to accept a response that has exceeded
5839 its expiration time by no more than the specified number of
5840 seconds. If no value is assigned to max-stale, then the client is
5841 willing to accept a stale response of any age.
5843 If a cache returns a stale response, either because of a max-stale
5844 directive on a request, or because the cache is configured to
5845 override the expiration time of a response, the cache MUST attach a
5846 Warning header to the stale response, using Warning 10 (Response is
5849 14.9.4 Cache Revalidation and Reload Controls
5851 Sometimes an user agent may want or need to insist that a cache
5852 revalidate its cache entry with the origin server (and not just with
5853 the next cache along the path to the origin server), or to reload its
5854 cache entry from the origin server. End-to-end revalidation may be
5855 necessary if either the cache or the origin server has overestimated
5856 the expiration time of the cached response. End-to-end reload may be
5857 necessary if the cache entry has become corrupted for some reason.
5859 End-to-end revalidation may be requested either when the client does
5860 not have its own local cached copy, in which case we call it
5861 "unspecified end-to-end revalidation", or when the client does have a
5862 local cached copy, in which case we call it "specific end-to-end
5865 The client can specify these three kinds of action using Cache-
5866 Control request directives:
5869 The request includes a "no-cache" Cache-Control directive or, for
5870 compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
5871 names may be included with the no-cache directive in a request. The
5872 server MUST NOT use a cached copy when responding to such a
5875 Specific end-to-end revalidation
5876 The request includes a "max-age=0" Cache-Control directive, which
5877 forces each cache along the path to the origin server to revalidate
5878 its own entry, if any, with the next cache or server. The initial
5882 Fielding, et. al. Standards Track [Page 105]
5884 RFC 2068 HTTP/1.1 January 1997
5887 request includes a cache-validating conditional with the client's
5890 Unspecified end-to-end revalidation
5891 The request includes "max-age=0" Cache-Control directive, which
5892 forces each cache along the path to the origin server to revalidate
5893 its own entry, if any, with the next cache or server. The initial
5894 request does not include a cache-validating conditional; the first
5895 cache along the path (if any) that holds a cache entry for this
5896 resource includes a cache-validating conditional with its current
5899 When an intermediate cache is forced, by means of a max-age=0
5900 directive, to revalidate its own cache entry, and the client has
5901 supplied its own validator in the request, the supplied validator may
5902 differ from the validator currently stored with the cache entry. In
5903 this case, the cache may use either validator in making its own
5904 request without affecting semantic transparency.
5906 However, the choice of validator may affect performance. The best
5907 approach is for the intermediate cache to use its own validator when
5908 making its request. If the server replies with 304 (Not Modified),
5909 then the cache should return its now validated copy to the client
5910 with a 200 (OK) response. If the server replies with a new entity and
5911 cache validator, however, the intermediate cache should compare the
5912 returned validator with the one provided in the client's request,
5913 using the strong comparison function. If the client's validator is
5914 equal to the origin server's, then the intermediate cache simply
5915 returns 304 (Not Modified). Otherwise, it returns the new entity with
5916 a 200 (OK) response.
5918 If a request includes the no-cache directive, it should not include
5919 min-fresh, max-stale, or max-age.
5921 In some cases, such as times of extremely poor network connectivity,
5922 a client may want a cache to return only those responses that it
5923 currently has stored, and not to reload or revalidate with the origin
5924 server. To do this, the client may include the only-if-cached
5925 directive in a request. If it receives this directive, a cache SHOULD
5926 either respond using a cached entry that is consistent with the other
5927 constraints of the request, or respond with a 504 (Gateway Timeout)
5928 status. However, if a group of caches is being operated as a unified
5929 system with good internal connectivity, such a request MAY be
5930 forwarded within that group of caches.
5932 Because a cache may be configured to ignore a server's specified
5933 expiration time, and because a client request may include a max-stale
5934 directive (which has a similar effect), the protocol also includes a
5938 Fielding, et. al. Standards Track [Page 106]
5940 RFC 2068 HTTP/1.1 January 1997
5943 mechanism for the origin server to require revalidation of a cache
5944 entry on any subsequent use. When the must-revalidate directive is
5945 present in a response received by a cache, that cache MUST NOT use
5946 the entry after it becomes stale to respond to a subsequent request
5947 without first revalidating it with the origin server. (I.e., the
5948 cache must do an end-to-end revalidation every time, if, based solely
5949 on the origin server's Expires or max-age value, the cached response
5952 The must-revalidate directive is necessary to support reliable
5953 operation for certain protocol features. In all circumstances an
5954 HTTP/1.1 cache MUST obey the must-revalidate directive; in
5955 particular, if the cache cannot reach the origin server for any
5956 reason, it MUST generate a 504 (Gateway Timeout) response.
5958 Servers should send the must-revalidate directive if and only if
5959 failure to revalidate a request on the entity could result in
5960 incorrect operation, such as a silently unexecuted financial
5961 transaction. Recipients MUST NOT take any automated action that
5962 violates this directive, and MUST NOT automatically provide an
5963 unvalidated copy of the entity if revalidation fails.
5965 Although this is not recommended, user agents operating under severe
5966 connectivity constraints may violate this directive but, if so, MUST
5967 explicitly warn the user that an unvalidated response has been
5968 provided. The warning MUST be provided on each unvalidated access,
5969 and SHOULD require explicit user confirmation.
5971 The proxy-revalidate directive has the same meaning as the must-
5972 revalidate directive, except that it does not apply to non-shared
5973 user agent caches. It can be used on a response to an authenticated
5974 request to permit the user's cache to store and later return the
5975 response without needing to revalidate it (since it has already been
5976 authenticated once by that user), while still requiring proxies that
5977 service many users to revalidate each time (in order to make sure
5978 that each user has been authenticated). Note that such authenticated
5979 responses also need the public cache control directive in order to
5980 allow them to be cached at all.
5982 14.9.5 No-Transform Directive
5984 Implementers of intermediate caches (proxies) have found it useful to
5985 convert the media type of certain entity bodies. A proxy might, for
5986 example, convert between image formats in order to save cache space
5987 or to reduce the amount of traffic on a slow link. HTTP has to date
5988 been silent on these transformations.
5994 Fielding, et. al. Standards Track [Page 107]
5996 RFC 2068 HTTP/1.1 January 1997
5999 Serious operational problems have already occurred, however, when
6000 these transformations have been applied to entity bodies intended for
6001 certain kinds of applications. For example, applications for medical
6002 imaging, scientific data analysis and those using end-to-end
6003 authentication, all depend on receiving an entity body that is bit
6004 for bit identical to the original entity-body.
6006 Therefore, if a response includes the no-transform directive, an
6007 intermediate cache or proxy MUST NOT change those headers that are
6008 listed in section 13.5.2 as being subject to the no-transform
6009 directive. This implies that the cache or proxy must not change any
6010 aspect of the entity-body that is specified by these headers.
6012 14.9.6 Cache Control Extensions
6014 The Cache-Control header field can be extended through the use of one
6015 or more cache-extension tokens, each with an optional assigned value.
6016 Informational extensions (those which do not require a change in
6017 cache behavior) may be added without changing the semantics of other
6018 directives. Behavioral extensions are designed to work by acting as
6019 modifiers to the existing base of cache directives. Both the new
6020 directive and the standard directive are supplied, such that
6021 applications which do not understand the new directive will default
6022 to the behavior specified by the standard directive, and those that
6023 understand the new directive will recognize it as modifying the
6024 requirements associated with the standard directive. In this way,
6025 extensions to the Cache-Control directives can be made without
6026 requiring changes to the base protocol.
6028 This extension mechanism depends on a HTTP cache obeying all of the
6029 cache-control directives defined for its native HTTP-version, obeying
6030 certain extensions, and ignoring all directives that it does not
6033 For example, consider a hypothetical new response directive called
6034 "community" which acts as a modifier to the "private" directive. We
6035 define this new directive to mean that, in addition to any non-shared
6036 cache, any cache which is shared only by members of the community
6037 named within its value may cache the response. An origin server
6038 wishing to allow the "UCI" community to use an otherwise private
6039 response in their shared cache(s) may do so by including
6041 Cache-Control: private, community="UCI"
6043 A cache seeing this header field will act correctly even if the cache
6044 does not understand the "community" cache-extension, since it will
6045 also see and understand the "private" directive and thus default to
6050 Fielding, et. al. Standards Track [Page 108]
6052 RFC 2068 HTTP/1.1 January 1997
6055 Unrecognized cache-directives MUST be ignored; it is assumed that any
6056 cache-directive likely to be unrecognized by an HTTP/1.1 cache will
6057 be combined with standard directives (or the response's default
6058 cachability) such that the cache behavior will remain minimally
6059 correct even if the cache does not understand the extension(s).
6063 The Connection general-header field allows the sender to specify
6064 options that are desired for that particular connection and MUST NOT
6065 be communicated by proxies over further connections.
6067 The Connection header has the following grammar:
6069 Connection-header = "Connection" ":" 1#(connection-token)
6070 connection-token = token
6072 HTTP/1.1 proxies MUST parse the Connection header field before a
6073 message is forwarded and, for each connection-token in this field,
6074 remove any header field(s) from the message with the same name as the
6075 connection-token. Connection options are signaled by the presence of
6076 a connection-token in the Connection header field, not by any
6077 corresponding additional header field(s), since the additional header
6078 field may not be sent if there are no parameters associated with that
6079 connection option. HTTP/1.1 defines the "close" connection option
6080 for the sender to signal that the connection will be closed after
6081 completion of the response. For example,
6085 in either the request or the response header fields indicates that
6086 the connection should not be considered `persistent' (section 8.1)
6087 after the current request/response is complete.
6089 HTTP/1.1 applications that do not support persistent connections MUST
6090 include the "close" connection option in every message.
6094 The Content-Base entity-header field may be used to specify the base
6095 URI for resolving relative URLs within the entity. This header field
6096 is described as Base in RFC 1808, which is expected to be revised.
6098 Content-Base = "Content-Base" ":" absoluteURI
6100 If no Content-Base field is present, the base URI of an entity is
6101 defined either by its Content-Location (if that Content-Location URI
6102 is an absolute URI) or the URI used to initiate the request, in that
6106 Fielding, et. al. Standards Track [Page 109]
6108 RFC 2068 HTTP/1.1 January 1997
6111 order of precedence. Note, however, that the base URI of the contents
6112 within the entity-body may be redefined within that entity-body.
6114 14.12 Content-Encoding
6116 The Content-Encoding entity-header field is used as a modifier to the
6117 media-type. When present, its value indicates what additional content
6118 codings have been applied to the entity-body, and thus what decoding
6119 mechanisms MUST be applied in order to obtain the media-type
6120 referenced by the Content-Type header field. Content-Encoding is
6121 primarily used to allow a document to be compressed without losing
6122 the identity of its underlying media type.
6124 Content-Encoding = "Content-Encoding" ":" 1#content-coding
6126 Content codings are defined in section 3.5. An example of its use is
6128 Content-Encoding: gzip
6130 The Content-Encoding is a characteristic of the entity identified by
6131 the Request-URI. Typically, the entity-body is stored with this
6132 encoding and is only decoded before rendering or analogous usage.
6134 If multiple encodings have been applied to an entity, the content
6135 codings MUST be listed in the order in which they were applied.
6137 Additional information about the encoding parameters MAY be provided
6138 by other entity-header fields not defined by this specification.
6140 14.13 Content-Language
6142 The Content-Language entity-header field describes the natural
6143 language(s) of the intended audience for the enclosed entity. Note
6144 that this may not be equivalent to all the languages used within the
6147 Content-Language = "Content-Language" ":" 1#language-tag
6149 Language tags are defined in section 3.10. The primary purpose of
6150 Content-Language is to allow a user to identify and differentiate
6151 entities according to the user's own preferred language. Thus, if the
6152 body content is intended only for a Danish-literate audience, the
6153 appropriate field is
6155 Content-Language: da
6157 If no Content-Language is specified, the default is that the content
6158 is intended for all language audiences. This may mean that the sender
6162 Fielding, et. al. Standards Track [Page 110]
6164 RFC 2068 HTTP/1.1 January 1997
6167 does not consider it to be specific to any natural language, or that
6168 the sender does not know for which language it is intended.
6170 Multiple languages MAY be listed for content that is intended for
6171 multiple audiences. For example, a rendition of the "Treaty of
6172 Waitangi," presented simultaneously in the original Maori and English
6173 versions, would call for
6175 Content-Language: mi, en
6177 However, just because multiple languages are present within an entity
6178 does not mean that it is intended for multiple linguistic audiences.
6179 An example would be a beginner's language primer, such as "A First
6180 Lesson in Latin," which is clearly intended to be used by an
6181 English-literate audience. In this case, the Content-Language should
6184 Content-Language may be applied to any media type -- it is not
6185 limited to textual documents.
6187 14.14 Content-Length
6189 The Content-Length entity-header field indicates the size of the
6190 message-body, in decimal number of octets, sent to the recipient or,
6191 in the case of the HEAD method, the size of the entity-body that
6192 would have been sent had the request been a GET.
6194 Content-Length = "Content-Length" ":" 1*DIGIT
6198 Content-Length: 3495
6200 Applications SHOULD use this field to indicate the size of the
6201 message-body to be transferred, regardless of the media type of the
6202 entity. It must be possible for the recipient to reliably determine
6203 the end of HTTP/1.1 requests containing an entity-body, e.g., because
6204 the request has a valid Content-Length field, uses Transfer-Encoding:
6205 chunked or a multipart body.
6207 Any Content-Length greater than or equal to zero is a valid value.
6208 Section 4.4 describes how to determine the length of a message-body
6209 if a Content-Length is not given.
6218 Fielding, et. al. Standards Track [Page 111]
6220 RFC 2068 HTTP/1.1 January 1997
6223 Note: The meaning of this field is significantly different from the
6224 corresponding definition in MIME, where it is an optional field
6225 used within the "message/external-body" content-type. In HTTP, it
6226 SHOULD be sent whenever the message's length can be determined
6227 prior to being transferred.
6229 14.15 Content-Location
6231 The Content-Location entity-header field may be used to supply the
6232 resource location for the entity enclosed in the message. In the case
6233 where a resource has multiple entities associated with it, and those
6234 entities actually have separate locations by which they might be
6235 individually accessed, the server should provide a Content-Location
6236 for the particular variant which is returned. In addition, a server
6237 SHOULD provide a Content-Location for the resource corresponding to
6238 the response entity.
6240 Content-Location = "Content-Location" ":"
6241 ( absoluteURI | relativeURI )
6243 If no Content-Base header field is present, the value of Content-
6244 Location also defines the base URL for the entity (see section
6247 The Content-Location value is not a replacement for the original
6248 requested URI; it is only a statement of the location of the resource
6249 corresponding to this particular entity at the time of the request.
6250 Future requests MAY use the Content-Location URI if the desire is to
6251 identify the source of that particular entity.
6253 A cache cannot assume that an entity with a Content-Location
6254 different from the URI used to retrieve it can be used to respond to
6255 later requests on that Content-Location URI. However, the Content-
6256 Location can be used to differentiate between multiple entities
6257 retrieved from a single requested resource, as described in section
6260 If the Content-Location is a relative URI, the URI is interpreted
6261 relative to any Content-Base URI provided in the response. If no
6262 Content-Base is provided, the relative URI is interpreted relative to
6274 Fielding, et. al. Standards Track [Page 112]
6276 RFC 2068 HTTP/1.1 January 1997
6281 The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
6282 an MD5 digest of the entity-body for the purpose of providing an
6283 end-to-end message integrity check (MIC) of the entity-body. (Note: a
6284 MIC is good for detecting accidental modification of the entity-body
6285 in transit, but is not proof against malicious attacks.)
6287 Content-MD5 = "Content-MD5" ":" md5-digest
6289 md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
6291 The Content-MD5 header field may be generated by an origin server to
6292 function as an integrity check of the entity-body. Only origin
6293 servers may generate the Content-MD5 header field; proxies and
6294 gateways MUST NOT generate it, as this would defeat its value as an
6295 end-to-end integrity check. Any recipient of the entity-body,
6296 including gateways and proxies, MAY check that the digest value in
6297 this header field matches that of the entity-body as received.
6299 The MD5 digest is computed based on the content of the entity-body,
6300 including any Content-Encoding that has been applied, but not
6301 including any Transfer-Encoding that may have been applied to the
6302 message-body. If the message is received with a Transfer-Encoding,
6303 that encoding must be removed prior to checking the Content-MD5 value
6304 against the received entity.
6306 This has the result that the digest is computed on the octets of the
6307 entity-body exactly as, and in the order that, they would be sent if
6308 no Transfer-Encoding were being applied.
6310 HTTP extends RFC 1864 to permit the digest to be computed for MIME
6311 composite media-types (e.g., multipart/* and message/rfc822), but
6312 this does not change how the digest is computed as defined in the
6313 preceding paragraph.
6315 Note: There are several consequences of this. The entity-body for
6316 composite types may contain many body-parts, each with its own MIME
6317 and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
6318 and Content-Encoding headers). If a body-part has a Content-
6319 Transfer-Encoding or Content-Encoding header, it is assumed that
6320 the content of the body-part has had the encoding applied, and the
6321 body-part is included in the Content-MD5 digest as is -- i.e.,
6322 after the application. The Transfer-Encoding header field is not
6323 allowed within body-parts.
6325 Note: while the definition of Content-MD5 is exactly the same for
6326 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
6330 Fielding, et. al. Standards Track [Page 113]
6332 RFC 2068 HTTP/1.1 January 1997
6335 in which the application of Content-MD5 to HTTP entity-bodies
6336 differs from its application to MIME entity-bodies. One is that
6337 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
6338 use Transfer-Encoding and Content-Encoding. Another is that HTTP
6339 more frequently uses binary content types than MIME, so it is worth
6340 noting that, in such cases, the byte order used to compute the
6341 digest is the transmission byte order defined for the type. Lastly,
6342 HTTP allows transmission of text types with any of several line
6343 break conventions and not just the canonical form using CRLF.
6344 Conversion of all line breaks to CRLF should not be done before
6345 computing or checking the digest: the line break convention used in
6346 the text actually transmitted should be left unaltered when
6347 computing the digest.
6351 The Content-Range entity-header is sent with a partial entity-body to
6352 specify where in the full entity-body the partial body should be
6353 inserted. It also indicates the total size of the full entity-body.
6354 When a server returns a partial response to a client, it must
6355 describe both the extent of the range covered by the response, and
6356 the length of the entire entity-body.
6358 Content-Range = "Content-Range" ":" content-range-spec
6360 content-range-spec = byte-content-range-spec
6362 byte-content-range-spec = bytes-unit SP first-byte-pos "-"
6363 last-byte-pos "/" entity-length
6365 entity-length = 1*DIGIT
6367 Unlike byte-ranges-specifier values, a byte-content-range-spec may
6368 only specify one range, and must contain absolute byte positions for
6369 both the first and last byte of the range.
6371 A byte-content-range-spec whose last-byte-pos value is less than its
6372 first-byte-pos value, or whose entity-length value is less than or
6373 equal to its last-byte-pos value, is invalid. The recipient of an
6374 invalid byte-content-range-spec MUST ignore it and any content
6375 transferred along with it.
6386 Fielding, et. al. Standards Track [Page 114]
6388 RFC 2068 HTTP/1.1 January 1997
6391 Examples of byte-content-range-spec values, assuming that the entity
6392 contains a total of 1234 bytes:
6394 o The first 500 bytes:
6398 o The second 500 bytes:
6402 o All except for the first 500 bytes:
6406 o The last 500 bytes:
6410 When an HTTP message includes the content of a single range (for
6411 example, a response to a request for a single range, or to a request
6412 for a set of ranges that overlap without any holes), this content is
6413 transmitted with a Content-Range header, and a Content-Length header
6414 showing the number of bytes actually transferred. For example,
6416 HTTP/1.1 206 Partial content
6417 Date: Wed, 15 Nov 1995 06:25:24 GMT
6418 Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
6419 Content-Range: bytes 21010-47021/47022
6420 Content-Length: 26012
6421 Content-Type: image/gif
6423 When an HTTP message includes the content of multiple ranges (for
6424 example, a response to a request for multiple non-overlapping
6425 ranges), these are transmitted as a multipart MIME message. The
6426 multipart MIME content-type used for this purpose is defined in this
6427 specification to be "multipart/byteranges". See appendix 19.2 for its
6430 A client that cannot decode a MIME multipart/byteranges message
6431 should not ask for multiple byte-ranges in a single request.
6433 When a client requests multiple byte-ranges in one request, the
6434 server SHOULD return them in the order that they appeared in the
6437 If the server ignores a byte-range-spec because it is invalid, the
6438 server should treat the request as if the invalid Range header field
6442 Fielding, et. al. Standards Track [Page 115]
6444 RFC 2068 HTTP/1.1 January 1997
6447 did not exist. (Normally, this means return a 200 response containing
6448 the full entity). The reason is that the only time a client will make
6449 such an invalid request is when the entity is smaller than the entity
6450 retrieved by a prior request.
6454 The Content-Type entity-header field indicates the media type of the
6455 entity-body sent to the recipient or, in the case of the HEAD method,
6456 the media type that would have been sent had the request been a GET.
6458 Content-Type = "Content-Type" ":" media-type
6459 Media types are defined in section 3.7. An example of the field is
6461 Content-Type: text/html; charset=ISO-8859-4
6463 Further discussion of methods for identifying the media type of an
6464 entity is provided in section 7.2.1.
6468 The Date general-header field represents the date and time at which
6469 the message was originated, having the same semantics as orig-date in
6470 RFC 822. The field value is an HTTP-date, as described in section
6473 Date = "Date" ":" HTTP-date
6477 Date: Tue, 15 Nov 1994 08:12:31 GMT
6479 If a message is received via direct connection with the user agent
6480 (in the case of requests) or the origin server (in the case of
6481 responses), then the date can be assumed to be the current date at
6482 the receiving end. However, since the date--as it is believed by the
6483 origin--is important for evaluating cached responses, origin servers
6484 MUST include a Date header field in all responses. Clients SHOULD
6485 only send a Date header field in messages that include an entity-
6486 body, as in the case of the PUT and POST requests, and even then it
6487 is optional. A received message which does not have a Date header
6488 field SHOULD be assigned one by the recipient if the message will be
6489 cached by that recipient or gatewayed via a protocol which requires a
6498 Fielding, et. al. Standards Track [Page 116]
6500 RFC 2068 HTTP/1.1 January 1997
6503 In theory, the date SHOULD represent the moment just before the
6504 entity is generated. In practice, the date can be generated at any
6505 time during the message origination without affecting its semantic
6508 The format of the Date is an absolute date and time as defined by
6509 HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.
6513 The ETag entity-header field defines the entity tag for the
6514 associated entity. The headers used with entity tags are described in
6515 sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used
6516 for comparison with other entities from the same resource (see
6519 ETag = "ETag" ":" entity-tag
6529 The Expires entity-header field gives the date/time after which the
6530 response should be considered stale. A stale cache entry may not
6531 normally be returned by a cache (either a proxy cache or an user
6532 agent cache) unless it is first validated with the origin server (or
6533 with an intermediate cache that has a fresh copy of the entity). See
6534 section 13.2 for further discussion of the expiration model.
6536 The presence of an Expires field does not imply that the original
6537 resource will change or cease to exist at, before, or after that
6540 The format is an absolute date and time as defined by HTTP-date in
6541 section 3.3; it MUST be in RFC1123-date format:
6543 Expires = "Expires" ":" HTTP-date
6554 Fielding, et. al. Standards Track [Page 117]
6556 RFC 2068 HTTP/1.1 January 1997
6559 An example of its use is
6561 Expires: Thu, 01 Dec 1994 16:00:00 GMT
6563 Note: if a response includes a Cache-Control field with the max-age
6564 directive, that directive overrides the Expires field.
6566 HTTP/1.1 clients and caches MUST treat other invalid date formats,
6567 especially including the value "0", as in the past (i.e., "already
6570 To mark a response as "already expired," an origin server should use
6571 an Expires date that is equal to the Date header value. (See the
6572 rules for expiration calculations in section 13.2.4.)
6574 To mark a response as "never expires," an origin server should use an
6575 Expires date approximately one year from the time the response is
6576 sent. HTTP/1.1 servers should not send Expires dates more than one
6579 The presence of an Expires header field with a date value of some
6580 time in the future on an response that otherwise would by default be
6581 non-cacheable indicates that the response is cachable, unless
6582 indicated otherwise by a Cache-Control header field (section 14.9).
6586 The From request-header field, if given, SHOULD contain an Internet
6587 e-mail address for the human user who controls the requesting user
6588 agent. The address SHOULD be machine-usable, as defined by mailbox
6589 in RFC 822 (as updated by RFC 1123 ):
6591 From = "From" ":" mailbox
6595 From: webmaster@w3.org
6597 This header field MAY be used for logging purposes and as a means for
6598 identifying the source of invalid or unwanted requests. It SHOULD NOT
6599 be used as an insecure form of access protection. The interpretation
6600 of this field is that the request is being performed on behalf of the
6601 person given, who accepts responsibility for the method performed. In
6602 particular, robot agents SHOULD include this header so that the
6603 person responsible for running the robot can be contacted if problems
6604 occur on the receiving end.
6610 Fielding, et. al. Standards Track [Page 118]
6612 RFC 2068 HTTP/1.1 January 1997
6615 The Internet e-mail address in this field MAY be separate from the
6616 Internet host which issued the request. For example, when a request
6617 is passed through a proxy the original issuer's address SHOULD be
6620 Note: The client SHOULD not send the From header field without the
6621 user's approval, as it may conflict with the user's privacy
6622 interests or their site's security policy. It is strongly
6623 recommended that the user be able to disable, enable, and modify
6624 the value of this field at any time prior to a request.
6628 The Host request-header field specifies the Internet host and port
6629 number of the resource being requested, as obtained from the original
6630 URL given by the user or referring resource (generally an HTTP URL,
6631 as described in section 3.2.2). The Host field value MUST represent
6632 the network location of the origin server or gateway given by the
6633 original URL. This allows the origin server or gateway to
6634 differentiate between internally-ambiguous URLs, such as the root "/"
6635 URL of a server for multiple host names on a single IP address.
6637 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
6639 A "host" without any trailing port information implies the default
6640 port for the service requested (e.g., "80" for an HTTP URL). For
6641 example, a request on the origin server for
6642 <http://www.w3.org/pub/WWW/> MUST include:
6644 GET /pub/WWW/ HTTP/1.1
6647 A client MUST include a Host header field in all HTTP/1.1 request
6648 messages on the Internet (i.e., on any message corresponding to a
6649 request for a URL which includes an Internet host address for the
6650 service being requested). If the Host field is not already present,
6651 an HTTP/1.1 proxy MUST add a Host field to the request message prior
6652 to forwarding it on the Internet. All Internet-based HTTP/1.1 servers
6653 MUST respond with a 400 status code to any HTTP/1.1 request message
6654 which lacks a Host header field.
6656 See sections 5.2 and 19.5.1 for other requirements relating to Host.
6658 14.24 If-Modified-Since
6660 The If-Modified-Since request-header field is used with the GET
6661 method to make it conditional: if the requested variant has not been
6662 modified since the time specified in this field, an entity will not
6666 Fielding, et. al. Standards Track [Page 119]
6668 RFC 2068 HTTP/1.1 January 1997
6671 be returned from the server; instead, a 304 (not modified) response
6672 will be returned without any message-body.
6674 If-Modified-Since = "If-Modified-Since" ":" HTTP-date
6676 An example of the field is:
6678 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
6680 A GET method with an If-Modified-Since header and no Range header
6681 requests that the identified entity be transferred only if it has
6682 been modified since the date given by the If-Modified-Since header.
6683 The algorithm for determining this includes the following cases:
6685 a)If the request would normally result in anything other than a 200
6686 (OK) status, or if the passed If-Modified-Since date is invalid, the
6687 response is exactly the same as for a normal GET. A date which is
6688 later than the server's current time is invalid.
6690 b)If the variant has been modified since the If-Modified-Since date,
6691 the response is exactly the same as for a normal GET.
6693 c)If the variant has not been modified since a valid If-Modified-Since
6694 date, the server MUST return a 304 (Not Modified) response.
6696 The purpose of this feature is to allow efficient updates of cached
6697 information with a minimum amount of transaction overhead.
6699 Note that the Range request-header field modifies the meaning of
6700 If-Modified-Since; see section 14.36 for full details.
6702 Note that If-Modified-Since times are interpreted by the server,
6703 whose clock may not be synchronized with the client.
6705 Note that if a client uses an arbitrary date in the If-Modified-Since
6706 header instead of a date taken from the Last-Modified header for the
6707 same request, the client should be aware of the fact that this date
6708 is interpreted in the server's understanding of time. The client
6709 should consider unsynchronized clocks and rounding problems due to
6710 the different encodings of time between the client and server. This
6711 includes the possibility of race conditions if the document has
6712 changed between the time it was first requested and the If-Modified-
6713 Since date of a subsequent request, and the possibility of clock-
6714 skew-related problems if the If-Modified-Since date is derived from
6715 the client's clock without correction to the server's clock.
6716 Corrections for different time bases between client and server are at
6717 best approximate due to network latency.
6722 Fielding, et. al. Standards Track [Page 120]
6724 RFC 2068 HTTP/1.1 January 1997
6729 The If-Match request-header field is used with a method to make it
6730 conditional. A client that has one or more entities previously
6731 obtained from the resource can verify that one of those entities is
6732 current by including a list of their associated entity tags in the
6733 If-Match header field. The purpose of this feature is to allow
6734 efficient updates of cached information with a minimum amount of
6735 transaction overhead. It is also used, on updating requests, to
6736 prevent inadvertent modification of the wrong version of a resource.
6737 As a special case, the value "*" matches any current entity of the
6740 If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
6742 If any of the entity tags match the entity tag of the entity that
6743 would have been returned in the response to a similar GET request
6744 (without the If-Match header) on that resource, or if "*" is given
6745 and any current entity exists for that resource, then the server MAY
6746 perform the requested method as if the If-Match header field did not
6749 A server MUST use the strong comparison function (see section 3.11)
6750 to compare the entity tags in If-Match.
6752 If none of the entity tags match, or if "*" is given and no current
6753 entity exists, the server MUST NOT perform the requested method, and
6754 MUST return a 412 (Precondition Failed) response. This behavior is
6755 most useful when the client wants to prevent an updating method, such
6756 as PUT, from modifying a resource that has changed since the client
6759 If the request would, without the If-Match header field, result in
6760 anything other than a 2xx status, then the If-Match header MUST be
6763 The meaning of "If-Match: *" is that the method SHOULD be performed
6764 if the representation selected by the origin server (or by a cache,
6765 possibly using the Vary mechanism, see section 14.43) exists, and
6766 MUST NOT be performed if the representation does not exist.
6778 Fielding, et. al. Standards Track [Page 121]
6780 RFC 2068 HTTP/1.1 January 1997
6783 A request intended to update a resource (e.g., a PUT) MAY include an
6784 If-Match header field to signal that the request method MUST NOT be
6785 applied if the entity corresponding to the If-Match value (a single
6786 entity tag) is no longer a representation of that resource. This
6787 allows the user to indicate that they do not wish the request to be
6788 successful if the resource has been changed without their knowledge.
6792 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
6797 The If-None-Match request-header field is used with a method to make
6798 it conditional. A client that has one or more entities previously
6799 obtained from the resource can verify that none of those entities is
6800 current by including a list of their associated entity tags in the
6801 If-None-Match header field. The purpose of this feature is to allow
6802 efficient updates of cached information with a minimum amount of
6803 transaction overhead. It is also used, on updating requests, to
6804 prevent inadvertent modification of a resource which was not known to
6807 As a special case, the value "*" matches any current entity of the
6810 If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
6812 If any of the entity tags match the entity tag of the entity that
6813 would have been returned in the response to a similar GET request
6814 (without the If-None-Match header) on that resource, or if "*" is
6815 given and any current entity exists for that resource, then the
6816 server MUST NOT perform the requested method. Instead, if the request
6817 method was GET or HEAD, the server SHOULD respond with a 304 (Not
6818 Modified) response, including the cache-related entity-header fields
6819 (particularly ETag) of one of the entities that matched. For all
6820 other request methods, the server MUST respond with a status of 412
6821 (Precondition Failed).
6823 See section 13.3.3 for rules on how to determine if two entity tags
6824 match. The weak comparison function can only be used with GET or HEAD
6827 If none of the entity tags match, or if "*" is given and no current
6828 entity exists, then the server MAY perform the requested method as if
6829 the If-None-Match header field did not exist.
6834 Fielding, et. al. Standards Track [Page 122]
6836 RFC 2068 HTTP/1.1 January 1997
6839 If the request would, without the If-None-Match header field, result
6840 in anything other than a 2xx status, then the If-None-Match header
6843 The meaning of "If-None-Match: *" is that the method MUST NOT be
6844 performed if the representation selected by the origin server (or by
6845 a cache, possibly using the Vary mechanism, see section 14.43)
6846 exists, and SHOULD be performed if the representation does not exist.
6847 This feature may be useful in preventing races between PUT
6852 If-None-Match: "xyzzy"
6853 If-None-Match: W/"xyzzy"
6854 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
6855 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
6860 If a client has a partial copy of an entity in its cache, and wishes
6861 to have an up-to-date copy of the entire entity in its cache, it
6862 could use the Range request-header with a conditional GET (using
6863 either or both of If-Unmodified-Since and If-Match.) However, if the
6864 condition fails because the entity has been modified, the client
6865 would then have to make a second request to obtain the entire current
6868 The If-Range header allows a client to "short-circuit" the second
6869 request. Informally, its meaning is `if the entity is unchanged, send
6870 me the part(s) that I am missing; otherwise, send me the entire new
6873 If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
6875 If the client has no entity tag for an entity, but does have a Last-
6876 Modified date, it may use that date in a If-Range header. (The server
6877 can distinguish between a valid HTTP-date and any form of entity-tag
6878 by examining no more than two characters.) The If-Range header should
6879 only be used together with a Range header, and must be ignored if the
6880 request does not include a Range header, or if the server does not
6881 support the sub-range operation.
6890 Fielding, et. al. Standards Track [Page 123]
6892 RFC 2068 HTTP/1.1 January 1997
6895 If the entity tag given in the If-Range header matches the current
6896 entity tag for the entity, then the server should provide the
6897 specified sub-range of the entity using a 206 (Partial content)
6898 response. If the entity tag does not match, then the server should
6899 return the entire entity using a 200 (OK) response.
6901 14.28 If-Unmodified-Since
6903 The If-Unmodified-Since request-header field is used with a method to
6904 make it conditional. If the requested resource has not been modified
6905 since the time specified in this field, the server should perform the
6906 requested operation as if the If-Unmodified-Since header were not
6909 If the requested variant has been modified since the specified time,
6910 the server MUST NOT perform the requested operation, and MUST return
6911 a 412 (Precondition Failed).
6913 If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
6915 An example of the field is:
6917 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
6919 If the request normally (i.e., without the If-Unmodified-Since
6920 header) would result in anything other than a 2xx status, the If-
6921 Unmodified-Since header should be ignored.
6923 If the specified date is invalid, the header is ignored.
6927 The Last-Modified entity-header field indicates the date and time at
6928 which the origin server believes the variant was last modified.
6930 Last-Modified = "Last-Modified" ":" HTTP-date
6932 An example of its use is
6934 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
6936 The exact meaning of this header field depends on the implementation
6937 of the origin server and the nature of the original resource. For
6938 files, it may be just the file system last-modified time. For
6939 entities with dynamically included parts, it may be the most recent
6940 of the set of last-modify times for its component parts. For database
6941 gateways, it may be the last-update time stamp of the record. For
6942 virtual objects, it may be the last time the internal state changed.
6946 Fielding, et. al. Standards Track [Page 124]
6948 RFC 2068 HTTP/1.1 January 1997
6951 An origin server MUST NOT send a Last-Modified date which is later
6952 than the server's time of message origination. In such cases, where
6953 the resource's last modification would indicate some time in the
6954 future, the server MUST replace that date with the message
6957 An origin server should obtain the Last-Modified value of the entity
6958 as close as possible to the time that it generates the Date value of
6959 its response. This allows a recipient to make an accurate assessment
6960 of the entity's modification time, especially if the entity changes
6961 near the time that the response is generated.
6963 HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
6967 The Location response-header field is used to redirect the recipient
6968 to a location other than the Request-URI for completion of the
6969 request or identification of a new resource. For 201 (Created)
6970 responses, the Location is that of the new resource which was created
6971 by the request. For 3xx responses, the location SHOULD indicate the
6972 server's preferred URL for automatic redirection to the resource. The
6973 field value consists of a single absolute URL.
6975 Location = "Location" ":" absoluteURI
6979 Location: http://www.w3.org/pub/WWW/People.html
6981 Note: The Content-Location header field (section 14.15) differs
6982 from Location in that the Content-Location identifies the original
6983 location of the entity enclosed in the request. It is therefore
6984 possible for a response to contain header fields for both Location
6985 and Content-Location. Also see section 13.10 for cache requirements
6990 The Max-Forwards request-header field may be used with the TRACE
6991 method (section 14.31) to limit the number of proxies or gateways
6992 that can forward the request to the next inbound server. This can be
6993 useful when the client is attempting to trace a request chain which
6994 appears to be failing or looping in mid-chain.
6996 Max-Forwards = "Max-Forwards" ":" 1*DIGIT
7002 Fielding, et. al. Standards Track [Page 125]
7004 RFC 2068 HTTP/1.1 January 1997
7007 The Max-Forwards value is a decimal integer indicating the remaining
7008 number of times this request message may be forwarded.
7010 Each proxy or gateway recipient of a TRACE request containing a Max-
7011 Forwards header field SHOULD check and update its value prior to
7012 forwarding the request. If the received value is zero (0), the
7013 recipient SHOULD NOT forward the request; instead, it SHOULD respond
7014 as the final recipient with a 200 (OK) response containing the
7015 received request message as the response entity-body (as described in
7016 section 9.8). If the received Max-Forwards value is greater than
7017 zero, then the forwarded message SHOULD contain an updated Max-
7018 Forwards field with a value decremented by one (1).
7020 The Max-Forwards header field SHOULD be ignored for all other methods
7021 defined by this specification and for any extension methods for which
7022 it is not explicitly referred to as part of that method definition.
7026 The Pragma general-header field is used to include implementation-
7027 specific directives that may apply to any recipient along the
7028 request/response chain. All pragma directives specify optional
7029 behavior from the viewpoint of the protocol; however, some systems
7030 MAY require that behavior be consistent with the directives.
7032 Pragma = "Pragma" ":" 1#pragma-directive
7034 pragma-directive = "no-cache" | extension-pragma
7035 extension-pragma = token [ "=" ( token | quoted-string ) ]
7037 When the no-cache directive is present in a request message, an
7038 application SHOULD forward the request toward the origin server even
7039 if it has a cached copy of what is being requested. This pragma
7040 directive has the same semantics as the no-cache cache-directive (see
7041 section 14.9) and is defined here for backwards compatibility with
7042 HTTP/1.0. Clients SHOULD include both header fields when a no-cache
7043 request is sent to a server not known to be HTTP/1.1 compliant.
7045 Pragma directives MUST be passed through by a proxy or gateway
7046 application, regardless of their significance to that application,
7047 since the directives may be applicable to all recipients along the
7048 request/response chain. It is not possible to specify a pragma for a
7049 specific recipient; however, any pragma directive not relevant to a
7050 recipient SHOULD be ignored by that recipient.
7058 Fielding, et. al. Standards Track [Page 126]
7060 RFC 2068 HTTP/1.1 January 1997
7063 HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1
7064 caches SHOULD treat "Pragma: no-cache" as if the client had sent
7065 "Cache-Control: no-cache". No new Pragma directives will be defined
7068 14.33 Proxy-Authenticate
7070 The Proxy-Authenticate response-header field MUST be included as part
7071 of a 407 (Proxy Authentication Required) response. The field value
7072 consists of a challenge that indicates the authentication scheme and
7073 parameters applicable to the proxy for this Request-URI.
7075 Proxy-Authenticate = "Proxy-Authenticate" ":" challenge
7077 The HTTP access authentication process is described in section 11.
7078 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
7079 only to the current connection and SHOULD NOT be passed on to
7080 downstream clients. However, an intermediate proxy may need to obtain
7081 its own credentials by requesting them from the downstream client,
7082 which in some circumstances will appear as if the proxy is forwarding
7083 the Proxy-Authenticate header field.
7085 14.34 Proxy-Authorization
7087 The Proxy-Authorization request-header field allows the client to
7088 identify itself (or its user) to a proxy which requires
7089 authentication. The Proxy-Authorization field value consists of
7090 credentials containing the authentication information of the user
7091 agent for the proxy and/or realm of the resource being requested.
7093 Proxy-Authorization = "Proxy-Authorization" ":" credentials
7095 The HTTP access authentication process is described in section 11.
7096 Unlike Authorization, the Proxy-Authorization header field applies
7097 only to the next outbound proxy that demanded authentication using
7098 the Proxy-Authenticate field. When multiple proxies are used in a
7099 chain, the Proxy-Authorization header field is consumed by the first
7100 outbound proxy that was expecting to receive credentials. A proxy MAY
7101 relay the credentials from the client request to the next proxy if
7102 that is the mechanism by which the proxies cooperatively authenticate
7107 The Public response-header field lists the set of methods supported
7108 by the server. The purpose of this field is strictly to inform the
7109 recipient of the capabilities of the server regarding unusual
7110 methods. The methods listed may or may not be applicable to the
7114 Fielding, et. al. Standards Track [Page 127]
7116 RFC 2068 HTTP/1.1 January 1997
7119 Request-URI; the Allow header field (section 14.7) MAY be used to
7120 indicate methods allowed for a particular URI.
7122 Public = "Public" ":" 1#method
7126 Public: OPTIONS, MGET, MHEAD, GET, HEAD
7128 This header field applies only to the server directly connected to
7129 the client (i.e., the nearest neighbor in a chain of connections). If
7130 the response passes through a proxy, the proxy MUST either remove the
7131 Public header field or replace it with one applicable to its own
7138 Since all HTTP entities are represented in HTTP messages as sequences
7139 of bytes, the concept of a byte range is meaningful for any HTTP
7140 entity. (However, not all clients and servers need to support byte-
7143 Byte range specifications in HTTP apply to the sequence of bytes in
7144 the entity-body (not necessarily the same as the message-body).
7146 A byte range operation may specify a single range of bytes, or a set
7147 of ranges within a single entity.
7149 ranges-specifier = byte-ranges-specifier
7151 byte-ranges-specifier = bytes-unit "=" byte-range-set
7153 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
7155 byte-range-spec = first-byte-pos "-" [last-byte-pos]
7157 first-byte-pos = 1*DIGIT
7159 last-byte-pos = 1*DIGIT
7161 The first-byte-pos value in a byte-range-spec gives the byte-offset
7162 of the first byte in a range. The last-byte-pos value gives the
7163 byte-offset of the last byte in the range; that is, the byte
7164 positions specified are inclusive. Byte offsets start at zero.
7170 Fielding, et. al. Standards Track [Page 128]
7172 RFC 2068 HTTP/1.1 January 1997
7175 If the last-byte-pos value is present, it must be greater than or
7176 equal to the first-byte-pos in that byte-range-spec, or the byte-
7177 range-spec is invalid. The recipient of an invalid byte-range-spec
7180 If the last-byte-pos value is absent, or if the value is greater than
7181 or equal to the current length of the entity-body, last-byte-pos is
7182 taken to be equal to one less than the current length of the entity-
7185 By its choice of last-byte-pos, a client can limit the number of
7186 bytes retrieved without knowing the size of the entity.
7188 suffix-byte-range-spec = "-" suffix-length
7190 suffix-length = 1*DIGIT
7192 A suffix-byte-range-spec is used to specify the suffix of the
7193 entity-body, of a length given by the suffix-length value. (That is,
7194 this form specifies the last N bytes of an entity-body.) If the
7195 entity is shorter than the specified suffix-length, the entire
7196 entity-body is used.
7198 Examples of byte-ranges-specifier values (assuming an entity-body of
7201 o The first 500 bytes (byte offsets 0-499, inclusive):
7205 o The second 500 bytes (byte offsets 500-999, inclusive):
7209 o The final 500 bytes (byte offsets 9500-9999, inclusive):
7217 o The first and last bytes only (bytes 0 and 9999):
7226 Fielding, et. al. Standards Track [Page 129]
7228 RFC 2068 HTTP/1.1 January 1997
7231 o Several legal but not canonical specifications of the second
7232 500 bytes (byte offsets 500-999, inclusive):
7234 bytes=500-600,601-999
7236 bytes=500-700,601-999
7238 14.36.2 Range Retrieval Requests
7240 HTTP retrieval requests using conditional or unconditional GET
7241 methods may request one or more sub-ranges of the entity, instead of
7242 the entire entity, using the Range request header, which applies to
7243 the entity returned as the result of the request:
7245 Range = "Range" ":" ranges-specifier
7247 A server MAY ignore the Range header. However, HTTP/1.1 origin
7248 servers and intermediate caches SHOULD support byte ranges when
7249 possible, since Range supports efficient recovery from partially
7250 failed transfers, and supports efficient partial retrieval of large
7253 If the server supports the Range header and the specified range or
7254 ranges are appropriate for the entity:
7256 o The presence of a Range header in an unconditional GET modifies
7257 what is returned if the GET is otherwise successful. In other
7258 words, the response carries a status code of 206 (Partial
7259 Content) instead of 200 (OK).
7261 o The presence of a Range header in a conditional GET (a request
7262 using one or both of If-Modified-Since and If-None-Match, or
7263 one or both of If-Unmodified-Since and If-Match) modifies what
7264 is returned if the GET is otherwise successful and the condition
7265 is true. It does not affect the 304 (Not Modified) response
7266 returned if the conditional is false.
7268 In some cases, it may be more appropriate to use the If-Range header
7269 (see section 14.27) in addition to the Range header.
7271 If a proxy that supports ranges receives a Range request, forwards
7272 the request to an inbound server, and receives an entire entity in
7273 reply, it SHOULD only return the requested range to its client. It
7274 SHOULD store the entire received response in its cache, if that is
7275 consistent with its cache allocation policies.
7282 Fielding, et. al. Standards Track [Page 130]
7284 RFC 2068 HTTP/1.1 January 1997
7289 The Referer[sic] request-header field allows the client to specify,
7290 for the server's benefit, the address (URI) of the resource from
7291 which the Request-URI was obtained (the "referrer", although the
7292 header field is misspelled.) The Referer request-header allows a
7293 server to generate lists of back-links to resources for interest,
7294 logging, optimized caching, etc. It also allows obsolete or mistyped
7295 links to be traced for maintenance. The Referer field MUST NOT be
7296 sent if the Request-URI was obtained from a source that does not have
7297 its own URI, such as input from the user keyboard.
7299 Referer = "Referer" ":" ( absoluteURI | relativeURI )
7303 Referer: http://www.w3.org/hypertext/DataSources/Overview.html
7305 If the field value is a partial URI, it SHOULD be interpreted
7306 relative to the Request-URI. The URI MUST NOT include a fragment.
7308 Note: Because the source of a link may be private information or
7309 may reveal an otherwise private information source, it is strongly
7310 recommended that the user be able to select whether or not the
7311 Referer field is sent. For example, a browser client could have a
7312 toggle switch for browsing openly/anonymously, which would
7313 respectively enable/disable the sending of Referer and From
7318 The Retry-After response-header field can be used with a 503 (Service
7319 Unavailable) response to indicate how long the service is expected to
7320 be unavailable to the requesting client. The value of this field can
7321 be either an HTTP-date or an integer number of seconds (in decimal)
7322 after the time of the response.
7324 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
7326 Two examples of its use are
7328 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
7331 In the latter example, the delay is 2 minutes.
7338 Fielding, et. al. Standards Track [Page 131]
7340 RFC 2068 HTTP/1.1 January 1997
7345 The Server response-header field contains information about the
7346 software used by the origin server to handle the request. The field
7347 can contain multiple product tokens (section 3.8) and comments
7348 identifying the server and any significant subproducts. The product
7349 tokens are listed in order of their significance for identifying the
7352 Server = "Server" ":" 1*( product | comment )
7356 Server: CERN/3.0 libwww/2.17
7358 If the response is being forwarded through a proxy, the proxy
7359 application MUST NOT modify the Server response-header. Instead, it
7360 SHOULD include a Via field (as described in section 14.44).
7362 Note: Revealing the specific software version of the server may
7363 allow the server machine to become more vulnerable to attacks
7364 against software that is known to contain security holes. Server
7365 implementers are encouraged to make this field a configurable
7368 14.40 Transfer-Encoding
7370 The Transfer-Encoding general-header field indicates what (if any)
7371 type of transformation has been applied to the message body in order
7372 to safely transfer it between the sender and the recipient. This
7373 differs from the Content-Encoding in that the transfer coding is a
7374 property of the message, not of the entity.
7376 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-
7379 Transfer codings are defined in section 3.6. An example is:
7381 Transfer-Encoding: chunked
7383 Many older HTTP/1.0 applications do not understand the Transfer-
7388 The Upgrade general-header allows the client to specify what
7389 additional communication protocols it supports and would like to use
7390 if the server finds it appropriate to switch protocols. The server
7394 Fielding, et. al. Standards Track [Page 132]
7396 RFC 2068 HTTP/1.1 January 1997
7399 MUST use the Upgrade header field within a 101 (Switching Protocols)
7400 response to indicate which protocol(s) are being switched.
7402 Upgrade = "Upgrade" ":" 1#product
7406 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
7408 The Upgrade header field is intended to provide a simple mechanism
7409 for transition from HTTP/1.1 to some other, incompatible protocol. It
7410 does so by allowing the client to advertise its desire to use another
7411 protocol, such as a later version of HTTP with a higher major version
7412 number, even though the current request has been made using HTTP/1.1.
7413 This eases the difficult transition between incompatible protocols by
7414 allowing the client to initiate a request in the more commonly
7415 supported protocol while indicating to the server that it would like
7416 to use a "better" protocol if available (where "better" is determined
7417 by the server, possibly according to the nature of the method and/or
7418 resource being requested).
7420 The Upgrade header field only applies to switching application-layer
7421 protocols upon the existing transport-layer connection. Upgrade
7422 cannot be used to insist on a protocol change; its acceptance and use
7423 by the server is optional. The capabilities and nature of the
7424 application-layer communication after the protocol change is entirely
7425 dependent upon the new protocol chosen, although the first action
7426 after changing the protocol MUST be a response to the initial HTTP
7427 request containing the Upgrade header field.
7429 The Upgrade header field only applies to the immediate connection.
7430 Therefore, the upgrade keyword MUST be supplied within a Connection
7431 header field (section 14.10) whenever Upgrade is present in an
7434 The Upgrade header field cannot be used to indicate a switch to a
7435 protocol on a different connection. For that purpose, it is more
7436 appropriate to use a 301, 302, 303, or 305 redirection response.
7438 This specification only defines the protocol name "HTTP" for use by
7439 the family of Hypertext Transfer Protocols, as defined by the HTTP
7440 version rules of section 3.1 and future updates to this
7441 specification. Any token can be used as a protocol name; however, it
7442 will only be useful if both the client and server associate the name
7443 with the same protocol.
7450 Fielding, et. al. Standards Track [Page 133]
7452 RFC 2068 HTTP/1.1 January 1997
7457 The User-Agent request-header field contains information about the
7458 user agent originating the request. This is for statistical purposes,
7459 the tracing of protocol violations, and automated recognition of user
7460 agents for the sake of tailoring responses to avoid particular user
7461 agent limitations. User agents SHOULD include this field with
7462 requests. The field can contain multiple product tokens (section 3.8)
7463 and comments identifying the agent and any subproducts which form a
7464 significant part of the user agent. By convention, the product tokens
7465 are listed in order of their significance for identifying the
7468 User-Agent = "User-Agent" ":" 1*( product | comment )
7472 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
7476 The Vary response-header field is used by a server to signal that the
7477 response entity was selected from the available representations of
7478 the response using server-driven negotiation (section 12). Field-
7479 names listed in Vary headers are those of request-headers. The Vary
7480 field value indicates either that the given set of header fields
7481 encompass the dimensions over which the representation might vary, or
7482 that the dimensions of variance are unspecified ("*") and thus may
7483 vary over any aspect of future requests.
7485 Vary = "Vary" ":" ( "*" | 1#field-name )
7487 An HTTP/1.1 server MUST include an appropriate Vary header field with
7488 any cachable response that is subject to server-driven negotiation.
7489 Doing so allows a cache to properly interpret future requests on that
7490 resource and informs the user agent about the presence of negotiation
7491 on that resource. A server SHOULD include an appropriate Vary header
7492 field with a non-cachable response that is subject to server-driven
7493 negotiation, since this might provide the user agent with useful
7494 information about the dimensions over which the response might vary.
7496 The set of header fields named by the Vary field value is known as
7497 the "selecting" request-headers.
7499 When the cache receives a subsequent request whose Request-URI
7500 specifies one or more cache entries including a Vary header, the
7501 cache MUST NOT use such a cache entry to construct a response to the
7502 new request unless all of the headers named in the cached Vary header
7506 Fielding, et. al. Standards Track [Page 134]
7508 RFC 2068 HTTP/1.1 January 1997
7511 are present in the new request, and all of the stored selecting
7512 request-headers from the previous request match the corresponding
7513 headers in the new request.
7515 The selecting request-headers from two requests are defined to match
7516 if and only if the selecting request-headers in the first request can
7517 be transformed to the selecting request-headers in the second request
7518 by adding or removing linear whitespace (LWS) at places where this is
7519 allowed by the corresponding BNF, and/or combining multiple message-
7520 header fields with the same field name following the rules about
7521 message headers in section 4.2.
7523 A Vary field value of "*" signals that unspecified parameters,
7524 possibly other than the contents of request-header fields (e.g., the
7525 network address of the client), play a role in the selection of the
7526 response representation. Subsequent requests on that resource can
7527 only be properly interpreted by the origin server, and thus a cache
7528 MUST forward a (possibly conditional) request even when it has a
7529 fresh response cached for the resource. See section 13.6 for use of
7530 the Vary header by caches.
7532 A Vary field value consisting of a list of field-names signals that
7533 the representation selected for the response is based on a selection
7534 algorithm which considers ONLY the listed request-header field values
7535 in selecting the most appropriate representation. A cache MAY assume
7536 that the same selection will be made for future requests with the
7537 same values for the listed field names, for the duration of time in
7538 which the response is fresh.
7540 The field-names given are not limited to the set of standard
7541 request-header fields defined by this specification. Field names are
7546 The Via general-header field MUST be used by gateways and proxies to
7547 indicate the intermediate protocols and recipients between the user
7548 agent and the server on requests, and between the origin server and
7549 the client on responses. It is analogous to the "Received" field of
7550 RFC 822 and is intended to be used for tracking message forwards,
7551 avoiding request loops, and identifying the protocol capabilities of
7552 all senders along the request/response chain.
7562 Fielding, et. al. Standards Track [Page 135]
7564 RFC 2068 HTTP/1.1 January 1997
7567 Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
7569 received-protocol = [ protocol-name "/" ] protocol-version
7570 protocol-name = token
7571 protocol-version = token
7572 received-by = ( host [ ":" port ] ) | pseudonym
7575 The received-protocol indicates the protocol version of the message
7576 received by the server or client along each segment of the
7577 request/response chain. The received-protocol version is appended to
7578 the Via field value when the message is forwarded so that information
7579 about the protocol capabilities of upstream applications remains
7580 visible to all recipients.
7582 The protocol-name is optional if and only if it would be "HTTP". The
7583 received-by field is normally the host and optional port number of a
7584 recipient server or client that subsequently forwarded the message.
7585 However, if the real host is considered to be sensitive information,
7586 it MAY be replaced by a pseudonym. If the port is not given, it MAY
7587 be assumed to be the default port of the received-protocol.
7589 Multiple Via field values represent each proxy or gateway that has
7590 forwarded the message. Each recipient MUST append its information
7591 such that the end result is ordered according to the sequence of
7592 forwarding applications.
7594 Comments MAY be used in the Via header field to identify the software
7595 of the recipient proxy or gateway, analogous to the User-Agent and
7596 Server header fields. However, all comments in the Via field are
7597 optional and MAY be removed by any recipient prior to forwarding the
7600 For example, a request message could be sent from an HTTP/1.0 user
7601 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
7602 forward the request to a public proxy at nowhere.com, which completes
7603 the request by forwarding it to the origin server at www.ics.uci.edu.
7604 The request received by www.ics.uci.edu would then have the following
7607 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
7609 Proxies and gateways used as a portal through a network firewall
7610 SHOULD NOT, by default, forward the names and ports of hosts within
7611 the firewall region. This information SHOULD only be propagated if
7612 explicitly enabled. If not enabled, the received-by host of any host
7613 behind the firewall SHOULD be replaced by an appropriate pseudonym
7618 Fielding, et. al. Standards Track [Page 136]
7620 RFC 2068 HTTP/1.1 January 1997
7623 For organizations that have strong privacy requirements for hiding
7624 internal structures, a proxy MAY combine an ordered subsequence of
7625 Via header field entries with identical received-protocol values into
7626 a single such entry. For example,
7628 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
7630 could be collapsed to
7632 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
7634 Applications SHOULD NOT combine multiple entries unless they are all
7635 under the same organizational control and the hosts have already been
7636 replaced by pseudonyms. Applications MUST NOT combine entries which
7637 have different received-protocol values.
7641 The Warning response-header field is used to carry additional
7642 information about the status of a response which may not be reflected
7643 by the response status code. This information is typically, though
7644 not exclusively, used to warn about a possible lack of semantic
7645 transparency from caching operations.
7647 Warning headers are sent with responses using:
7649 Warning = "Warning" ":" 1#warning-value
7651 warning-value = warn-code SP warn-agent SP warn-text
7653 warn-agent = ( host [ ":" port ] ) | pseudonym
7654 ; the name or pseudonym of the server adding
7655 ; the Warning header, for use in debugging
7656 warn-text = quoted-string
7658 A response may carry more than one Warning header.
7660 The warn-text should be in a natural language and character set that
7661 is most likely to be intelligible to the human user receiving the
7662 response. This decision may be based on any available knowledge,
7663 such as the location of the cache or user, the Accept-Language field
7664 in a request, the Content-Language field in a response, etc. The
7665 default language is English and the default character set is ISO-
7668 If a character set other than ISO-8859-1 is used, it MUST be encoded
7669 in the warn-text using the method described in RFC 1522 [14].
7674 Fielding, et. al. Standards Track [Page 137]
7676 RFC 2068 HTTP/1.1 January 1997
7679 Any server or cache may add Warning headers to a response. New
7680 Warning headers should be added after any existing Warning headers. A
7681 cache MUST NOT delete any Warning header that it received with a
7682 response. However, if a cache successfully validates a cache entry,
7683 it SHOULD remove any Warning headers previously attached to that
7684 entry except as specified for specific Warning codes. It MUST then
7685 add any Warning headers received in the validating response. In other
7686 words, Warning headers are those that would be attached to the most
7687 recent relevant response.
7689 When multiple Warning headers are attached to a response, the user
7690 agent SHOULD display as many of them as possible, in the order that
7691 they appear in the response. If it is not possible to display all of
7692 the warnings, the user agent should follow these heuristics:
7694 o Warnings that appear early in the response take priority over those
7695 appearing later in the response.
7696 o Warnings in the user's preferred character set take priority over
7697 warnings in other character sets but with identical warn-codes and
7700 Systems that generate multiple Warning headers should order them with
7701 this user agent behavior in mind.
7703 This is a list of the currently-defined warn-codes, each with a
7704 recommended warn-text in English, and a description of its meaning.
7706 10 Response is stale
7707 MUST be included whenever the returned response is stale. A cache may
7708 add this warning to any response, but may never remove it until the
7709 response is known to be fresh.
7711 11 Revalidation failed
7712 MUST be included if a cache returns a stale response because an
7713 attempt to revalidate the response failed, due to an inability to
7714 reach the server. A cache may add this warning to any response, but
7715 may never remove it until the response is successfully revalidated.
7717 12 Disconnected operation
7718 SHOULD be included if the cache is intentionally disconnected from
7719 the rest of the network for a period of time.
7721 13 Heuristic expiration
7722 MUST be included if the cache heuristically chose a freshness
7723 lifetime greater than 24 hours and the response's age is greater than
7730 Fielding, et. al. Standards Track [Page 138]
7732 RFC 2068 HTTP/1.1 January 1997
7735 14 Transformation applied
7736 MUST be added by an intermediate cache or proxy if it applies any
7737 transformation changing the content-coding (as specified in the
7738 Content-Encoding header) or media-type (as specified in the
7739 Content-Type header) of the response, unless this Warning code
7740 already appears in the response. MUST NOT be deleted from a response
7741 even after revalidation.
7743 99 Miscellaneous warning
7744 The warning text may include arbitrary information to be presented to
7745 a human user, or logged. A system receiving this warning MUST NOT
7746 take any automated action.
7748 14.46 WWW-Authenticate
7750 The WWW-Authenticate response-header field MUST be included in 401
7751 (Unauthorized) response messages. The field value consists of at
7752 least one challenge that indicates the authentication scheme(s) and
7753 parameters applicable to the Request-URI.
7755 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
7757 The HTTP access authentication process is described in section 11.
7758 User agents MUST take special care in parsing the WWW-Authenticate
7759 field value if it contains more than one challenge, or if more than
7760 one WWW-Authenticate header field is provided, since the contents of
7761 a challenge may itself contain a comma-separated list of
7762 authentication parameters.
7764 15 Security Considerations
7766 This section is meant to inform application developers, information
7767 providers, and users of the security limitations in HTTP/1.1 as
7768 described by this document. The discussion does not include
7769 definitive solutions to the problems revealed, though it does make
7770 some suggestions for reducing security risks.
7772 15.1 Authentication of Clients
7774 The Basic authentication scheme is not a secure method of user
7775 authentication, nor does it in any way protect the entity, which is
7776 transmitted in clear text across the physical network used as the
7777 carrier. HTTP does not prevent additional authentication schemes and
7778 encryption mechanisms from being employed to increase security or the
7779 addition of enhancements (such as schemes to use one-time passwords)
7780 to Basic authentication.
7786 Fielding, et. al. Standards Track [Page 139]
7788 RFC 2068 HTTP/1.1 January 1997
7791 The most serious flaw in Basic authentication is that it results in
7792 the essentially clear text transmission of the user's password over
7793 the physical network. It is this problem which Digest Authentication
7794 attempts to address.
7796 Because Basic authentication involves the clear text transmission of
7797 passwords it SHOULD never be used (without enhancements) to protect
7798 sensitive or valuable information.
7800 A common use of Basic authentication is for identification purposes
7801 -- requiring the user to provide a user name and password as a means
7802 of identification, for example, for purposes of gathering accurate
7803 usage statistics on a server. When used in this way it is tempting to
7804 think that there is no danger in its use if illicit access to the
7805 protected documents is not a major concern. This is only correct if
7806 the server issues both user name and password to the users and in
7807 particular does not allow the user to choose his or her own password.
7808 The danger arises because naive users frequently reuse a single
7809 password to avoid the task of maintaining multiple passwords.
7811 If a server permits users to select their own passwords, then the
7812 threat is not only illicit access to documents on the server but also
7813 illicit access to the accounts of all users who have chosen to use
7814 their account password. If users are allowed to choose their own
7815 password that also means the server must maintain files containing
7816 the (presumably encrypted) passwords. Many of these may be the
7817 account passwords of users perhaps at distant sites. The owner or
7818 administrator of such a system could conceivably incur liability if
7819 this information is not maintained in a secure fashion.
7821 Basic Authentication is also vulnerable to spoofing by counterfeit
7822 servers. If a user can be led to believe that he is connecting to a
7823 host containing information protected by basic authentication when in
7824 fact he is connecting to a hostile server or gateway then the
7825 attacker can request a password, store it for later use, and feign an
7826 error. This type of attack is not possible with Digest Authentication
7827 [32]. Server implementers SHOULD guard against the possibility of
7828 this sort of counterfeiting by gateways or CGI scripts. In particular
7829 it is very dangerous for a server to simply turn over a connection to
7830 a gateway since that gateway can then use the persistent connection
7831 mechanism to engage in multiple transactions with the client while
7832 impersonating the original server in a way that is not detectable by
7835 15.2 Offering a Choice of Authentication Schemes
7837 An HTTP/1.1 server may return multiple challenges with a 401
7838 (Authenticate) response, and each challenge may use a different
7842 Fielding, et. al. Standards Track [Page 140]
7844 RFC 2068 HTTP/1.1 January 1997
7847 scheme. The order of the challenges returned to the user agent is in
7848 the order that the server would prefer they be chosen. The server
7849 should order its challenges with the "most secure" authentication
7850 scheme first. A user agent should choose as the challenge to be made
7851 to the user the first one that the user agent understands.
7853 When the server offers choices of authentication schemes using the
7854 WWW-Authenticate header, the "security" of the authentication is only
7855 as malicious user could capture the set of challenges and try to
7856 authenticate him/herself using the weakest of the authentication
7857 schemes. Thus, the ordering serves more to protect the user's
7858 credentials than the server's information.
7860 A possible man-in-the-middle (MITM) attack would be to add a weak
7861 authentication scheme to the set of choices, hoping that the client
7862 will use one that exposes the user's credentials (e.g. password). For
7863 this reason, the client should always use the strongest scheme that
7864 it understands from the choices accepted.
7866 An even better MITM attack would be to remove all offered choices,
7867 and to insert a challenge that requests Basic authentication. For
7868 this reason, user agents that are concerned about this kind of attack
7869 could remember the strongest authentication scheme ever requested by
7870 a server and produce a warning message that requires user
7871 confirmation before using a weaker one. A particularly insidious way
7872 to mount such a MITM attack would be to offer a "free" proxy caching
7873 service to gullible users.
7875 15.3 Abuse of Server Log Information
7877 A server is in the position to save personal data about a user's
7878 requests which may identify their reading patterns or subjects of
7879 interest. This information is clearly confidential in nature and its
7880 handling may be constrained by law in certain countries. People using
7881 the HTTP protocol to provide data are responsible for ensuring that
7882 such material is not distributed without the permission of any
7883 individuals that are identifiable by the published results.
7885 15.4 Transfer of Sensitive Information
7887 Like any generic data transfer protocol, HTTP cannot regulate the
7888 content of the data that is transferred, nor is there any a priori
7889 method of determining the sensitivity of any particular piece of
7890 information within the context of any given request. Therefore,
7891 applications SHOULD supply as much control over this information as
7892 possible to the provider of that information. Four header fields are
7893 worth special mention in this context: Server, Via, Referer and From.
7898 Fielding, et. al. Standards Track [Page 141]
7900 RFC 2068 HTTP/1.1 January 1997
7903 Revealing the specific software version of the server may allow the
7904 server machine to become more vulnerable to attacks against software
7905 that is known to contain security holes. Implementers SHOULD make the
7906 Server header field a configurable option.
7908 Proxies which serve as a portal through a network firewall SHOULD
7909 take special precautions regarding the transfer of header information
7910 that identifies the hosts behind the firewall. In particular, they
7911 SHOULD remove, or replace with sanitized versions, any Via fields
7912 generated behind the firewall.
7914 The Referer field allows reading patterns to be studied and reverse
7915 links drawn. Although it can be very useful, its power can be abused
7916 if user details are not separated from the information contained in
7917 the Referer. Even when the personal information has been removed, the
7918 Referer field may indicate a private document's URI whose publication
7919 would be inappropriate.
7921 The information sent in the From field might conflict with the user's
7922 privacy interests or their site's security policy, and hence it
7923 SHOULD NOT be transmitted without the user being able to disable,
7924 enable, and modify the contents of the field. The user MUST be able
7925 to set the contents of this field within a user preference or
7926 application defaults configuration.
7928 We suggest, though do not require, that a convenient toggle interface
7929 be provided for the user to enable or disable the sending of From and
7930 Referer information.
7932 15.5 Attacks Based On File and Path Names
7934 Implementations of HTTP origin servers SHOULD be careful to restrict
7935 the documents returned by HTTP requests to be only those that were
7936 intended by the server administrators. If an HTTP server translates
7937 HTTP URIs directly into file system calls, the server MUST take
7938 special care not to serve files that were not intended to be
7939 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
7940 other operating systems use ".." as a path component to indicate a
7941 directory level above the current one. On such a system, an HTTP
7942 server MUST disallow any such construct in the Request-URI if it
7943 would otherwise allow access to a resource outside those intended to
7944 be accessible via the HTTP server. Similarly, files intended for
7945 reference only internally to the server (such as access control
7946 files, configuration files, and script code) MUST be protected from
7947 inappropriate retrieval, since they might contain sensitive
7948 information. Experience has shown that minor bugs in such HTTP server
7949 implementations have turned into security risks.
7954 Fielding, et. al. Standards Track [Page 142]
7956 RFC 2068 HTTP/1.1 January 1997
7959 15.6 Personal Information
7961 HTTP clients are often privy to large amounts of personal information
7962 (e.g. the user's name, location, mail address, passwords, encryption
7963 keys, etc.), and SHOULD be very careful to prevent unintentional
7964 leakage of this information via the HTTP protocol to other sources.
7965 We very strongly recommend that a convenient interface be provided
7966 for the user to control dissemination of such information, and that
7967 designers and implementers be particularly careful in this area.
7968 History shows that errors in this area are often both serious
7969 security and/or privacy problems, and often generate highly adverse
7970 publicity for the implementer's company.
7972 15.7 Privacy Issues Connected to Accept Headers
7974 Accept request-headers can reveal information about the user to all
7975 servers which are accessed. The Accept-Language header in particular
7976 can reveal information the user would consider to be of a private
7977 nature, because the understanding of particular languages is often
7978 strongly correlated to the membership of a particular ethnic group.
7979 User agents which offer the option to configure the contents of an
7980 Accept-Language header to be sent in every request are strongly
7981 encouraged to let the configuration process include a message which
7982 makes the user aware of the loss of privacy involved.
7984 An approach that limits the loss of privacy would be for a user agent
7985 to omit the sending of Accept-Language headers by default, and to ask
7986 the user whether it should start sending Accept-Language headers to a
7987 server if it detects, by looking for any Vary response-header fields
7988 generated by the server, that such sending could improve the quality
7991 Elaborate user-customized accept header fields sent in every request,
7992 in particular if these include quality values, can be used by servers
7993 as relatively reliable and long-lived user identifiers. Such user
7994 identifiers would allow content providers to do click-trail tracking,
7995 and would allow collaborating content providers to match cross-server
7996 click-trails or form submissions of individual users. Note that for
7997 many users not behind a proxy, the network address of the host
7998 running the user agent will also serve as a long-lived user
7999 identifier. In environments where proxies are used to enhance
8000 privacy, user agents should be conservative in offering accept header
8001 configuration options to end users. As an extreme privacy measure,
8002 proxies could filter the accept headers in relayed requests. General
8003 purpose user agents which provide a high degree of header
8004 configurability should warn users about the loss of privacy which can
8010 Fielding, et. al. Standards Track [Page 143]
8012 RFC 2068 HTTP/1.1 January 1997
8017 Clients using HTTP rely heavily on the Domain Name Service, and are
8018 thus generally prone to security attacks based on the deliberate
8019 mis-association of IP addresses and DNS names. Clients need to be
8020 cautious in assuming the continuing validity of an IP number/DNS name
8023 In particular, HTTP clients SHOULD rely on their name resolver for
8024 confirmation of an IP number/DNS name association, rather than
8025 caching the result of previous host name lookups. Many platforms
8026 already can cache host name lookups locally when appropriate, and
8027 they SHOULD be configured to do so. These lookups should be cached,
8028 however, only when the TTL (Time To Live) information reported by the
8029 name server makes it likely that the cached information will remain
8032 If HTTP clients cache the results of host name lookups in order to
8033 achieve a performance improvement, they MUST observe the TTL
8034 information reported by DNS.
8036 If HTTP clients do not observe this rule, they could be spoofed when
8037 a previously-accessed server's IP address changes. As network
8038 renumbering is expected to become increasingly common, the
8039 possibility of this form of attack will grow. Observing this
8040 requirement thus reduces this potential security vulnerability.
8042 This requirement also improves the load-balancing behavior of clients
8043 for replicated servers using the same DNS name and reduces the
8044 likelihood of a user's experiencing failure in accessing sites which
8047 15.9 Location Headers and Spoofing
8049 If a single server supports multiple organizations that do not trust
8050 one another, then it must check the values of Location and Content-
8051 Location headers in responses that are generated under control of
8052 said organizations to make sure that they do not attempt to
8053 invalidate resources over which they have no authority.
8057 This specification makes heavy use of the augmented BNF and generic
8058 constructs defined by David H. Crocker for RFC 822. Similarly, it
8059 reuses many of the definitions provided by Nathaniel Borenstein and
8060 Ned Freed for MIME. We hope that their inclusion in this
8061 specification will help reduce past confusion over the relationship
8062 between HTTP and Internet mail message formats.
8066 Fielding, et. al. Standards Track [Page 144]
8068 RFC 2068 HTTP/1.1 January 1997
8071 The HTTP protocol has evolved considerably over the past four years.
8072 It has benefited from a large and active developer community--the
8073 many people who have participated on the www-talk mailing list--and
8074 it is that community which has been most responsible for the success
8075 of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
8076 Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
8077 Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
8078 McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
8079 VanHeyningen deserve special recognition for their efforts in
8080 defining early aspects of the protocol.
8082 This document has benefited greatly from the comments of all those
8083 participating in the HTTP-WG. In addition to those already mentioned,
8084 the following individuals have contributed to this specification:
8086 Gary Adams Albert Lunde
8087 Harald Tveit Alvestrand John C. Mallery
8088 Keith Ball Jean-Philippe Martin-Flatin
8089 Brian Behlendorf Larry Masinter
8091 Maurizio Codogno David Morris
8092 Mike Cowlishaw Gavin Nicol
8093 Roman Czyborra Bill Perry
8094 Michael A. Dolan Jeffrey Perry
8095 David J. Fiander Scott Powers
8096 Alan Freier Owen Rees
8097 Marc Hedlund Luigi Rizzo
8098 Greg Herlihy David Robinson
8099 Koen Holtman Marc Salomon
8100 Alex Hopmann Rich Salz
8101 Bob Jernigan Allan M. Schiffman
8102 Shel Kaphan Jim Seidman
8103 Rohit Khare Chuck Shotton
8104 John Klensin Eric W. Sink
8105 Martijn Koster Simon E. Spero
8106 Alexei Kosut Richard N. Taylor
8107 David M. Kristol Robert S. Thau
8108 Daniel LaLiberte Bill (BearHeart) Weinman
8109 Ben Laurie Francois Yergeau
8110 Paul J. Leach Mary Ellen Zurko
8113 Much of the content and presentation of the caching design is due to
8114 suggestions and comments from individuals including: Shel Kaphan,
8115 Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
8122 Fielding, et. al. Standards Track [Page 145]
8124 RFC 2068 HTTP/1.1 January 1997
8127 Most of the specification of ranges is based on work originally done
8128 by Ari Luotonen and John Franks, with additional input from Steve
8131 Thanks to the "cave men" of Palo Alto. You know who you are.
8133 Jim Gettys (the current editor of this document) wishes particularly
8134 to thank Roy Fielding, the previous editor of this document, along
8135 with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
8136 Holtman, John Franks, Alex Hopmann, and Larry Masinter for their
8141 [1] Alvestrand, H., "Tags for the identification of languages", RFC
8142 1766, UNINETT, March 1995.
8144 [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
8145 D., and B. Alberti. "The Internet Gopher Protocol: (a distributed
8146 document search and retrieval protocol)", RFC 1436, University of
8147 Minnesota, March 1993.
8149 [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", A
8150 Unifying Syntax for the Expression of Names and Addresses of Objects
8151 on the Network as used in the World-Wide Web", RFC 1630, CERN, June
8154 [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
8155 Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
8158 [5] Berners-Lee, T., and D. Connolly, "HyperText Markup Language
8159 Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
8161 [6] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
8162 Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May
8165 [7] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
8166 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
8167 2045, Innosoft, First Virtual, November 1996.
8169 [8] Braden, R., "Requirements for Internet hosts - application and
8170 support", STD 3, RFC 1123, IETF, October 1989.
8172 [9] Crocker, D., "Standard for the Format of ARPA Internet Text
8173 Messages", STD 11, RFC 822, UDEL, August 1982.
8178 Fielding, et. al. Standards Track [Page 146]
8180 RFC 2068 HTTP/1.1 January 1997
8183 [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
8184 Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype
8185 Functional Specification", (v1.5), Thinking Machines Corporation,
8188 [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC
8191 [12] Horton, M., and R. Adams. "Standard for interchange of USENET
8192 messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
8193 Studies, December 1987.
8195 [13] Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A
8196 Proposed Standard for the Stream-Based Transmission of News", RFC
8197 977, UC San Diego, UC Berkeley, February 1986.
8199 [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
8200 Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
8201 University of Tennessee, November 1996.
8203 [15] Nebel, E., and L. Masinter. "Form-based File Upload in HTML",
8204 RFC 1867, Xerox Corporation, November 1995.
8206 [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
8207 USC/ISI, August 1982.
8209 [17] Postel, J., "Media Type Registration Procedure", RFC 2048,
8210 USC/ISI, November 1996.
8212 [18] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD
8213 9, RFC 959, USC/ISI, October 1985.
8215 [19] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
8216 1700, USC/ISI, October 1994.
8218 [20] Sollins, K., and L. Masinter, "Functional Requirements for
8219 Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
8222 [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
8223 Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
8225 [22] ISO-8859. International Standard -- Information Processing --
8226 8-bit Single-Byte Coded Graphic Character Sets --
8227 Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
8228 Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
8229 Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
8230 Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
8234 Fielding, et. al. Standards Track [Page 147]
8236 RFC 2068 HTTP/1.1 January 1997
8239 Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
8240 Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
8241 Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
8242 Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
8243 Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
8245 [23] Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC
8246 1864, Carnegie Mellon, Dover Beach Consulting, October, 1995.
8248 [24] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC
8249 1900, IAB, February 1996.
8251 [25] Deutsch, P., "GZIP file format specification version 4.3." RFC
8252 1952, Aladdin Enterprises, May 1996.
8254 [26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP
8255 Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec.
8256 1995. Slightly revised version of paper in Proc. 2nd International
8257 WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at
8258 http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/
8261 [27] Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP
8262 Performance", <URL: http://www.isi.edu/lsam/ib/http-perf/>,
8263 USC/Information Sciences Institute, June 1996
8265 [28] Mills, D., "Network Time Protocol, Version 3, Specification,
8266 Implementation and Analysis", RFC 1305, University of Delaware, March
8269 [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
8270 version 1.3." RFC 1951, Aladdin Enterprises, May 1996.
8272 [30] Spero, S., "Analysis of HTTP Performance Problems"
8273 <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>.
8275 [31] Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format
8276 Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP,
8279 [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
8280 Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP :
8281 Digest Access Authentication", RFC 2069, January 1997.
8290 Fielding, et. al. Standards Track [Page 148]
8292 RFC 2068 HTTP/1.1 January 1997
8295 18 Authors' Addresses
8298 Department of Information and Computer Science
8299 University of California
8300 Irvine, CA 92717-3425, USA
8302 Fax: +1 (714) 824-4056
8303 EMail: fielding@ics.uci.edu
8307 MIT Laboratory for Computer Science
8308 545 Technology Square
8309 Cambridge, MA 02139, USA
8311 Fax: +1 (617) 258 8682
8316 Western Research Laboratory
8317 Digital Equipment Corporation
8318 250 University Avenue
8319 Palo Alto, California, 94305, USA
8321 EMail: mogul@wrl.dec.com
8324 Henrik Frystyk Nielsen
8326 MIT Laboratory for Computer Science
8327 545 Technology Square
8328 Cambridge, MA 02139, USA
8330 Fax: +1 (617) 258 8682
8331 EMail: frystyk@w3.org
8335 Director, W3 Consortium
8336 MIT Laboratory for Computer Science
8337 545 Technology Square
8338 Cambridge, MA 02139, USA
8340 Fax: +1 (617) 258 8682
8346 Fielding, et. al. Standards Track [Page 149]
8348 RFC 2068 HTTP/1.1 January 1997
8353 19.1 Internet Media Type message/http
8355 In addition to defining the HTTP/1.1 protocol, this document serves
8356 as the specification for the Internet media type "message/http". The
8357 following is to be registered with IANA.
8359 Media Type name: message
8360 Media subtype name: http
8361 Required parameters: none
8362 Optional parameters: version, msgtype
8364 version: The HTTP-Version number of the enclosed message
8365 (e.g., "1.1"). If not present, the version can be
8366 determined from the first line of the body.
8368 msgtype: The message type -- "request" or "response". If not
8369 present, the type can be determined from the first
8372 Encoding considerations: only "7bit", "8bit", or "binary" are
8375 Security considerations: none
8377 19.2 Internet Media Type multipart/byteranges
8379 When an HTTP message includes the content of multiple ranges (for
8380 example, a response to a request for multiple non-overlapping
8381 ranges), these are transmitted as a multipart MIME message. The
8382 multipart media type for this purpose is called
8383 "multipart/byteranges".
8385 The multipart/byteranges media type includes two or more parts, each
8386 with its own Content-Type and Content-Range fields. The parts are
8387 separated using a MIME boundary parameter.
8389 Media Type name: multipart
8390 Media subtype name: byteranges
8391 Required parameters: boundary
8392 Optional parameters: none
8394 Encoding considerations: only "7bit", "8bit", or "binary" are
8397 Security considerations: none
8402 Fielding, et. al. Standards Track [Page 150]
8404 RFC 2068 HTTP/1.1 January 1997
8409 HTTP/1.1 206 Partial content
8410 Date: Wed, 15 Nov 1995 06:25:24 GMT
8411 Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
8412 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
8414 --THIS_STRING_SEPARATES
8415 Content-type: application/pdf
8416 Content-range: bytes 500-999/8000
8418 ...the first range...
8419 --THIS_STRING_SEPARATES
8420 Content-type: application/pdf
8421 Content-range: bytes 7000-7999/8000
8424 --THIS_STRING_SEPARATES--
8426 19.3 Tolerant Applications
8428 Although this document specifies the requirements for the generation
8429 of HTTP/1.1 messages, not all applications will be correct in their
8430 implementation. We therefore recommend that operational applications
8431 be tolerant of deviations whenever those deviations can be
8432 interpreted unambiguously.
8434 Clients SHOULD be tolerant in parsing the Status-Line and servers
8435 tolerant when parsing the Request-Line. In particular, they SHOULD
8436 accept any amount of SP or HT characters between fields, even though
8437 only a single SP is required.
8439 The line terminator for message-header fields is the sequence CRLF.
8440 However, we recommend that applications, when parsing such headers,
8441 recognize a single LF as a line terminator and ignore the leading CR.
8443 The character set of an entity-body should be labeled as the lowest
8444 common denominator of the character codes used within that body, with
8445 the exception that no label is preferred over the labels US-ASCII or
8448 Additional rules for requirements on parsing and encoding of dates
8449 and other potential problems with date encodings include:
8451 o HTTP/1.1 clients and caches should assume that an RFC-850 date
8452 which appears to be more than 50 years in the future is in fact
8453 in the past (this helps solve the "year 2000" problem).
8458 Fielding, et. al. Standards Track [Page 151]
8460 RFC 2068 HTTP/1.1 January 1997
8463 o An HTTP/1.1 implementation may internally represent a parsed
8464 Expires date as earlier than the proper value, but MUST NOT
8465 internally represent a parsed Expires date as later than the
8468 o All expiration-related calculations must be done in GMT. The
8469 local time zone MUST NOT influence the calculation or comparison
8470 of an age or expiration time.
8472 o If an HTTP header incorrectly carries a date value with a time
8473 zone other than GMT, it must be converted into GMT using the most
8474 conservative possible conversion.
8476 19.4 Differences Between HTTP Entities and MIME Entities
8478 HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
8479 822) and the Multipurpose Internet Mail Extensions (MIME ) to allow
8480 entities to be transmitted in an open variety of representations and
8481 with extensible mechanisms. However, MIME [7] discusses mail, and
8482 HTTP has a few features that are different from those described in
8483 MIME. These differences were carefully chosen to optimize
8484 performance over binary connections, to allow greater freedom in the
8485 use of new media types, to make date comparisons easier, and to
8486 acknowledge the practice of some early HTTP servers and clients.
8488 This appendix describes specific areas where HTTP differs from MIME.
8489 Proxies and gateways to strict MIME environments SHOULD be aware of
8490 these differences and provide the appropriate conversions where
8491 necessary. Proxies and gateways from MIME environments to HTTP also
8492 need to be aware of the differences because some conversions may be
8495 19.4.1 Conversion to Canonical Form
8497 MIME requires that an Internet mail entity be converted to canonical
8498 form prior to being transferred. Section 3.7.1 of this document
8499 describes the forms allowed for subtypes of the "text" media type
8500 when transmitted over HTTP. MIME requires that content with a type of
8501 "text" represent line breaks as CRLF and forbids the use of CR or LF
8502 outside of line break sequences. HTTP allows CRLF, bare CR, and bare
8503 LF to indicate a line break within text content when a message is
8504 transmitted over HTTP.
8506 Where it is possible, a proxy or gateway from HTTP to a strict MIME
8507 environment SHOULD translate all line breaks within the text media
8508 types described in section 3.7.1 of this document to the MIME
8509 canonical form of CRLF. Note, however, that this may be complicated
8510 by the presence of a Content-Encoding and by the fact that HTTP
8514 Fielding, et. al. Standards Track [Page 152]
8516 RFC 2068 HTTP/1.1 January 1997
8519 allows the use of some character sets which do not use octets 13 and
8520 10 to represent CR and LF, as is the case for some multi-byte
8523 19.4.2 Conversion of Date Formats
8525 HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
8526 simplify the process of date comparison. Proxies and gateways from
8527 other protocols SHOULD ensure that any Date header field present in a
8528 message conforms to one of the HTTP/1.1 formats and rewrite the date
8531 19.4.3 Introduction of Content-Encoding
8533 MIME does not include any concept equivalent to HTTP/1.1's Content-
8534 Encoding header field. Since this acts as a modifier on the media
8535 type, proxies and gateways from HTTP to MIME-compliant protocols MUST
8536 either change the value of the Content-Type header field or decode
8537 the entity-body before forwarding the message. (Some experimental
8538 applications of Content-Type for Internet mail have used a media-type
8539 parameter of ";conversions=<content-coding>" to perform an equivalent
8540 function as Content-Encoding. However, this parameter is not part of
8543 19.4.4 No Content-Transfer-Encoding
8545 HTTP does not use the Content-Transfer-Encoding (CTE) field of MIME.
8546 Proxies and gateways from MIME-compliant protocols to HTTP MUST
8547 remove any non-identity CTE ("quoted-printable" or "base64") encoding
8548 prior to delivering the response message to an HTTP client.
8550 Proxies and gateways from HTTP to MIME-compliant protocols are
8551 responsible for ensuring that the message is in the correct format
8552 and encoding for safe transport on that protocol, where "safe
8553 transport" is defined by the limitations of the protocol being used.
8554 Such a proxy or gateway SHOULD label the data with an appropriate
8555 Content-Transfer-Encoding if doing so will improve the likelihood of
8556 safe transport over the destination protocol.
8558 19.4.5 HTTP Header Fields in Multipart Body-Parts
8560 In MIME, most header fields in multipart body-parts are generally
8561 ignored unless the field name begins with "Content-". In HTTP/1.1,
8562 multipart body-parts may contain any HTTP header fields which are
8563 significant to the meaning of that part.
8570 Fielding, et. al. Standards Track [Page 153]
8572 RFC 2068 HTTP/1.1 January 1997
8575 19.4.6 Introduction of Transfer-Encoding
8577 HTTP/1.1 introduces the Transfer-Encoding header field (section
8578 14.40). Proxies/gateways MUST remove any transfer coding prior to
8579 forwarding a message via a MIME-compliant protocol.
8581 A process for decoding the "chunked" transfer coding (section 3.6)
8582 can be represented in pseudo-code as:
8585 read chunk-size, chunk-ext (if any) and CRLF
8586 while (chunk-size > 0) {
8587 read chunk-data and CRLF
8588 append chunk-data to entity-body
8589 length := length + chunk-size
8590 read chunk-size and CRLF
8593 while (entity-header not empty) {
8594 append entity-header to existing header fields
8597 Content-Length := length
8598 Remove "chunked" from Transfer-Encoding
8602 HTTP is not a MIME-compliant protocol (see appendix 19.4). However,
8603 HTTP/1.1 messages may include a single MIME-Version general-header
8604 field to indicate what version of the MIME protocol was used to
8605 construct the message. Use of the MIME-Version header field indicates
8606 that the message is in full compliance with the MIME protocol.
8607 Proxies/gateways are responsible for ensuring full compliance (where
8608 possible) when exporting HTTP messages to strict MIME environments.
8610 MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
8612 MIME version "1.0" is the default for use in HTTP/1.1. However,
8613 HTTP/1.1 message parsing and semantics are defined by this document
8614 and not the MIME specification.
8616 19.5 Changes from HTTP/1.0
8618 This section summarizes major differences between versions HTTP/1.0
8626 Fielding, et. al. Standards Track [Page 154]
8628 RFC 2068 HTTP/1.1 January 1997
8631 19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
8634 The requirements that clients and servers support the Host request-
8635 header, report an error if the Host request-header (section 14.23) is
8636 missing from an HTTP/1.1 request, and accept absolute URIs (section
8637 5.1.2) are among the most important changes defined by this
8640 Older HTTP/1.0 clients assumed a one-to-one relationship of IP
8641 addresses and servers; there was no other established mechanism for
8642 distinguishing the intended server of a request than the IP address
8643 to which that request was directed. The changes outlined above will
8644 allow the Internet, once older HTTP clients are no longer common, to
8645 support multiple Web sites from a single IP address, greatly
8646 simplifying large operational Web servers, where allocation of many
8647 IP addresses to a single host has created serious problems. The
8648 Internet will also be able to recover the IP addresses that have been
8649 allocated for the sole purpose of allowing special-purpose domain
8650 names to be used in root-level HTTP URLs. Given the rate of growth of
8651 the Web, and the number of servers already deployed, it is extremely
8652 important that all implementations of HTTP (including updates to
8653 existing HTTP/1.0 applications) correctly implement these
8656 o Both clients and servers MUST support the Host request-header.
8658 o Host request-headers are required in HTTP/1.1 requests.
8660 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
8661 request does not include a Host request-header.
8663 o Servers MUST accept absolute URIs.
8682 Fielding, et. al. Standards Track [Page 155]
8684 RFC 2068 HTTP/1.1 January 1997
8687 19.6 Additional Features
8689 This appendix documents protocol elements used by some existing HTTP
8690 implementations, but not consistently and correctly across most
8691 HTTP/1.1 applications. Implementers should be aware of these
8692 features, but cannot rely upon their presence in, or interoperability
8693 with, other HTTP/1.1 applications. Some of these describe proposed
8694 experimental features, and some describe features that experimental
8695 deployment found lacking that are now addressed in the base HTTP/1.1
8698 19.6.1 Additional Request Methods
8702 The PATCH method is similar to PUT except that the entity contains a
8703 list of differences between the original version of the resource
8704 identified by the Request-URI and the desired content of the resource
8705 after the PATCH action has been applied. The list of differences is
8706 in a format defined by the media type of the entity (e.g.,
8707 "application/diff") and MUST include sufficient information to allow
8708 the server to recreate the changes necessary to convert the original
8709 version of the resource to the desired version.
8711 If the request passes through a cache and the Request-URI identifies
8712 a currently cached entity, that entity MUST be removed from the
8713 cache. Responses to this method are not cachable.
8715 The actual method for determining how the patched resource is placed,
8716 and what happens to its predecessor, is defined entirely by the
8717 origin server. If the original version of the resource being patched
8718 included a Content-Version header field, the request entity MUST
8719 include a Derived-From header field corresponding to the value of the
8720 original Content-Version header field. Applications are encouraged to
8721 use these fields for constructing versioning relationships and
8722 resolving version conflicts.
8724 PATCH requests must obey the message transmission requirements set
8727 Caches that implement PATCH should invalidate cached responses as
8728 defined in section 13.10 for PUT.
8732 The LINK method establishes one or more Link relationships between
8733 the existing resource identified by the Request-URI and other
8734 existing resources. The difference between LINK and other methods
8738 Fielding, et. al. Standards Track [Page 156]
8740 RFC 2068 HTTP/1.1 January 1997
8743 allowing links to be established between resources is that the LINK
8744 method does not allow any message-body to be sent in the request and
8745 does not directly result in the creation of new resources.
8747 If the request passes through a cache and the Request-URI identifies
8748 a currently cached entity, that entity MUST be removed from the
8749 cache. Responses to this method are not cachable.
8751 Caches that implement LINK should invalidate cached responses as
8752 defined in section 13.10 for PUT.
8756 The UNLINK method removes one or more Link relationships from the
8757 existing resource identified by the Request-URI. These relationships
8758 may have been established using the LINK method or by any other
8759 method supporting the Link header. The removal of a link to a
8760 resource does not imply that the resource ceases to exist or becomes
8761 inaccessible for future references.
8763 If the request passes through a cache and the Request-URI identifies
8764 a currently cached entity, that entity MUST be removed from the
8765 cache. Responses to this method are not cachable.
8767 Caches that implement UNLINK should invalidate cached responses as
8768 defined in section 13.10 for PUT.
8770 19.6.2 Additional Header Field Definitions
8774 The Alternates response-header field has been proposed as a means for
8775 the origin server to inform the client about other available
8776 representations of the requested resource, along with their
8777 distinguishing attributes, and thus providing a more reliable means
8778 for a user agent to perform subsequent selection of another
8779 representation which better fits the desires of its user (described
8780 as agent-driven negotiation in section 12).
8794 Fielding, et. al. Standards Track [Page 157]
8796 RFC 2068 HTTP/1.1 January 1997
8799 The Alternates header field is orthogonal to the Vary header field in
8800 that both may coexist in a message without affecting the
8801 interpretation of the response or the available representations. It
8802 is expected that Alternates will provide a significant improvement
8803 over the server-driven negotiation provided by the Vary field for
8804 those resources that vary over common dimensions like type and
8807 The Alternates header field will be defined in a future
8810 19.6.2.2 Content-Version
8812 The Content-Version entity-header field defines the version tag
8813 associated with a rendition of an evolving entity. Together with the
8814 Derived-From field described in section 19.6.2.3, it allows a group
8815 of people to work simultaneously on the creation of a work as an
8816 iterative process. The field should be used to allow evolution of a
8817 particular work along a single path rather than derived works or
8818 renditions in different representations.
8820 Content-Version = "Content-Version" ":" quoted-string
8822 Examples of the Content-Version field include:
8824 Content-Version: "2.1.2"
8825 Content-Version: "Fred 19950116-12:26:48"
8826 Content-Version: "2.5a4-omega7"
8828 19.6.2.3 Derived-From
8830 The Derived-From entity-header field can be used to indicate the
8831 version tag of the resource from which the enclosed entity was
8832 derived before modifications were made by the sender. This field is
8833 used to help manage the process of merging successive changes to a
8834 resource, particularly when such changes are being made in parallel
8835 and from multiple sources.
8837 Derived-From = "Derived-From" ":" quoted-string
8839 An example use of the field is:
8841 Derived-From: "2.1.1"
8843 The Derived-From field is required for PUT and PATCH requests if the
8844 entity being sent was previously retrieved from the same URI and a
8845 Content-Version header was included with the entity when it was last
8850 Fielding, et. al. Standards Track [Page 158]
8852 RFC 2068 HTTP/1.1 January 1997
8857 The Link entity-header field provides a means for describing a
8858 relationship between two resources, generally between the requested
8859 resource and some other resource. An entity MAY include multiple Link
8860 values. Links at the metainformation level typically indicate
8861 relationships like hierarchical structure and navigation paths. The
8862 Link field is semantically equivalent to the <LINK> element in
8865 Link = "Link" ":" #("<" URI ">" *( ";" link-param )
8867 link-param = ( ( "rel" "=" relationship )
8868 | ( "rev" "=" relationship )
8869 | ( "title" "=" quoted-string )
8870 | ( "anchor" "=" <"> URI <"> )
8871 | ( link-extension ) )
8873 link-extension = token [ "=" ( token | quoted-string ) ]
8875 relationship = sgml-name
8876 | ( <"> sgml-name *( SP sgml-name) <"> )
8878 sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )
8880 Relationship values are case-insensitive and MAY be extended within
8881 the constraints of the sgml-name syntax. The title parameter MAY be
8882 used to label the destination of a link such that it can be used as
8883 identification within a human-readable menu. The anchor parameter MAY
8884 be used to indicate a source anchor other than the entire current
8885 resource, such as a fragment of this resource or a third resource.
8887 Examples of usage include:
8889 Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"
8891 Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"
8893 The first example indicates that chapter2 is previous to this
8894 resource in a logical navigation path. The second indicates that the
8895 person responsible for making the resource available is identified by
8896 the given e-mail address.
8900 The URI header field has, in past versions of this specification,
8901 been used as a combination of the existing Location, Content-
8902 Location, and Vary header fields as well as the future Alternates
8906 Fielding, et. al. Standards Track [Page 159]
8908 RFC 2068 HTTP/1.1 January 1997
8911 field (above). Its primary purpose has been to include a list of
8912 additional URIs for the resource, including names and mirror
8913 locations. However, it has become clear that the combination of many
8914 different functions within this single field has been a barrier to
8915 consistently and correctly implementing any of those functions.
8916 Furthermore, we believe that the identification of names and mirror
8917 locations would be better performed via the Link header field. The
8918 URI header field is therefore deprecated in favor of those other
8921 URI-header = "URI" ":" 1#( "<" URI ">" )
8923 19.7 Compatibility with Previous Versions
8925 It is beyond the scope of a protocol specification to mandate
8926 compliance with previous versions. HTTP/1.1 was deliberately
8927 designed, however, to make supporting previous versions easy. It is
8928 worth noting that at the time of composing this specification, we
8929 would expect commercial HTTP/1.1 servers to:
8931 o recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1
8934 o understand any valid request in the format of HTTP/0.9, 1.0, or
8937 o respond appropriately with a message in the same major version used
8940 And we would expect HTTP/1.1 clients to:
8942 o recognize the format of the Status-Line for HTTP/1.0 and 1.1
8945 o understand any valid response in the format of HTTP/0.9, 1.0, or
8948 For most implementations of HTTP/1.0, each connection is established
8949 by the client prior to the request and closed by the server after
8950 sending the response. A few implementations implement the Keep-Alive
8951 version of persistent connections described in section 19.7.1.1.
8962 Fielding, et. al. Standards Track [Page 160]
8964 RFC 2068 HTTP/1.1 January 1997
8967 19.7.1 Compatibility with HTTP/1.0 Persistent Connections
8969 Some clients and servers may wish to be compatible with some previous
8970 implementations of persistent connections in HTTP/1.0 clients and
8971 servers. Persistent connections in HTTP/1.0 must be explicitly
8972 negotiated as they are not the default behavior. HTTP/1.0
8973 experimental implementations of persistent connections are faulty,
8974 and the new facilities in HTTP/1.1 are designed to rectify these
8975 problems. The problem was that some existing 1.0 clients may be
8976 sending Keep-Alive to a proxy server that doesn't understand
8977 Connection, which would then erroneously forward it to the next
8978 inbound server, which would establish the Keep-Alive connection and
8979 result in a hung HTTP/1.0 proxy waiting for the close on the
8980 response. The result is that HTTP/1.0 clients must be prevented from
8981 using Keep-Alive when talking to proxies.
8983 However, talking to proxies is the most important use of persistent
8984 connections, so that prohibition is clearly unacceptable. Therefore,
8985 we need some other mechanism for indicating a persistent connection
8986 is desired, which is safe to use even when talking to an old proxy
8987 that ignores Connection. Persistent connections are the default for
8988 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
8989 declaring non-persistence.
8991 The following describes the original HTTP/1.0 form of persistent
8994 When it connects to an origin server, an HTTP client MAY send the
8995 Keep-Alive connection-token in addition to the Persist connection-
8998 Connection: Keep-Alive
9000 An HTTP/1.0 server would then respond with the Keep-Alive connection
9001 token and the client may proceed with an HTTP/1.0 (or Keep-Alive)
9002 persistent connection.
9004 An HTTP/1.1 server may also establish persistent connections with
9005 HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
9006 However, a persistent connection with an HTTP/1.0 client cannot make
9007 use of the chunked transfer-coding, and therefore MUST use a
9008 Content-Length for marking the ending boundary of each message.
9010 A client MUST NOT send the Keep-Alive connection token to a proxy
9011 server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1
9012 for parsing the Connection header field.
9018 Fielding, et. al. Standards Track [Page 161]
9020 RFC 2068 HTTP/1.1 January 1997
9023 19.7.1.1 The Keep-Alive Header
9025 When the Keep-Alive connection-token has been transmitted with a
9026 request or a response, a Keep-Alive header field MAY also be
9027 included. The Keep-Alive header field takes the following form:
9029 Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
9031 keepalive-param = param-name "=" value
9033 The Keep-Alive header itself is optional, and is used only if a
9034 parameter is being sent. HTTP/1.1 does not define any parameters.
9036 If the Keep-Alive header is sent, the corresponding connection token
9037 MUST be transmitted. The Keep-Alive header MUST be ignored if
9038 received without the connection token.
9074 Fielding, et. al. Standards Track [Page 162]
projects / profile / ivi / libsoup2.4.git / blob