1 |
|
2 |
|
3 |
HTTP Working Group R. Fielding, UC Irvine |
4 |
INTERNET-DRAFT H. Frystyk, MIT/LCS |
5 |
<draft-ietf-http-v11-spec-04> T. Berners-Lee, MIT/LCS |
6 |
J. Gettys, DEC |
7 |
J. C. Mogul, DEC |
8 |
Expires October 3, 1996 June 3, 1996 |
9 |
|
10 |
|
11 |
Hypertext Transfer Protocol -- HTTP/1.1 |
12 |
|
13 |
Status of this Memo |
14 |
|
15 |
This document is an Internet-Draft. Internet-Drafts are working |
16 |
documents of the Internet Engineering Task Force (IETF), its areas, and |
17 |
its working groups. Note that other groups may also distribute working |
18 |
documents as Internet-Drafts. |
19 |
|
20 |
Internet-Drafts are draft documents valid for a maximum of six months |
21 |
and may be updated, replaced, or made obsolete by other documents at any |
22 |
time. It is inappropriate to use Internet-Drafts as reference material |
23 |
or to cite them other than as "work in progress". |
24 |
|
25 |
To learn the current status of any Internet-Draft, please check the |
26 |
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow |
27 |
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), |
28 |
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or |
29 |
ftp.isi.edu (US West Coast). |
30 |
|
31 |
Distribution of this document is unlimited. Please send comments to the |
32 |
HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the |
33 |
working group are archived at |
34 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions about |
35 |
HTTP and the applications which use HTTP should take place on the <www- |
36 |
talk@w3.org> mailing list. |
37 |
|
38 |
Abstract |
39 |
|
40 |
The Hypertext Transfer Protocol (HTTP) is an application-level protocol |
41 |
for distributed, collaborative, hypermedia information systems. It is a |
42 |
generic, stateless, object-oriented protocol which can be used for many |
43 |
tasks, such as name servers and distributed object management systems, |
44 |
through extension of its request methods. A feature of HTTP is the |
45 |
typing and negotiation of data representation, allowing systems to be |
46 |
built independently of the data being transferred. |
47 |
|
48 |
HTTP has been in use by the World-Wide Web global information initiative |
49 |
since 1990. This specification defines the protocol referred to as |
50 |
"HTTP/1.1". |
51 |
|
52 |
|
53 |
|
54 |
|
55 |
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 1] |
56 |
|
57 |
|
58 |
|
59 |
|
60 |
|
61 |
|
62 |
|
63 |
Table of Contents |
64 |
|
65 |
|
66 |
|
67 |
HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1................................1 |
68 |
|
69 |
1 Introduction.........................................................7 |
70 |
1.1 Purpose ..........................................................7 |
71 |
1.2 Requirements .....................................................7 |
72 |
1.3 Terminology ......................................................8 |
73 |
1.4 Overall Operation ...............................................11 |
74 |
|
75 |
2 Notational Conventions and Generic Grammar..........................13 |
76 |
2.1 Augmented BNF ...................................................13 |
77 |
2.2 Basic Rules .....................................................14 |
78 |
|
79 |
3 Protocol Parameters.................................................16 |
80 |
3.1 HTTP Version ....................................................16 |
81 |
3.2 Uniform Resource Identifiers ....................................17 |
82 |
3.3 Date/Time Formats ...............................................19 |
83 |
3.4 Character Sets ..................................................21 |
84 |
3.5 Content Codings .................................................21 |
85 |
3.6 Transfer Codings ................................................22 |
86 |
3.7 Media Types .....................................................24 |
87 |
3.8 Product Tokens ..................................................26 |
88 |
3.9 Quality Values ..................................................26 |
89 |
3.10 Language Tags ..................................................26 |
90 |
3.11 Entity Tags ....................................................27 |
91 |
3.12 Range Units ....................................................28 |
92 |
|
93 |
4 HTTP Message........................................................28 |
94 |
4.1 Message Types ...................................................28 |
95 |
4.2 Message Headers .................................................29 |
96 |
4.3 Message Body ....................................................29 |
97 |
4.4 Message Length ..................................................30 |
98 |
4.5 General Header Fields ...........................................31 |
99 |
|
100 |
5 Request.............................................................32 |
101 |
5.1 Request-Line ....................................................32 |
102 |
5.2 The Resource Identified by a Request ............................34 |
103 |
5.3 Request Header Fields ...........................................35 |
104 |
|
105 |
6 Response............................................................35 |
106 |
6.1 Status-Line .....................................................36 |
107 |
6.2 Response Header Fields ..........................................38 |
108 |
|
109 |
7 Entity..............................................................38 |
110 |
7.1 Entity Header Fields ............................................38 |
111 |
7.2 Entity Body .....................................................39 |
112 |
|
113 |
8 Connections.........................................................40 |
114 |
|
115 |
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 3] |
116 |
|
117 |
|
118 |
|
119 |
|
120 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
121 |
|
122 |
|
123 |
8.1 Persistent Connections ..........................................40 |
124 |
8.2 Message Transmission Requirements ...............................43 |
125 |
|
126 |
9 Method Definitions..................................................44 |
127 |
9.2 OPTIONS .........................................................45 |
128 |
9.3 GET .............................................................46 |
129 |
9.4 HEAD ............................................................46 |
130 |
9.5 POST ............................................................47 |
131 |
9.6 PUT .............................................................47 |
132 |
9.7 DELETE ..........................................................48 |
133 |
9.8 TRACE ...........................................................49 |
134 |
|
135 |
10 Status Code Definitions............................................49 |
136 |
10.1 Informational 1xx ..............................................49 |
137 |
10.2 Successful 2xx .................................................50 |
138 |
10.3 Redirection 3xx ................................................52 |
139 |
10.4 Client Error 4xx ...............................................55 |
140 |
10.5 Server Error 5xx ...............................................59 |
141 |
|
142 |
11 Access Authentication..............................................60 |
143 |
11.1 Basic Authentication Scheme ....................................61 |
144 |
11.2 Digest Authentication Scheme ...................................62 |
145 |
|
146 |
12 Content Negotiation................................................62 |
147 |
12.1 Server-driven Negotiation ......................................63 |
148 |
12.2 Agent-driven Negotiation .......................................64 |
149 |
12.3 Transparent Negotiation ........................................65 |
150 |
|
151 |
13 Caching in HTTP....................................................65 |
152 |
13.2 Expiration Model ...............................................69 |
153 |
13.3 Validation Model ...............................................75 |
154 |
13.4 Constructing Responses From Caches .............................80 |
155 |
13.5 Caching Negotiated Responses ...................................82 |
156 |
13.6 Shared and Non-Shared Caches ...................................83 |
157 |
13.7 Errors or Incomplete Response Cache Behavior ...................83 |
158 |
13.8 Invalidation After Updates or Deletions ........................84 |
159 |
13.9 Write-Through Mandatory ........................................85 |
160 |
13.10 Cache Replacement .............................................85 |
161 |
13.11 History Lists .................................................85 |
162 |
|
163 |
14 Header Field Definitions...........................................86 |
164 |
14.1 Accept .........................................................86 |
165 |
14.2 Accept-Charset .................................................88 |
166 |
14.3 Accept-Encoding ................................................89 |
167 |
14.4 Accept-Language ................................................89 |
168 |
14.5 Accept-Ranges ..................................................90 |
169 |
14.6 Age ............................................................91 |
170 |
14.7 Allow ..........................................................91 |
171 |
14.8 Authorization ..................................................92 |
172 |
14.9 Cache-Control ..................................................92 |
173 |
14.10 Connection ....................................................99 |
174 |
|
175 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 4] |
176 |
|
177 |
|
178 |
|
179 |
|
180 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
181 |
|
182 |
|
183 |
14.11 Content-Base ..................................................99 |
184 |
14.12 Content-Encoding ..............................................99 |
185 |
14.13 Content-Language .............................................100 |
186 |
14.14 Content-Length ...............................................101 |
187 |
14.15 Content-Location .............................................101 |
188 |
14.16 Content-MD5 ..................................................102 |
189 |
14.17 Content-Range ................................................103 |
190 |
14.18 Content-Type .................................................105 |
191 |
14.19 Date .........................................................105 |
192 |
14.20 ETag .........................................................106 |
193 |
14.21 Expires ......................................................106 |
194 |
14.22 From .........................................................107 |
195 |
14.23 Host .........................................................107 |
196 |
14.24 If-Modified-Since ............................................108 |
197 |
14.25 If-Match .....................................................109 |
198 |
14.26 If-None-Match ................................................110 |
199 |
14.27 If-Range .....................................................112 |
200 |
14.28 If-Unmodified-Since ..........................................112 |
201 |
14.29 Last-Modified ................................................113 |
202 |
14.30 Location .....................................................113 |
203 |
14.31 Max-Forwards .................................................114 |
204 |
14.32 Pragma .......................................................114 |
205 |
14.33 Proxy-Authenticate ...........................................115 |
206 |
14.34 Proxy-Authorization ..........................................115 |
207 |
14.35 Public .......................................................116 |
208 |
14.36 Range ........................................................116 |
209 |
14.37 Referer ......................................................119 |
210 |
14.38 Retry-After ..................................................119 |
211 |
14.39 Server .......................................................120 |
212 |
14.40 Transfer Encoding ............................................120 |
213 |
14.41 Upgrade ......................................................120 |
214 |
14.42 User-Agent ...................................................121 |
215 |
14.43 Vary .........................................................122 |
216 |
14.44 Via ..........................................................123 |
217 |
14.45 Warning ......................................................124 |
218 |
14.46 WWW-Authenticate .............................................126 |
219 |
|
220 |
15 Security Considerations...........................................126 |
221 |
15.1 Authentication of Clients .....................................126 |
222 |
15.2 Offering a Choice of Authentication Schemes ...................127 |
223 |
15.3 Abuse of Server Log Information ...............................128 |
224 |
15.4 Transfer of Sensitive Information .............................128 |
225 |
15.5 Attacks Based On File and Path Names ..........................129 |
226 |
15.6 Personal Information ..........................................130 |
227 |
15.7 Privacy Issues Connected to Accept Headers ....................130 |
228 |
15.8 DNS Spoofing ..................................................131 |
229 |
15.9 Location Headers and Spoofing .................................131 |
230 |
|
231 |
16 Acknowledgments...................................................131 |
232 |
|
233 |
17 References........................................................133 |
234 |
|
235 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 5] |
236 |
|
237 |
|
238 |
|
239 |
|
240 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
241 |
|
242 |
|
243 |
18 Authors' Addresses................................................136 |
244 |
|
245 |
19 Appendices........................................................137 |
246 |
19.1 Internet Media Type message/http ..............................137 |
247 |
19.2 Internet Media Type multipart/byteranges ......................138 |
248 |
19.3 Tolerant Applications .........................................139 |
249 |
19.4 Differences Between HTTP Entities and RFC 1521 Entities .......140 |
250 |
19.5 Changes from HTTP/1.0 .........................................142 |
251 |
19.6 Additional Features ...........................................143 |
252 |
19.7 Compatibility with Previous Versions ..........................147 |
253 |
19.8 Notes to RFC Editor and IANA ..................................149 |
254 |
|
255 |
|
256 |
|
257 |
|
258 |
|
259 |
|
260 |
|
261 |
|
262 |
|
263 |
|
264 |
|
265 |
|
266 |
|
267 |
|
268 |
|
269 |
|
270 |
|
271 |
|
272 |
|
273 |
|
274 |
|
275 |
|
276 |
|
277 |
|
278 |
|
279 |
|
280 |
|
281 |
|
282 |
|
283 |
|
284 |
|
285 |
|
286 |
|
287 |
|
288 |
|
289 |
|
290 |
|
291 |
|
292 |
|
293 |
|
294 |
|
295 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 6] |
296 |
|
297 |
|
298 |
|
299 |
|
300 |
|
301 |
|
302 |
|
303 |
|
304 |
1 Introduction |
305 |
|
306 |
|
307 |
1.1 Purpose |
308 |
|
309 |
The Hypertext Transfer Protocol (HTTP) is an application-level protocol |
310 |
for distributed, collaborative, hypermedia information systems. HTTP has |
311 |
been in use by the World-Wide Web global information initiative since |
312 |
1990. The first version of HTTP, referred to as HTTP/0.9, was a simple |
313 |
protocol for raw data transfer across the Internet. HTTP/1.0, as defined |
314 |
by RFC 1945 [6] , improved the protocol by allowing messages to be in |
315 |
the format of MIME-like messages, containing metainformation about the |
316 |
data transferred and modifiers on the request/response semantics. |
317 |
However, HTTP/1.0 does not sufficiently take into consideration the |
318 |
effects of hierarchical proxies, caching, the need for persistent |
319 |
connections, and virtual hosts. In addition, the proliferation of |
320 |
incompletely-implemented applications calling themselves "HTTP/1.0" has |
321 |
necessitated a protocol version change in order for two communicating |
322 |
applications to determine each other's true capabilities. |
323 |
|
324 |
This specification defines the protocol referred to as "HTTP/1.1". This |
325 |
protocol includes more stringent requirements than HTTP/1.0 in order to |
326 |
ensure reliable implementation of its features. |
327 |
|
328 |
Practical information systems require more functionality than simple |
329 |
retrieval, including search, front-end update, and annotation. HTTP |
330 |
allows an open-ended set of methods that indicate the purpose of a |
331 |
request. It builds on the discipline of reference provided by the |
332 |
Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or |
333 |
name (URN) , for indicating the resource to which a method is to be |
334 |
applied. Messages are passed in a format similar to that used by |
335 |
Internet mail as defined by the Multipurpose Internet Mail Extensions |
336 |
(MIME) . |
337 |
|
338 |
HTTP is also used as a generic protocol for communication between user |
339 |
agents and proxies/gateways to other Internet systems, including those |
340 |
supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS |
341 |
[10] protocols. In this way, HTTP allows basic hypermedia access to |
342 |
resources available from diverse applications. |
343 |
|
344 |
|
345 |
1.2 Requirements |
346 |
|
347 |
This specification uses the same words as RFC 1123 [8] for defining the |
348 |
significance of each particular requirement. These words are: |
349 |
|
350 |
|
351 |
MUST |
352 |
This word or the adjective "required" means that the item is an |
353 |
absolute requirement of the specification. |
354 |
|
355 |
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 7] |
356 |
|
357 |
|
358 |
|
359 |
|
360 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
361 |
|
362 |
|
363 |
SHOULD |
364 |
This word or the adjective "recommended" means that there may exist |
365 |
valid reasons in particular circumstances to ignore this item, but |
366 |
the full implications should be understood and the case carefully |
367 |
weighed before choosing a different course. |
368 |
|
369 |
MAY |
370 |
This word or the adjective "optional" means that this item is truly |
371 |
optional. One vendor may choose to include the item because a |
372 |
particular marketplace requires it or because it enhances the |
373 |
product, for example; another vendor may omit the same item. |
374 |
|
375 |
An implementation is not compliant if it fails to satisfy one or more of |
376 |
the MUST requirements for the protocols it implements. An implementation |
377 |
that satisfies all the MUST and all the SHOULD requirements for its |
378 |
protocols is said to be "unconditionally compliant"; one that satisfies |
379 |
all the MUST requirements but not all the SHOULD requirements for its |
380 |
protocols is said to be "conditionally compliant." |
381 |
|
382 |
|
383 |
1.3 Terminology |
384 |
|
385 |
This specification uses a number of terms to refer to the roles played |
386 |
by participants in, and objects of, the HTTP communication. |
387 |
|
388 |
connection |
389 |
A transport layer virtual circuit established between two programs |
390 |
for the purpose of communication. |
391 |
|
392 |
message |
393 |
The basic unit of HTTP communication, consisting of a structured |
394 |
sequence of octets matching the syntax defined in section 4 and |
395 |
transmitted via the connection. |
396 |
|
397 |
request |
398 |
An HTTP request message, as defined in section 5. |
399 |
|
400 |
response |
401 |
An HTTP response message, as defined in section 6. |
402 |
|
403 |
resource |
404 |
A network data object or service that can be identified by a URI, as |
405 |
defined in section 3.2. Resources may be available in multiple |
406 |
languages, data formats, size, resolutions, or vary in other ways. |
407 |
|
408 |
entity |
409 |
The information transferred as the payload of a request or response. |
410 |
An entity consists of metainformation in the form of entity-header |
411 |
fields and content in the form of an entity-body, as described in |
412 |
section 7. |
413 |
|
414 |
|
415 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 8] |
416 |
|
417 |
|
418 |
|
419 |
|
420 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
421 |
|
422 |
|
423 |
representation |
424 |
An entity included with a response that is subject to content |
425 |
negotiation, as described in section 12. There may exist multiple |
426 |
representations associated with a particular response status. |
427 |
|
428 |
content negotiation |
429 |
The mechanism for selecting the appropriate representation when |
430 |
servicing a request, as described in section 12. The representation |
431 |
of entities in any response can be negotiated (including error |
432 |
responses), as well as entities derived from resources. |
433 |
|
434 |
variant |
435 |
Each representation of that resource that corresponds to a different |
436 |
sequence of entities that could be returned for a requested resource |
437 |
is termed a variant. |
438 |
|
439 |
client |
440 |
A program that establishes connections for the purpose of sending |
441 |
requests. |
442 |
|
443 |
user agent |
444 |
The client which initiates a request. These are often browsers, |
445 |
editors, spiders (web-traversing robots), or other end user tools. |
446 |
|
447 |
server |
448 |
An application program that accepts connections in order to service |
449 |
requests by sending back responses. Any given program may be capable |
450 |
of being both a client and a server; our use of these terms refers |
451 |
only to the role being performed by the program for a particular |
452 |
connection, rather than to the program's capabilities in general. |
453 |
Likewise, any server may act as an origin server, proxy, gateway, or |
454 |
tunnel, switching behavior based on the nature of each request. |
455 |
|
456 |
origin server |
457 |
The server on which a given resource resides or is to be created. |
458 |
|
459 |
proxy |
460 |
An intermediary program which acts as both a server and a client for |
461 |
the purpose of making requests on behalf of other clients. Requests |
462 |
are serviced internally or by passing them on, with possible |
463 |
translation, to other servers. A proxy must implement both the client |
464 |
and server requirements of this specification. |
465 |
|
466 |
gateway |
467 |
A server which acts as an intermediary for some other server. Unlike |
468 |
a proxy, a gateway receives requests as if it were the origin server |
469 |
for the requested resource; the requesting client may not be aware |
470 |
that it is communicating with a gateway. |
471 |
|
472 |
tunnel |
473 |
An intermediary program which is acting as a blind relay between two |
474 |
|
475 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 9] |
476 |
|
477 |
|
478 |
|
479 |
|
480 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
481 |
|
482 |
|
483 |
connections. Once active, a tunnel is not considered a party to the |
484 |
HTTP communication, though the tunnel may have been initiated by an |
485 |
HTTP request. The tunnel ceases to exist when both ends of the |
486 |
relayed connections are closed. |
487 |
|
488 |
cache |
489 |
A program's local store of response messages and the subsystem that |
490 |
controls its message storage, retrieval, and deletion. A cache stores |
491 |
cachable responses in order to reduce the response time and network |
492 |
bandwidth consumption on future, equivalent requests. Any client or |
493 |
server may include a cache, though a cache cannot be used by a server |
494 |
that is acting as a tunnel. |
495 |
|
496 |
cachable |
497 |
A response is cachable if a cache is allowed to store a copy of the |
498 |
response message for use in answering subsequent requests. The rules |
499 |
for determining the cachability of HTTP responses are defined in |
500 |
section 13. Even if a resource is cachable, there may be additional |
501 |
constraints on whether a cache can use the cached copy for a |
502 |
particular request. |
503 |
|
504 |
first-hand |
505 |
A response is first-hand if it comes directly and without unnecessary |
506 |
delay from the origin server, perhaps via one or more proxies. A |
507 |
response is also first-hand if its validity has just been checked |
508 |
directly with the origin server. |
509 |
|
510 |
explicit expiration time |
511 |
The time at which the origin server intends that an entity should no |
512 |
longer be returned by a cache without further validation. |
513 |
|
514 |
heuristic expiration time |
515 |
An expiration time assigned by a cache when no explicit expiration |
516 |
time is available. |
517 |
|
518 |
age |
519 |
The age of a response is the time since it was sent by, or |
520 |
successfully validated with, the origin server. |
521 |
|
522 |
freshness lifetime |
523 |
The length of time between the generation of a response and its |
524 |
expiration time. |
525 |
|
526 |
fresh |
527 |
A response is fresh if its age has not yet exceeded its freshness |
528 |
lifetime. |
529 |
|
530 |
stale |
531 |
A response is stale if its age has passed its freshness lifetime. |
532 |
|
533 |
|
534 |
|
535 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 10] |
536 |
|
537 |
|
538 |
|
539 |
|
540 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
541 |
|
542 |
|
543 |
semantically transparent |
544 |
A cache that does not affect the semantics of a request and the |
545 |
resulting response. A response is considered to be unaffected by the |
546 |
cache when the client receives a response equivalent to what it would |
547 |
have received if it had made the request directly to the origin |
548 |
server. |
549 |
|
550 |
validator |
551 |
A protocol element (e.g., an entity tag or a Last-Modified time) that |
552 |
is used to find out whether a cache entry is an equivalent copy of |
553 |
an entity. |
554 |
|
555 |
|
556 |
1.4 Overall Operation |
557 |
|
558 |
The HTTP protocol is a request/response protocol. A client sends a |
559 |
request to the server in the form of a request method, URI, and protocol |
560 |
version, followed by a MIME-like message containing request modifiers, |
561 |
client information, and possible body content over a connection with a |
562 |
server. The server responds with a status line, including the message's |
563 |
protocol version and a success or error code, followed by a MIME-like |
564 |
message containing server information, entity metainformation, and |
565 |
possible entity-body content. The relationship between HTTP and MIME is |
566 |
described in appendix 19.4. |
567 |
|
568 |
Most HTTP communication is initiated by a user agent and consists of a |
569 |
request to be applied to a resource on some origin server. In the |
570 |
simplest case, this may be accomplished via a single connection (v) |
571 |
between the user agent (UA) and the origin server (O). |
572 |
|
573 |
request chain ------------------------> |
574 |
UA -------------------v------------------- O |
575 |
<----------------------- response chain |
576 |
|
577 |
A more complicated situation occurs when one or more intermediaries are |
578 |
present in the request/response chain. There are three common forms of |
579 |
intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, |
580 |
receiving requests for a URI in its absolute form, rewriting all or part |
581 |
of the message, and forwarding the reformatted request toward the server |
582 |
identified by the URI. A gateway is a receiving agent, acting as a layer |
583 |
above some other server(s) and, if necessary, translating the requests |
584 |
to the underlying server's protocol. A tunnel acts as a relay point |
585 |
between two connections without changing the messages; tunnels are used |
586 |
when the communication needs to pass through an intermediary (such as a |
587 |
firewall) even when the intermediary cannot understand the contents of |
588 |
the messages. |
589 |
|
590 |
request chain --------------------------------------> |
591 |
UA -----v----- A -----v----- B -----v----- C -----v----- O |
592 |
<------------------------------------- response chain |
593 |
|
594 |
|
595 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 11] |
596 |
|
597 |
|
598 |
|
599 |
|
600 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
601 |
|
602 |
|
603 |
The figure above shows three intermediaries (A, B, and C) between the |
604 |
user agent and origin server. A request or response message that travels |
605 |
the whole chain will pass through four separate connections. This |
606 |
distinction is important because some HTTP communication options may |
607 |
apply only to the connection with the nearest, non-tunnel neighbor, only |
608 |
to the end-points of the chain, or to all connections along the chain. |
609 |
Although the diagram is linear, each participant may be engaged in |
610 |
multiple, simultaneous communications. For example, B may be receiving |
611 |
requests from many clients other than A, and/or forwarding requests to |
612 |
servers other than C, at the same time that it is handling A's request. |
613 |
|
614 |
Any party to the communication which is not acting as a tunnel may |
615 |
employ an internal cache for handling requests. The effect of a cache is |
616 |
that the request/response chain is shortened if one of the participants |
617 |
along the chain has a cached response applicable to that request. The |
618 |
following illustrates the resulting chain if B has a cached copy of an |
619 |
earlier response from O (via C) for a request which has not been cached |
620 |
by UA or A. |
621 |
|
622 |
request chain ----------> |
623 |
UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
624 |
<--------- response chain |
625 |
|
626 |
Not all responses are usefully cachable, and some requests may contain |
627 |
modifiers which place special requirements on cache behavior. HTTP |
628 |
requirements for cache behavior and cachable responses are defined in |
629 |
section 13. |
630 |
|
631 |
In fact, there are a wide variety of architectures and configurations of |
632 |
caches and proxies currently being experimented with or deployed across |
633 |
the World Wide Web; these systems include national hierarchies of proxy |
634 |
caches to save transoceanic bandwidth, systems that broadcast or |
635 |
multicast cache entries, organizations that distribute subsets of cached |
636 |
data via CD-ROM, and so on. HTTP systems are used in corporate intranets |
637 |
over high-bandwidth links, and for access via PDAs with low-power radio |
638 |
links and intermittent connectivity. The goal of HTTP/1.1 is to support |
639 |
the wide diversity of configurations already deployed while introducing |
640 |
protocol constructs that meet the needs of those who build web |
641 |
applications that require high reliability and, failing that, at least |
642 |
reliable indications of failure. |
643 |
|
644 |
HTTP communication usually takes place over TCP/IP connections. The |
645 |
default port is TCP 80, but other ports can be used. This does not |
646 |
preclude HTTP from being implemented on top of any other protocol on the |
647 |
Internet, or on other networks. HTTP only presumes a reliable transport; |
648 |
any protocol that provides such guarantees can be used; the mapping of |
649 |
the HTTP/1.1 request and response structures onto the transport data |
650 |
units of the protocol in question is outside the scope of this |
651 |
specification. |
652 |
|
653 |
|
654 |
|
655 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 12] |
656 |
|
657 |
|
658 |
|
659 |
|
660 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
661 |
|
662 |
|
663 |
In HTTP/1.0, most implementations used a new connection for each |
664 |
request/response exchange. In HTTP/1.1, a connection may be used for one |
665 |
or more request/response exchanges, although connections may be closed |
666 |
for a variety of reasons (see section 8.1). |
667 |
|
668 |
|
669 |
2 Notational Conventions and Generic Grammar |
670 |
|
671 |
|
672 |
2.1 Augmented BNF |
673 |
|
674 |
All of the mechanisms specified in this document are described in both |
675 |
prose and an augmented Backus-Naur Form (BNF) similar to that used by |
676 |
RFC 822 [9]. Implementers will need to be familiar with the notation in |
677 |
order to understand this specification. The augmented BNF includes the |
678 |
following constructs: |
679 |
|
680 |
|
681 |
name = definition |
682 |
The name of a rule is simply the name itself (without any enclosing |
683 |
"<" and ">") and is separated from its definition by the equal "=" |
684 |
character. Whitespace is only significant in that indentation of |
685 |
continuation lines is used to indicate a rule definition that spans |
686 |
more than one line. Certain basic rules are in uppercase, such as |
687 |
SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used |
688 |
within definitions whenever their presence will facilitate |
689 |
discerning the use of rule names. |
690 |
|
691 |
|
692 |
"literal" |
693 |
Quotation marks surround literal text. Unless stated otherwise, the |
694 |
text is case-insensitive. |
695 |
|
696 |
|
697 |
rule1 | rule2 |
698 |
Elements separated by a bar ("|") are alternatives, e.g., "yes | |
699 |
no" will accept yes or no. |
700 |
|
701 |
|
702 |
(rule1 rule2) |
703 |
Elements enclosed in parentheses are treated as a single element. |
704 |
Thus, "(elem (foo | bar) elem)" allows the token sequences |
705 |
"elem foo elem" and "elem bar elem". |
706 |
|
707 |
|
708 |
*rule |
709 |
The character "*" preceding an element indicates repetition. The |
710 |
full form is "<n>*<m>element" indicating at least <n> and at most |
711 |
<m> occurrences of element. Default values are 0 and infinity so |
712 |
that "*(element)" allows any number, including zero; "1*element" |
713 |
requires at least one; and "1*2element" allows one or two. |
714 |
|
715 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 13] |
716 |
|
717 |
|
718 |
|
719 |
|
720 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
721 |
|
722 |
|
723 |
[rule] |
724 |
Square brackets enclose optional elements; "[foo bar]" is |
725 |
equivalent to "*1(foo bar)". |
726 |
|
727 |
|
728 |
N rule |
729 |
Specific repetition: "<n>(element)" is equivalent to |
730 |
"<n>*<n>(element)"; that is, exactly <n> occurrences of (element). |
731 |
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three |
732 |
alphabetic characters. |
733 |
|
734 |
|
735 |
#rule |
736 |
A construct "#" is defined, similar to "*", for defining lists of |
737 |
elements. The full form is "<n>#<m>element " indicating at least |
738 |
<n> and at most <m> elements, each separated by one or more commas |
739 |
(",") and optional linear whitespace (LWS). This makes the usual |
740 |
form of lists very easy; a rule such as |
741 |
"( *LWS element *( *LWS "," *LWS element )) " can be shown as |
742 |
"1#element". Wherever this construct is used, null elements are |
743 |
allowed, but do not contribute to the count of elements present. |
744 |
That is, "(element), , (element) " is permitted, but counts as only |
745 |
two elements. Therefore, where at least one element is required, at |
746 |
least one non-null element must be present. Default values are 0 |
747 |
and infinity so that "#element" allows any number, including zero; |
748 |
"1#element" requires at least one; and "1#2element" allows one or |
749 |
two. |
750 |
|
751 |
|
752 |
; comment |
753 |
A semi-colon, set off some distance to the right of rule text, |
754 |
starts a comment that continues to the end of line. This is a |
755 |
simple way of including useful notes in parallel with the |
756 |
specifications. |
757 |
|
758 |
|
759 |
implied *LWS |
760 |
The grammar described by this specification is word-based. Except |
761 |
where noted otherwise, linear whitespace (LWS) can be included |
762 |
between any two adjacent words (token or quoted-string), and |
763 |
between adjacent tokens and delimiters (tspecials), without |
764 |
changing the interpretation of a field. At least one delimiter |
765 |
(tspecials) must exist between any two tokens, since they would |
766 |
otherwise be interpreted as a single token. |
767 |
|
768 |
|
769 |
2.2 Basic Rules |
770 |
|
771 |
The following rules are used throughout this specification to describe |
772 |
basic parsing constructs. The US-ASCII coded character set is defined by |
773 |
ANSI X3.4-1986 [21]. |
774 |
|
775 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14] |
776 |
|
777 |
|
778 |
|
779 |
|
780 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
781 |
|
782 |
|
783 |
OCTET = <any 8-bit sequence of data> |
784 |
CHAR = <any US-ASCII character (octets 0 - 127)> |
785 |
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |
786 |
LOALPHA = <any US-ASCII lowercase letter "a".."z"> |
787 |
ALPHA = UPALPHA | LOALPHA |
788 |
DIGIT = <any US-ASCII digit "0".."9"> |
789 |
CTL = <any US-ASCII control character |
790 |
(octets 0 - 31) and DEL (127)> |
791 |
CR = <US-ASCII CR, carriage return (13)> |
792 |
LF = <US-ASCII LF, linefeed (10)> |
793 |
SP = <US-ASCII SP, space (32)> |
794 |
HT = <US-ASCII HT, horizontal-tab (9)> |
795 |
<"> = <US-ASCII double-quote mark (34)> |
796 |
|
797 |
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |
798 |
protocol elements except the entity-body (see appendix 19.3 for tolerant |
799 |
applications). The end-of-line marker within an entity-body is defined |
800 |
by its associated media type, as described in section 3.7. |
801 |
|
802 |
CRLF = CR LF |
803 |
|
804 |
HTTP/1.1 headers can be folded onto multiple lines if the continuation |
805 |
line begins with a space or horizontal tab. All linear white space, |
806 |
including folding, has the same semantics as SP. |
807 |
|
808 |
LWS = [CRLF] 1*( SP | HT ) |
809 |
|
810 |
The TEXT rule is only used for descriptive field contents and values |
811 |
that are not intended to be interpreted by the message parser. Words of |
812 |
*TEXT may contain characters from character sets other than ISO 8859-1 |
813 |
[22] only when encoded according to the rules of RFC 1522 [14]. |
814 |
|
815 |
TEXT = <any OCTET except CTLs, |
816 |
but including LWS> |
817 |
|
818 |
Hexadecimal numeric characters are used in several protocol elements. |
819 |
|
820 |
HEX = "A" | "B" | "C" | "D" | "E" | "F" |
821 |
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT |
822 |
|
823 |
Many HTTP/1.1 header field values consist of words separated by LWS or |
824 |
special characters. These special characters MUST be in a quoted string |
825 |
to be used within a parameter value. |
826 |
|
827 |
token = 1*<any CHAR except CTLs or tspecials> |
828 |
|
829 |
tspecials = "(" | ")" | "<" | ">" | "@" |
830 |
| "," | ";" | ":" | "\" | <"> |
831 |
| "/" | "[" | "]" | "?" | "=" |
832 |
| "{" | "}" | SP | HT |
833 |
|
834 |
|
835 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 15] |
836 |
|
837 |
|
838 |
|
839 |
|
840 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
841 |
|
842 |
|
843 |
Comments can be included in some HTTP header fields by surrounding the |
844 |
comment text with parentheses. Comments are only allowed in fields |
845 |
containing "comment" as part of their field value definition. In all |
846 |
other fields, parentheses are considered part of the field value. |
847 |
|
848 |
comment = "(" *( ctext | comment ) ")" |
849 |
ctext = <any TEXT excluding "(" and ")"> |
850 |
|
851 |
A string of text is parsed as a single word if it is quoted using |
852 |
double-quote marks. |
853 |
|
854 |
quoted-string = ( <"> *(qdtext) <"> ) |
855 |
|
856 |
qdtext = <any TEXT except <">> |
857 |
|
858 |
The backslash character ("\") may be used as a single-character quoting |
859 |
mechanism only within quoted-string and comment constructs. |
860 |
|
861 |
quoted-pair = "\" CHAR |
862 |
|
863 |
|
864 |
3 Protocol Parameters |
865 |
|
866 |
|
867 |
3.1 HTTP Version |
868 |
|
869 |
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of |
870 |
the protocol. The protocol versioning policy is intended to allow the |
871 |
sender to indicate the format of a message and its capacity for |
872 |
understanding further HTTP communication, rather than the features |
873 |
obtained via that communication. No change is made to the version number |
874 |
for the addition of message components which do not affect communication |
875 |
behavior or which only add to extensible field values. The <minor> |
876 |
number is incremented when the changes made to the protocol add features |
877 |
which do not change the general message parsing algorithm, but which may |
878 |
add to the message semantics and imply additional capabilities of the |
879 |
sender. The <major> number is incremented when the format of a message |
880 |
within the protocol is changed. |
881 |
|
882 |
The version of an HTTP message is indicated by an HTTP-Version field in |
883 |
the first line of the message. |
884 |
|
885 |
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |
886 |
|
887 |
Note that the major and minor numbers MUST be treated as separate |
888 |
integers and that each may be incremented higher than a single digit. |
889 |
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower |
890 |
than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT |
891 |
be sent. |
892 |
|
893 |
|
894 |
|
895 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 16] |
896 |
|
897 |
|
898 |
|
899 |
|
900 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
901 |
|
902 |
|
903 |
Applications sending Request or Response messages, as defined by this |
904 |
specification, MUST include an HTTP-Version of "HTTP/1.1". Use of this |
905 |
version number indicates that the sending application is at least |
906 |
conditionally compliant with this specification. |
907 |
|
908 |
The HTTP version of an application is the highest HTTP version for which |
909 |
the application is at least conditionally compliant. |
910 |
|
911 |
Proxy and gateway applications must be careful when forwarding messages |
912 |
in protocol versions different from that of the application. Since the |
913 |
protocol version indicates the protocol capability of the sender, a |
914 |
proxy/gateway MUST never send a message with a version indicator which |
915 |
is greater than its actual version; if a higher version request is |
916 |
received, the proxy/gateway MUST either downgrade the request version, |
917 |
respond with an error, or switch to tunnel behavior. Requests with a |
918 |
version lower than that of the proxy/gateway's version MAY be upgraded |
919 |
before being forwarded; the proxy/gateway's response to that request |
920 |
MUST be in the same major version as the request. |
921 |
|
922 |
Note: Converting between versions of HTTP may involve modification |
923 |
of header fields required or forbidden by the versions involved. |
924 |
|
925 |
|
926 |
3.2 Uniform Resource Identifiers |
927 |
|
928 |
URIs have been known by many names: WWW addresses, Universal Document |
929 |
Identifiers, Universal Resource Identifiers , and finally the |
930 |
combination of Uniform Resource Locators (URL) and Names (URN) . As far |
931 |
as HTTP is concerned, Uniform Resource Identifiers are simply formatted |
932 |
strings which identify--via name, location, or any other characteristic- |
933 |
-a resource. |
934 |
|
935 |
|
936 |
3.2.1 General Syntax |
937 |
|
938 |
URIs in HTTP can be represented in absolute form or relative to some |
939 |
known base URI , depending upon the context of their use. The two forms |
940 |
are differentiated by the fact that absolute URIs always begin with a |
941 |
scheme name followed by a colon. |
942 |
|
943 |
URI = ( absoluteURI | relativeURI ) [ "#" fragment ] |
944 |
|
945 |
absoluteURI = scheme ":" *( uchar | reserved ) |
946 |
|
947 |
relativeURI = net_path | abs_path | rel_path |
948 |
|
949 |
net_path = "//" net_loc [ abs_path ] |
950 |
abs_path = "/" rel_path |
951 |
rel_path = [ path ] [ ";" params ] [ "?" query ] |
952 |
|
953 |
|
954 |
|
955 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 17] |
956 |
|
957 |
|
958 |
|
959 |
|
960 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
961 |
|
962 |
|
963 |
path = fsegment *( "/" segment ) |
964 |
fsegment = 1*pchar |
965 |
segment = *pchar |
966 |
|
967 |
params = param *( ";" param ) |
968 |
param = *( pchar | "/" ) |
969 |
|
970 |
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) |
971 |
net_loc = *( pchar | ";" | "?" ) |
972 |
query = *( uchar | reserved ) |
973 |
fragment = *( uchar | reserved ) |
974 |
|
975 |
pchar = uchar | ":" | "@" | "&" | "=" | "+" |
976 |
uchar = unreserved | escape |
977 |
unreserved = ALPHA | DIGIT | safe | extra | national |
978 |
|
979 |
escape = "%" HEX HEX |
980 |
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
981 |
extra = "!" | "*" | "'" | "(" | ")" | "," |
982 |
safe = "$" | "-" | "_" | "." |
983 |
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" |
984 |
national = <any OCTET excluding ALPHA, DIGIT, |
985 |
reserved, extra, safe, and unsafe> |
986 |
|
987 |
For definitive information on URL syntax and semantics, see RFC 1738 [4] |
988 |
and RFC 1808 [11]. The BNF above includes national characters not |
989 |
allowed in valid URLs as specified by RFC 1738, since HTTP servers are |
990 |
not restricted in the set of unreserved characters allowed to represent |
991 |
the rel_path part of addresses, and HTTP proxies may receive requests |
992 |
for URIs not defined by RFC 1738. |
993 |
|
994 |
The HTTP protocol does not place any a priori limit on the length of a |
995 |
URI. Servers MUST be able to handle the URI of any resource they serve, |
996 |
and SHOULD be able to handle URIs of unbounded length if they provide |
997 |
GET-based forms that could generate such URIs. A server SHOULD return |
998 |
414 (Request-URI Too Long) status if a URI is longer than the server can |
999 |
handle (see section 10.4.15). |
1000 |
|
1001 |
Note: Servers should be cautious about depending on URI lengths |
1002 |
above 255 bytes, because some older client or proxy implementations |
1003 |
may not properly support these lengths. |
1004 |
|
1005 |
|
1006 |
3.2.2 http URL |
1007 |
|
1008 |
The "http" scheme is used to locate network resources via the HTTP |
1009 |
protocol. This section defines the scheme-specific syntax and semantics |
1010 |
for http URLs. |
1011 |
|
1012 |
http_URL = "http:" "//" host [ ":" port ] [ abs_path ] |
1013 |
|
1014 |
|
1015 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 18] |
1016 |
|
1017 |
|
1018 |
|
1019 |
|
1020 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1021 |
|
1022 |
|
1023 |
host = <A legal Internet host domain name |
1024 |
or IP address (in dotted-decimal form), |
1025 |
as defined by Section 2.1 of RFC 1123> |
1026 |
|
1027 |
port = *DIGIT |
1028 |
|
1029 |
If the port is empty or not given, port 80 is assumed. The semantics are |
1030 |
that the identified resource is located at the server listening for TCP |
1031 |
connections on that port of that host, and the Request-URI for the |
1032 |
resource is abs_path. The use of IP addresses in URL's SHOULD be avoided |
1033 |
whenever possible (see RFC 1900 [24]). If the abs_path is not present in |
1034 |
the URL, it MUST be given as "/" when used as a Request-URI for a |
1035 |
resource (section 5.1.2). |
1036 |
|
1037 |
|
1038 |
3.2.3 URI Comparison |
1039 |
|
1040 |
When comparing two URIs to decide if they match or not, a client SHOULD |
1041 |
use a case-sensitive octet-by-octet comparison of the entire URIs, with |
1042 |
these exceptions: |
1043 |
|
1044 |
. A port that is empty or not given is equivalent to the default port |
1045 |
for that URI; |
1046 |
. Comparisons of host names MUST be case-insensitive; |
1047 |
. Comparisons of scheme names MUST be case-insensitive; |
1048 |
. An empty abs_path is equivalent to an abs_path of "/". |
1049 |
Characters other than those in the "reserved" and "unsafe" sets (see |
1050 |
section 3.2) are equivalent to their ""%" HEX HEX" encodings. |
1051 |
|
1052 |
For example, the following three URIs are equivalent: |
1053 |
|
1054 |
http://abc.com:80/~smith/home.html |
1055 |
http://ABC.com/%7Esmith/home.html |
1056 |
http://ABC.com:/%7esmith/home.html |
1057 |
|
1058 |
|
1059 |
3.3 Date/Time Formats |
1060 |
|
1061 |
|
1062 |
3.3.1 Full Date |
1063 |
|
1064 |
HTTP applications have historically allowed three different formats for |
1065 |
the representation of date/time stamps: |
1066 |
|
1067 |
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |
1068 |
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 |
1069 |
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
1070 |
|
1071 |
The first format is preferred as an Internet standard and represents a |
1072 |
fixed-length subset of that defined by RFC 1123 (an update to RFC 822 |
1073 |
). The second format is in common use, but is based on the obsolete RFC |
1074 |
|
1075 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 19] |
1076 |
|
1077 |
|
1078 |
|
1079 |
|
1080 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1081 |
|
1082 |
|
1083 |
850 date format and lacks a four-digit year. HTTP/1.1 clients and |
1084 |
servers that parse the date value MUST accept all three formats (for |
1085 |
compatibility with HTTP/1.0), though they MUST only generate the RFC |
1086 |
1123 format for representing HTTP-date values in header fields. |
1087 |
|
1088 |
Note: Recipients of date values are encouraged to be robust in |
1089 |
accepting date values that may have been sent by non-HTTP |
1090 |
applications, as is sometimes the case when retrieving or posting |
1091 |
messages via proxies/gateways to SMTP or NNTP. |
1092 |
|
1093 |
All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
1094 |
(GMT), without exception. This is indicated in the first two formats by |
1095 |
the inclusion of "GMT" as the three-letter abbreviation for time zone, |
1096 |
and MUST be assumed when reading the asctime format. |
1097 |
|
1098 |
HTTP-date = rfc1123-date | rfc850-date | asctime-date |
1099 |
|
1100 |
rfc1123-date = wkday "," SP date1 SP time SP "GMT" |
1101 |
rfc850-date = weekday "," SP date2 SP time SP "GMT" |
1102 |
asctime-date = wkday SP date3 SP time SP 4DIGIT |
1103 |
|
1104 |
date1 = 2DIGIT SP month SP 4DIGIT |
1105 |
; day month year (e.g., 02 Jun 1982) |
1106 |
date2 = 2DIGIT "-" month "-" 2DIGIT |
1107 |
; day-month-year (e.g., 02-Jun-82) |
1108 |
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |
1109 |
; month day (e.g., Jun 2) |
1110 |
|
1111 |
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
1112 |
; 00:00:00 - 23:59:59 |
1113 |
|
1114 |
wkday = "Mon" | "Tue" | "Wed" |
1115 |
| "Thu" | "Fri" | "Sat" | "Sun" |
1116 |
|
1117 |
weekday = "Monday" | "Tuesday" | "Wednesday" |
1118 |
| "Thursday" | "Friday" | "Saturday" | "Sunday" |
1119 |
|
1120 |
month = "Jan" | "Feb" | "Mar" | "Apr" |
1121 |
| "May" | "Jun" | "Jul" | "Aug" |
1122 |
| "Sep" | "Oct" | "Nov" | "Dec" |
1123 |
|
1124 |
Note: HTTP requirements for the date/time stamp format apply only |
1125 |
to their usage within the protocol stream. Clients and servers are |
1126 |
not required to use these formats for user presentation, request |
1127 |
logging, etc. |
1128 |
|
1129 |
|
1130 |
|
1131 |
|
1132 |
|
1133 |
|
1134 |
|
1135 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 20] |
1136 |
|
1137 |
|
1138 |
|
1139 |
|
1140 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1141 |
|
1142 |
|
1143 |
3.3.2 Delta Seconds |
1144 |
|
1145 |
Some HTTP header fields allow a time value to be specified as an integer |
1146 |
number of seconds, represented in decimal, after the time that the |
1147 |
message was received. |
1148 |
|
1149 |
delta-seconds = 1*DIGIT |
1150 |
|
1151 |
|
1152 |
3.4 Character Sets |
1153 |
|
1154 |
HTTP uses the same definition of the term "character set" as that |
1155 |
described for MIME: |
1156 |
|
1157 |
The term "character set" is used in this document to refer to a |
1158 |
method used with one or more tables to convert a sequence of octets |
1159 |
into a sequence of characters. Note that unconditional conversion |
1160 |
in the other direction is not required, in that not all characters |
1161 |
may be available in a given character set and a character set may |
1162 |
provide more than one sequence of octets to represent a particular |
1163 |
character. This definition is intended to allow various kinds of |
1164 |
character encodings, from simple single-table mappings such as US- |
1165 |
ASCII to complex table switching methods such as those that use ISO |
1166 |
2022's techniques. However, the definition associated with a MIME |
1167 |
character set name MUST fully specify the mapping to be performed |
1168 |
from octets to characters. In particular, use of external profiling |
1169 |
information to determine the exact mapping is not permitted. |
1170 |
|
1171 |
Note: This use of the term "character set" is more commonly |
1172 |
referred to as a "character encoding." However, since HTTP and MIME |
1173 |
share the same registry, it is important that the terminology also |
1174 |
be shared. |
1175 |
|
1176 |
HTTP character sets are identified by case-insensitive tokens. The |
1177 |
complete set of tokens is defined by the IANA Character Set registry |
1178 |
[19]. |
1179 |
|
1180 |
charset = token |
1181 |
|
1182 |
Although HTTP allows an arbitrary token to be used as a charset value, |
1183 |
any token that has a predefined value within the IANA Character Set |
1184 |
registry MUST represent the character set defined by that registry. |
1185 |
Applications SHOULD limit their use of character sets to those defined |
1186 |
by the IANA registry. |
1187 |
|
1188 |
|
1189 |
3.5 Content Codings |
1190 |
|
1191 |
Content coding values indicate an encoding transformation that has been |
1192 |
or can be applied to an entity. Content codings are primarily used to |
1193 |
allow a document to be compressed or otherwise usefully transformed |
1194 |
|
1195 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 21] |
1196 |
|
1197 |
|
1198 |
|
1199 |
|
1200 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1201 |
|
1202 |
|
1203 |
without losing the identity of its underlying media type and without |
1204 |
loss of information. Frequently, the entity is stored in coded form, |
1205 |
transmitted directly, and only decoded by the recipient. |
1206 |
|
1207 |
content-coding = token |
1208 |
|
1209 |
All content-coding values are case-insensitive. HTTP/1.1 uses content- |
1210 |
coding values in the Accept-Encoding (section 14.3) and Content-Encoding |
1211 |
(section 14.12) header fields. Although the value describes the content- |
1212 |
coding, what is more important is that it indicates what decoding |
1213 |
mechanism will be required to remove the encoding. |
1214 |
|
1215 |
The Internet Assigned Numbers Authority (IANA) acts as a registry for |
1216 |
content-coding value tokens. Initially, the registry contains the |
1217 |
following tokens: |
1218 |
|
1219 |
|
1220 |
gzip An encoding format produced by the file compression program "gzip" |
1221 |
(GNU zip) as described in RFC 1952 [25]. This format is a Lempel- |
1222 |
Ziv coding (LZ77) with a 32 bit CRC. |
1223 |
|
1224 |
|
1225 |
compress |
1226 |
The encoding format produced by the common UNIX file compression |
1227 |
program "compress". This format is an adaptive Lempel-Ziv-Welch |
1228 |
coding (LZW). |
1229 |
|
1230 |
Note: Use of program names for the identification of encoding |
1231 |
formats is not desirable and should be discouraged for future |
1232 |
encodings. Their use here is representative of historical practice, |
1233 |
not good design. For compatibility with previous implementations of |
1234 |
HTTP, applications should consider "x-gzip" and "x-compress" to be |
1235 |
equivalent to "gzip" and "compress" respectively. |
1236 |
|
1237 |
deflate The "zlib" format defined in RFC 1950[31] in combination with |
1238 |
the "deflate" compression mechanism described in RFC 1951[29]. |
1239 |
|
1240 |
New content-coding value tokens should be registered; to allow |
1241 |
interoperability between clients and servers, specifications of the |
1242 |
content coding algorithms needed to implement a new value should be |
1243 |
publicly available and adequate for independent implementation, and |
1244 |
conform to the purpose of content coding defined in this section. |
1245 |
|
1246 |
|
1247 |
3.6 Transfer Codings |
1248 |
|
1249 |
Transfer coding values are used to indicate an encoding transformation |
1250 |
that has been, can be, or may need to be applied to an entity-body in |
1251 |
order to ensure "safe transport" through the network. This differs from |
1252 |
a content coding in that the transfer coding is a property of the |
1253 |
message, not of the original entity. |
1254 |
|
1255 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 22] |
1256 |
|
1257 |
|
1258 |
|
1259 |
|
1260 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1261 |
|
1262 |
|
1263 |
transfer-coding = "chunked" | transfer-extension |
1264 |
|
1265 |
transfer-extension = token |
1266 |
|
1267 |
All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer |
1268 |
coding values in the Transfer-Encoding header field (section 14.40). |
1269 |
|
1270 |
Transfer codings are analogous to the Content-Transfer-Encoding values |
1271 |
of MIME , which were designed to enable safe transport of binary data |
1272 |
over a 7-bit transport service. However, safe transport has a different |
1273 |
focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe |
1274 |
characteristic of message-bodies is the difficulty in determining the |
1275 |
exact body length (section 7.2.2), or the desire to encrypt data over a |
1276 |
shared transport. |
1277 |
|
1278 |
The chunked encoding modifies the body of a message in order to transfer |
1279 |
it as a series of chunks, each with its own size indicator, followed by |
1280 |
an optional footer containing entity-header fields. This allows |
1281 |
dynamically-produced content to be transferred along with the |
1282 |
information necessary for the recipient to verify that it has received |
1283 |
the full message. |
1284 |
|
1285 |
Chunked-Body = *chunk |
1286 |
"0" CRLF |
1287 |
footer |
1288 |
CRLF |
1289 |
|
1290 |
chunk = chunk-size [ chunk-ext ] CRLF |
1291 |
chunk-data CRLF |
1292 |
|
1293 |
hex-no-zero = <HEX excluding "0"> |
1294 |
|
1295 |
chunk-size = hex-no-zero *HEX |
1296 |
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) |
1297 |
chunk-ext-name = token |
1298 |
chunk-ext-val = token | quoted-string |
1299 |
chunk-data = chunk-size(OCTET) |
1300 |
|
1301 |
footer = *entity-header |
1302 |
|
1303 |
The chunked encoding is ended by a zero-sized chunk followed by the |
1304 |
footer, which is terminated by an empty line. The purpose of the footer |
1305 |
is to provide an efficient way to supply information about an entity |
1306 |
that is generated dynamically; applications MUST NOT send header fields |
1307 |
in the footer which are not explicitly defined as being appropriate for |
1308 |
the footer, such as Content-MD5 or future extensions to HTTP for digital |
1309 |
signatures or other facilities. |
1310 |
|
1311 |
An example process for decoding a Chunked-Body is presented in appendix |
1312 |
19.4.6. |
1313 |
|
1314 |
|
1315 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 23] |
1316 |
|
1317 |
|
1318 |
|
1319 |
|
1320 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1321 |
|
1322 |
|
1323 |
All HTTP/1.1 applications MUST be able to receive and decode the |
1324 |
"chunked" transfer coding , and MUST ignore transfer coding extensions |
1325 |
they do not understand. A server which receives an entity-body with a |
1326 |
transfer-coding it does not understand SHOULD return 501 |
1327 |
(Unimplemented), and close the connection. A server MUST NOT send |
1328 |
transfer-codings to an HTTP/1.0 client. |
1329 |
|
1330 |
|
1331 |
3.7 Media Types |
1332 |
|
1333 |
HTTP uses Internet Media Types in the Content-Type (section 14.18) and |
1334 |
Accept (section 14.1) header fields in order to provide open and |
1335 |
extensible data typing and type negotiation. |
1336 |
|
1337 |
media-type = type "/" subtype *( ";" parameter ) |
1338 |
type = token |
1339 |
subtype = token |
1340 |
|
1341 |
Parameters may follow the type/subtype in the form of attribute/value |
1342 |
pairs. |
1343 |
|
1344 |
parameter = attribute "=" value |
1345 |
attribute = token |
1346 |
value = token | quoted-string |
1347 |
|
1348 |
The type, subtype, and parameter attribute names are case-insensitive. |
1349 |
Parameter values may or may not be case-sensitive, depending on the |
1350 |
semantics of the parameter name. Linear white space (LWS) MUST NOT be |
1351 |
used between the type and subtype, nor between an attribute and its |
1352 |
value. User agents that recognize the media-type MUST process (or |
1353 |
arrange to be processed by any external applications used to process |
1354 |
that type/subtype by the user agent) the parameters for that MIME type |
1355 |
as described by that type/subtype definition to the and inform the user |
1356 |
of any problems discovered. |
1357 |
|
1358 |
Note: some older HTTP applications do not recognize media type |
1359 |
parameters. When sending data to older HTTP applications, |
1360 |
implementations should only use media type parameters when they are |
1361 |
required by that type/subtype definition. |
1362 |
|
1363 |
Media-type values are registered with the Internet Assigned Number |
1364 |
Authority (IANA). The media type registration process is outlined in RFC |
1365 |
1590 [17]. Use of non-registered media types is discouraged. |
1366 |
|
1367 |
|
1368 |
3.7.1 Canonicalization and Text Defaults |
1369 |
|
1370 |
Internet media types are registered with a canonical form. In general, |
1371 |
an entity-body transferred via HTTP messages MUST be represented in the |
1372 |
appropriate canonical form prior to its transmission; the exception is |
1373 |
"text" types, as defined in the next paragraph. |
1374 |
|
1375 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 24] |
1376 |
|
1377 |
|
1378 |
|
1379 |
|
1380 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1381 |
|
1382 |
|
1383 |
When in canonical form, media subtypes of the "text" type use CRLF as |
1384 |
the text line break. HTTP relaxes this requirement and allows the |
1385 |
transport of text media with plain CR or LF alone representing a line |
1386 |
break when it is done consistently for an entire entity-body. HTTP |
1387 |
applications MUST accept CRLF, bare CR, and bare LF as being |
1388 |
representative of a line break in text media received via HTTP. In |
1389 |
addition, if the text is represented in a character set that does not |
1390 |
use octets 13 and 10 for CR and LF respectively, as is the case for some |
1391 |
multi-byte character sets, HTTP allows the use of whatever octet |
1392 |
sequences are defined by that character set to represent the equivalent |
1393 |
of CR and LF for line breaks. This flexibility regarding line breaks |
1394 |
applies only to text media in the entity-body; a bare CR or LF MUST NOT |
1395 |
be substituted for CRLF within any of the HTTP control structures (such |
1396 |
as header fields and multipart boundaries). |
1397 |
|
1398 |
If an entity-body is encoded with a Content-Encoding, the underlying |
1399 |
data MUST be in a form defined above prior to being encoded. |
1400 |
|
1401 |
The "charset" parameter is used with some media types to define the |
1402 |
character set (section 3.4) of the data. When no explicit charset |
1403 |
parameter is provided by the sender, media subtypes of the "text" type |
1404 |
are defined to have a default charset value of "ISO-8859-1" when |
1405 |
received via HTTP. Data in character sets other than "ISO-8859-1" or its |
1406 |
subsets MUST be labeled with an appropriate charset value. |
1407 |
|
1408 |
|
1409 |
3.7.2 Multipart Types |
1410 |
|
1411 |
MIME provides for a number of "multipart" types -- encapsulations of one |
1412 |
or more entities within a single message-body. All multipart types share |
1413 |
a common syntax, as defined in section 7.2.1 of RFC 1521 [7], and MUST |
1414 |
include a boundary parameter as part of the media type value. The |
1415 |
message body is itself a protocol element and MUST therefore use only |
1416 |
CRLF to represent line breaks between body-parts. Unlike in RFC 1521, |
1417 |
the epilogue of any multipart message MUST be empty; HTTP applications |
1418 |
MUST NOT transmit the epilogue (even if the original multipart contains |
1419 |
an epilogue). |
1420 |
|
1421 |
In HTTP, multipart body-parts MAY contain header fields which are |
1422 |
significant to the meaning of that part. A Content-Location header field |
1423 |
(section 14.15) SHOULD be included in the body-part of each enclosed |
1424 |
entity that can be identified by a URL. |
1425 |
|
1426 |
In general, an HTTP user agent SHOULD follow the same or similar |
1427 |
behavior as a MIME user agent would upon receipt of a multipart type. If |
1428 |
an application receives an unrecognized multipart subtype, the |
1429 |
application MUST treat it as being equivalent to "multipart/mixed". |
1430 |
|
1431 |
Note: The "multipart/form-data" type has been specifically defined |
1432 |
for carrying form data suitable for processing via the POST request |
1433 |
method, as described in RFC 1867 [15]. |
1434 |
|
1435 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 25] |
1436 |
|
1437 |
|
1438 |
|
1439 |
|
1440 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1441 |
|
1442 |
|
1443 |
3.8 Product Tokens |
1444 |
|
1445 |
Product tokens are used to allow communicating applications to identify |
1446 |
themselves by software name and version. Most fields using product |
1447 |
tokens also allow sub-products which form a significant part of the |
1448 |
application to be listed, separated by whitespace. By convention, the |
1449 |
products are listed in order of their significance for identifying the |
1450 |
application. |
1451 |
|
1452 |
product = token ["/" product-version] |
1453 |
product-version = token |
1454 |
|
1455 |
Examples: |
1456 |
|
1457 |
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
1458 |
Server: Apache/0.8.4 |
1459 |
|
1460 |
Product tokens should be short and to the point -- use of them for |
1461 |
advertising or other non-essential information is explicitly forbidden. |
1462 |
Although any token character may appear in a product-version, this token |
1463 |
SHOULD only be used for a version identifier (i.e., successive versions |
1464 |
of the same product SHOULD only differ in the product-version portion of |
1465 |
the product value). |
1466 |
|
1467 |
|
1468 |
3.9 Quality Values |
1469 |
|
1470 |
HTTP content negotiation (section 12) uses short "floating point" |
1471 |
numbers to indicate the relative importance ("weight") of various |
1472 |
negotiable parameters. A weight is normalized to a real number in the |
1473 |
range 0 through 1, where 0 is the minimum and 1 the maximum value. |
1474 |
HTTP/1.1 applications MUST NOT generate more than three digits after the |
1475 |
decimal point. User configuration of these values SHOULD also be limited |
1476 |
in this fashion. |
1477 |
|
1478 |
qvalue = ( "0" [ "." 0*3DIGIT ] ) |
1479 |
| ( "1" [ "." 0*3("0") ] ) |
1480 |
|
1481 |
"Quality values" is a misnomer, since these values merely represent |
1482 |
relative degradation in desired quality. |
1483 |
|
1484 |
|
1485 |
3.10 Language Tags |
1486 |
|
1487 |
A language tag identifies a natural language spoken, written, or |
1488 |
otherwise conveyed by human beings for communication of information to |
1489 |
other human beings. Computer languages are explicitly excluded. HTTP |
1490 |
uses language tags within the Accept-Language and Content-Language |
1491 |
fields. |
1492 |
|
1493 |
|
1494 |
|
1495 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 26] |
1496 |
|
1497 |
|
1498 |
|
1499 |
|
1500 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1501 |
|
1502 |
|
1503 |
The syntax and registry of HTTP language tags is the same as that |
1504 |
defined by RFC 1766 [1]. In summary, a language tag is composed of 1 or |
1505 |
more parts: A primary language tag and a possibly empty series of |
1506 |
subtags: |
1507 |
|
1508 |
language-tag = primary-tag *( "-" subtag ) |
1509 |
|
1510 |
primary-tag = 1*8ALPHA |
1511 |
subtag = 1*8ALPHA |
1512 |
|
1513 |
Whitespace is not allowed within the tag and all tags are case- |
1514 |
insensitive. The name space of language tags is administered by the |
1515 |
IANA. Example tags include: |
1516 |
|
1517 |
en, en-US, en-cockney, i-cherokee, x-pig-latin |
1518 |
|
1519 |
where any two-letter primary-tag is an ISO 639 language abbreviation and |
1520 |
any two-letter initial subtag is an ISO 3166 country code. (The last |
1521 |
three tags above are not registered tags; all but the last are examples |
1522 |
of tags which could be registered in future.) |
1523 |
|
1524 |
|
1525 |
3.11 Entity Tags |
1526 |
|
1527 |
Entity tags are used for comparing two or more entities from the same |
1528 |
requested resource. HTTP/1.1 uses entity tags in the ETag (section |
1529 |
14.20), If-Match (section 14.25), If-None-Match (section 14.26), and If- |
1530 |
Range (section 14.27) header fields. The definition of how they are used |
1531 |
and compared as cache validators is in section 13.3.3. An entity tag |
1532 |
consists of an opaque quoted string, possibly prefixed by a weakness |
1533 |
indicator. |
1534 |
|
1535 |
entity-tag = [ weak ] opaque-tag |
1536 |
|
1537 |
weak = "W/" |
1538 |
opaque-tag = quoted-string |
1539 |
|
1540 |
A "strong entity tag" may be shared by two entities of a resource only |
1541 |
if they are equivalent by octet equality. |
1542 |
|
1543 |
A "weak entity tag," indicated by the "W/" prefix, may be shared by two |
1544 |
entities of a resource only if the entities are equivalent and could be |
1545 |
substituted for each other with no significant change in semantics. A |
1546 |
weak entity tag can only be used for weak comparison. |
1547 |
|
1548 |
An entity tag MUST be unique across all versions of all entities |
1549 |
associated with a particular resource. A given entity tag value may be |
1550 |
used for entities obtained by requests on different URIs without |
1551 |
implying anything about the equivalence of those entities. |
1552 |
|
1553 |
|
1554 |
|
1555 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 27] |
1556 |
|
1557 |
|
1558 |
|
1559 |
|
1560 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1561 |
|
1562 |
|
1563 |
3.12 Range Units |
1564 |
|
1565 |
HTTP/1.1 allows a client to request that only part (a range of) the |
1566 |
response entity be included within the response. HTTP/1.1 uses range |
1567 |
units in the Range (section 14.36), If-Range (section 14.27), and |
1568 |
Content-Range (section 14.17) header fields. An entity may be broken |
1569 |
down into subranges according to various structural units. |
1570 |
|
1571 |
range-unit = bytes-unit | other-range-unit |
1572 |
|
1573 |
bytes-unit = "bytes" |
1574 |
other-range-unit = token |
1575 |
|
1576 |
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 |
1577 |
implementations may ignore ranges specified using other units. HTTP/1.1 |
1578 |
has been designed to allow implementations of applications that do not |
1579 |
depend on knowledge of ranges. |
1580 |
|
1581 |
|
1582 |
4 HTTP Message |
1583 |
|
1584 |
|
1585 |
4.1 Message Types |
1586 |
|
1587 |
HTTP messages consist of requests from client to server and responses |
1588 |
from server to client. |
1589 |
|
1590 |
HTTP-message = Request | Response ; HTTP/1.1 messages |
1591 |
|
1592 |
Request (section 5) and Response (section 6) messages use the generic |
1593 |
message format of RFC 822 for transferring entities (the payload of the |
1594 |
message). Both types of message consist of a start-line, one or more |
1595 |
header fields (also known as "headers"), an empty line (i.e., a line |
1596 |
with nothing preceding the CRLF) indicating the end of the header |
1597 |
fields, and an optional message-body. |
1598 |
|
1599 |
generic-message = start-line |
1600 |
*message-header |
1601 |
CRLF |
1602 |
[ message-body ] |
1603 |
|
1604 |
start-line = Request-Line | Status-Line |
1605 |
|
1606 |
In the interest of robustness, servers SHOULD ignore any empty line(s) |
1607 |
received where a Request-Line is expected. In other words, if the server |
1608 |
is reading the protocol stream at the beginning of a message and |
1609 |
receives a CRLF first, it should ignore the CRLF. |
1610 |
|
1611 |
Note: certain buggy HTTP/1.0 client implementations and/or scripts |
1612 |
generated extra CRLF's before/after a POST request. To restate what |
1613 |
|
1614 |
|
1615 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 28] |
1616 |
|
1617 |
|
1618 |
|
1619 |
|
1620 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1621 |
|
1622 |
|
1623 |
is explicitly forbidden by the BNF, an HTTP/1.1 client must not |
1624 |
preface or follow a request with an extra CRLF. |
1625 |
|
1626 |
|
1627 |
4.2 Message Headers |
1628 |
|
1629 |
HTTP header fields, which include general-header (section 4.5), request- |
1630 |
header (section 5.3), response-header (section 6.2), and entity-header |
1631 |
(section 7.1) fields, follow the same generic format as that given in |
1632 |
Section 3.1 of RFC 822 [9]. Each header field consists of a name |
1633 |
followed by a colon (":") and the field value. Field names are case- |
1634 |
insensitive. The field value may be preceded by any amount of LWS, |
1635 |
though a single SP is preferred. Header fields can be extended over |
1636 |
multiple lines by preceding each extra line with at least one SP or HT. |
1637 |
Applications SHOULD follow "common form" when generating HTTP |
1638 |
constructs, since there might exist some implementations that fail to |
1639 |
accept anything beyond the common forms. |
1640 |
|
1641 |
message-header = field-name ":" [ field-value ] CRLF |
1642 |
|
1643 |
field-name = token |
1644 |
field-value = *( field-content | LWS ) |
1645 |
|
1646 |
field-content = <the OCTETs making up the field-value |
1647 |
and consisting of either *TEXT or combinations |
1648 |
of token, tspecials, and quoted-string> |
1649 |
|
1650 |
The order in which header fields with differing field names are received |
1651 |
is not significant. However, it is "good practice" to send general- |
1652 |
header fields first, followed by request-header or response-header |
1653 |
fields, and ending with the entity-header fields. |
1654 |
|
1655 |
Multiple message-header fields with the same field-name may be present |
1656 |
in a message if and only if the entire field-value for that header field |
1657 |
is defined as a comma-separated list [i.e., #(values)]. It MUST be |
1658 |
possible to combine the multiple header fields into one "field-name: |
1659 |
field-value" pair, without changing the semantics of the message, by |
1660 |
appending each subsequent field-value to the first, each separated by a |
1661 |
comma. The order in which header fields with the same field-name are |
1662 |
received is therefore significant to the interpretation of the combined |
1663 |
field value, and thus a proxy MUST NOT change the order of these field |
1664 |
values when a message is forwarded. |
1665 |
|
1666 |
|
1667 |
4.3 Message Body |
1668 |
|
1669 |
The message-body (if any) of an HTTP message is used to carry the |
1670 |
entity-body associated with the request or response. The message-body |
1671 |
differs from the entity-body only when a transfer coding has been |
1672 |
applied, as indicated by the Transfer-Encoding header field (section |
1673 |
14.40). |
1674 |
|
1675 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 29] |
1676 |
|
1677 |
|
1678 |
|
1679 |
|
1680 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1681 |
|
1682 |
|
1683 |
message-body = entity-body |
1684 |
| <entity-body encoded as per Transfer-Encoding> |
1685 |
|
1686 |
Transfer-Encoding MUST be used to indicate any transfer codings applied |
1687 |
by an application to ensure safe and proper transfer of the message. |
1688 |
Transfer-Encoding is a property of the message, not of the entity, and |
1689 |
thus can be added or removed by any application along the |
1690 |
request/response chain. |
1691 |
|
1692 |
The rules for when a message-body is allowed in a message differ for |
1693 |
requests and responses. |
1694 |
|
1695 |
The presence of a message-body in a request is signaled by the inclusion |
1696 |
of a Content-Length or Transfer-Encoding header field in the request's |
1697 |
message-headers. A message-body MAY be included in a request only when |
1698 |
the request method (section 5.1.1) allows an entity-body. |
1699 |
|
1700 |
For response messages, whether or not a message-body is included with a |
1701 |
message is dependent on both the request method and the response status |
1702 |
code (section 6.1.1). All responses to the HEAD request method MUST NOT |
1703 |
include a message-body, even though the presence of entity-header fields |
1704 |
might lead one to believe they do. All 1xx (informational), 204 (no |
1705 |
content), and 304 (not modified) responses MUST NOT include a message- |
1706 |
body. All other responses do include a message-body, although it may be |
1707 |
of zero length. |
1708 |
|
1709 |
|
1710 |
4.4 Message Length |
1711 |
|
1712 |
When a message-body is included with a message, the length of that body |
1713 |
is determined by one of the following (in order of precedence): |
1714 |
|
1715 |
1. Any response message which MUST NOT include a message-body (such as |
1716 |
the 1xx, 204, and 304 responses and any response to a HEAD request) |
1717 |
is always terminated by the first empty line after the header fields, |
1718 |
regardless of the entity-header fields present in the message. |
1719 |
|
1720 |
2. If a Transfer-Encoding header field (section 14.40) is present and |
1721 |
indicates that the "chunked" transfer coding has been applied, then |
1722 |
the length is defined by the chunked encoding (section 3.6). |
1723 |
|
1724 |
3. If a Content-Length header field (section 14.14) is present, its |
1725 |
value in bytes represents the length of the message-body. |
1726 |
|
1727 |
4. If the message uses the MIME "multipart/byteranges" Content-Type, |
1728 |
which is self-delimiting, then that defines the length. This Content- |
1729 |
Type MUST NOT be used unless the sender knows that the recipient can |
1730 |
parse it; the presence in a request of a Range header with multiple |
1731 |
byte-range specifiers implies that the client can parse |
1732 |
multipart/byteranges responses. |
1733 |
|
1734 |
|
1735 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 30] |
1736 |
|
1737 |
|
1738 |
|
1739 |
|
1740 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1741 |
|
1742 |
|
1743 |
5. By the server closing the connection. (Closing the connection cannot |
1744 |
be used to indicate the end of a request body, since that would leave |
1745 |
no possibility for the server to send back a response.) |
1746 |
|
1747 |
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |
1748 |
containing a message-body MUST include a valid Content-Length header |
1749 |
field unless the server is known to be HTTP/1.1 compliant. If a request |
1750 |
contains a message-body and a Content-Length is not given, the server |
1751 |
SHOULD respond with 400 (bad request) if it cannot determine the length |
1752 |
of the message, or with 411 (length required) if it wishes to insist on |
1753 |
receiving a valid Content-Length. |
1754 |
|
1755 |
All HTTP/1.1 applications that receive entities MUST accept the |
1756 |
"chunked" transfer coding (section 3.6), thus allowing this mechanism to |
1757 |
be used for messages when the message length cannot be determined in |
1758 |
advance. |
1759 |
|
1760 |
Messages MUST NOT include both a Content-Length header field and the |
1761 |
"chunked" transfer coding. If both are received, the Content-Length MUST |
1762 |
be ignored. |
1763 |
|
1764 |
When a Content-Length is given in a message where a message-body is |
1765 |
allowed, its field value MUST exactly match the number of OCTETs in the |
1766 |
message-body. HTTP/1.1 user agents MUST notify the user when an invalid |
1767 |
length is received and detected. |
1768 |
|
1769 |
|
1770 |
4.5 General Header Fields |
1771 |
|
1772 |
There are a few header fields which have general applicability for both |
1773 |
request and response messages, but which do not apply to the entity |
1774 |
being transferred. These header fields apply only to the message being |
1775 |
transmitted. |
1776 |
|
1777 |
general-header = Cache-Control ; Section 14.9 |
1778 |
| Connection ; Section 14.10 |
1779 |
| Date ; Section 14.19 |
1780 |
| Pragma ; Section 14.32 |
1781 |
| Transfer-Encoding ; Section 14.40 |
1782 |
| Upgrade ; Section 14.41 |
1783 |
| Via ; Section 14.44 |
1784 |
|
1785 |
General-header field names can be extended reliably only in combination |
1786 |
with a change in the protocol version. However, new or experimental |
1787 |
header fields may be given the semantics of general header fields if all |
1788 |
parties in the communication recognize them to be general-header fields. |
1789 |
Unrecognized header fields are treated as entity-header fields. |
1790 |
|
1791 |
|
1792 |
|
1793 |
|
1794 |
|
1795 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 31] |
1796 |
|
1797 |
|
1798 |
|
1799 |
|
1800 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1801 |
|
1802 |
|
1803 |
5 Request |
1804 |
|
1805 |
A request message from a client to a server includes, within the first |
1806 |
line of that message, the method to be applied to the resource, the |
1807 |
identifier of the resource, and the protocol version in use. |
1808 |
|
1809 |
Request = Request-Line ; Section 5.1 |
1810 |
*( general-header ; Section 4.5 |
1811 |
| request-header ; Section 5.3 |
1812 |
| entity-header ) ; Section 7.1 |
1813 |
CRLF |
1814 |
[ message-body ] ; Section 7.2 |
1815 |
|
1816 |
|
1817 |
5.1 Request-Line |
1818 |
|
1819 |
The Request-Line begins with a method token, followed by the Request-URI |
1820 |
and the protocol version, and ending with CRLF. The elements are |
1821 |
separated by SP characters. No CR or LF are allowed except in the final |
1822 |
CRLF sequence. |
1823 |
|
1824 |
Request-Line = Method SP Request-URI SP HTTP-Version CRLF |
1825 |
|
1826 |
|
1827 |
5.1.1 Method |
1828 |
|
1829 |
The Method token indicates the method to be performed on the resource |
1830 |
identified by the Request-URI. The method is case-sensitive. |
1831 |
|
1832 |
Method = "OPTIONS" ; Section 9.1.1 |
1833 |
| "GET" ; Section 9.3 |
1834 |
| "HEAD" ; Section 9.4 |
1835 |
| "POST" ; Section 9.5 |
1836 |
| "PUT" ; Section 9.6 |
1837 |
| "DELETE" ; Section 9.7 |
1838 |
| "TRACE" ; Section 9.8 |
1839 |
| extension-method |
1840 |
|
1841 |
extension-method = token |
1842 |
|
1843 |
The list of methods acceptable by a plain resource can be specified in |
1844 |
an Allow header field (section 14.7). The return code of the response |
1845 |
always notifies the client whether a method is currently allowed on a |
1846 |
resource, as which methods are allowed can change dynamically. Servers |
1847 |
SHOULD return the status code 405 (Method Not Allowed) if the method is |
1848 |
known by the server but not allowed for the requested resource, and 501 |
1849 |
(Not Implemented) if the method is unrecognized or not implemented by |
1850 |
the server. The list of methods known by a server can be listed in a |
1851 |
Public response-header field (section 14.35). |
1852 |
|
1853 |
|
1854 |
|
1855 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 32] |
1856 |
|
1857 |
|
1858 |
|
1859 |
|
1860 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1861 |
|
1862 |
|
1863 |
The methods GET and HEAD MUST be supported by all general-purpose |
1864 |
servers. All other methods are optional; however, if the above methods |
1865 |
are implemented, they MUST be implemented with the same semantics as |
1866 |
those specified in section 9. |
1867 |
|
1868 |
|
1869 |
5.1.2 Request-URI |
1870 |
|
1871 |
The Request-URI is a Uniform Resource Identifier (section 3.2) and |
1872 |
identifies the resource upon which to apply the request. |
1873 |
|
1874 |
Request-URI = "*" | absoluteURI | abs_path |
1875 |
|
1876 |
The three options for Request-URI are dependent on the nature of the |
1877 |
request. The asterisk "*" means that the request does not apply to a |
1878 |
particular resource, but to the server itself, and is only allowed when |
1879 |
the method used does not necessarily apply to a resource. One example |
1880 |
would be |
1881 |
|
1882 |
OPTIONS * HTTP/1.1 |
1883 |
|
1884 |
The absoluteURI form is required when the request is being made to a |
1885 |
proxy. The proxy is requested to forward the request or service it from |
1886 |
a valid cache, and return the response. Note that the proxy MAY forward |
1887 |
the request on to another proxy or directly to the server specified by |
1888 |
the absoluteURI. In order to avoid request loops, a proxy MUST be able |
1889 |
to recognize all of its server names, including any aliases, local |
1890 |
variations, and the numeric IP address. An example Request-Line would |
1891 |
be: |
1892 |
|
1893 |
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 |
1894 |
|
1895 |
To allow for transition to absoluteURIs in all requests in future |
1896 |
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form |
1897 |
in requests, even though HTTP/1.1 clients will only generate them in |
1898 |
requests to proxies. |
1899 |
|
1900 |
The most common form of Request-URI is that used to identify a resource |
1901 |
on an origin server or gateway. In this case the absolute path of the |
1902 |
URI MUST be transmitted (see section 3.2.1, abs_path) as the Request- |
1903 |
URI, and the network location of the URI (net_loc) MUST be transmitted |
1904 |
in a Host header field. For example, a client wishing to retrieve the |
1905 |
resource above directly from the origin server would create a TCP |
1906 |
connection to port 80 of the host "www.w3.org" and send the lines: |
1907 |
|
1908 |
GET /pub/WWW/TheProject.html HTTP/1.1 |
1909 |
Host: www.w3.org |
1910 |
|
1911 |
followed by the remainder of the Request. Note that the absolute path |
1912 |
cannot be empty; if none is present in the original URI, it MUST be |
1913 |
given as "/" (the server root). |
1914 |
|
1915 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 33] |
1916 |
|
1917 |
|
1918 |
|
1919 |
|
1920 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1921 |
|
1922 |
|
1923 |
If a proxy receives a request without any path in the Request-URI and |
1924 |
the method specified is capable of supporting the asterisk form of |
1925 |
request, then the last proxy on the request chain MUST forward the |
1926 |
request with "*" as the final Request-URI. For example, the request |
1927 |
|
1928 |
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 |
1929 |
|
1930 |
would be forwarded by the proxy as |
1931 |
|
1932 |
OPTIONS * HTTP/1.1 |
1933 |
Host: www.ics.uci.edu:8001 |
1934 |
|
1935 |
after connecting to port 8001 of host "www.ics.uci.edu". |
1936 |
|
1937 |
The Request-URI is transmitted in the format specified in section 3.2.1. |
1938 |
The origin server MUST decode the Request-URI in order to properly |
1939 |
interpret the request. Servers SHOULD respond to invalid Request-URIs |
1940 |
with an appropriate status code. |
1941 |
|
1942 |
In requests that they forward, proxies MUST NOT rewrite the "abs_path" |
1943 |
part of a Request-URI in any way except as noted above to replace a null |
1944 |
abs_path with "*", no matter what the proxy does in its internal |
1945 |
implementation. |
1946 |
|
1947 |
Note: The "no rewrite" rule prevents the proxy from changing the |
1948 |
meaning of the request when the origin server is improperly using a |
1949 |
non-reserved URL character for a reserved purpose, since it is not |
1950 |
feasible to fix all CGI scripts (or script authors) use URI syntax |
1951 |
correctly. |
1952 |
|
1953 |
Implementers should be aware that some pre-HTTP/1.1 proxies have |
1954 |
been known to rewrite the Request-URI. |
1955 |
|
1956 |
|
1957 |
5.2 The Resource Identified by a Request |
1958 |
|
1959 |
HTTP/1.1 origin servers SHOULD be aware that the exact resource |
1960 |
identified by an Internet request is determined by examining both the |
1961 |
Request-URI and the Host header field. |
1962 |
|
1963 |
An origin server that does not allow resources to differ by the |
1964 |
requested host MAY ignore the Host header field value. (But see section |
1965 |
19.5.1 for other requirements on Host support in HTTP/1.1.) |
1966 |
|
1967 |
An origin server that does differentiate resources based on the host |
1968 |
requested (sometimes referred to as virtual hosts or vanity hostnames) |
1969 |
MUST use the following rules for determining the requested resource on |
1970 |
an HTTP/1.1 request: |
1971 |
|
1972 |
1. If Request-URI is an absoluteURI, the host is part of the Request- |
1973 |
URI. Any Host header field value in the request MUST be ignored. |
1974 |
|
1975 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 34] |
1976 |
|
1977 |
|
1978 |
|
1979 |
|
1980 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
1981 |
|
1982 |
|
1983 |
2. If the Request-URI is not an absoluteURI, and the request includes |
1984 |
a Host header field, the host is determined by the Host header |
1985 |
field value. |
1986 |
|
1987 |
3. If the host as determined by rule 1 or 2 is not a valid host on the |
1988 |
server, the response MUST be a 400 (Bad Request) error message. |
1989 |
|
1990 |
Recipients of an HTTP/1.0 request that lacks a Host header field MAY |
1991 |
attempt to use heuristics (e.g., examination of the URI path for |
1992 |
something unique to a particular host) in order to determine what exact |
1993 |
resource is being requested. |
1994 |
|
1995 |
|
1996 |
5.3 Request Header Fields |
1997 |
|
1998 |
The request-header fields allow the client to pass additional |
1999 |
information about the request, and about the client itself, to the |
2000 |
server. These fields act as request modifiers, with semantics equivalent |
2001 |
to the parameters on a programming language method invocation. |
2002 |
|
2003 |
request-header = Accept ; Section 14.1 |
2004 |
| Accept-Charset ; Section 14.2 |
2005 |
| Accept-Encoding ; Section 14.3 |
2006 |
| Accept-Language ; Section 14.4 |
2007 |
| Authorization ; Section 14.8 |
2008 |
| From ; Section 14.22 |
2009 |
| Host ; Section 14.23 |
2010 |
| If-Modified-Since ; Section 14.24 |
2011 |
| If-Match ; Section 14.25 |
2012 |
| If-None-Match ; Section 14.26 |
2013 |
| If-Range ; Section 14.27 |
2014 |
| If-Unmodified-Since ; Section 14.28 |
2015 |
| Max-Forwards ; Section 14.31 |
2016 |
| Proxy-Authorization ; Section 14.34 |
2017 |
| Range ; Section 14.36 |
2018 |
| Referer ; Section 14.37 |
2019 |
| User-Agent ; Section 14.42 |
2020 |
|
2021 |
Request-header field names can be extended reliably only in combination |
2022 |
with a change in the protocol version. However, new or experimental |
2023 |
header fields MAY be given the semantics of request-header fields if all |
2024 |
parties in the communication recognize them to be request-header fields. |
2025 |
Unrecognized header fields are treated as entity-header fields. |
2026 |
|
2027 |
|
2028 |
6 Response |
2029 |
|
2030 |
After receiving and interpreting a request message, a server responds |
2031 |
with an HTTP response message. |
2032 |
|
2033 |
|
2034 |
|
2035 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 35] |
2036 |
|
2037 |
|
2038 |
|
2039 |
|
2040 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2041 |
|
2042 |
|
2043 |
Response = Status-Line ; Section 6.1 |
2044 |
*( general-header ; Section 4.5 |
2045 |
| response-header ; Section 6.2 |
2046 |
| entity-header ) ; Section 7.1 |
2047 |
CRLF |
2048 |
[ message-body ] ; Section 7.2 |
2049 |
|
2050 |
|
2051 |
6.1 Status-Line |
2052 |
|
2053 |
The first line of a Response message is the Status-Line, consisting of |
2054 |
the protocol version followed by a numeric status code and its |
2055 |
associated textual phrase, with each element separated by SP characters. |
2056 |
No CR or LF is allowed except in the final CRLF sequence. |
2057 |
|
2058 |
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
2059 |
|
2060 |
|
2061 |
6.1.1 Status Code and Reason Phrase |
2062 |
|
2063 |
The Status-Code element is a 3-digit integer result code of the attempt |
2064 |
to understand and satisfy the request. These codes are fully defined in |
2065 |
section 10. The Reason-Phrase is intended to give a short textual |
2066 |
description of the Status-Code. The Status-Code is intended for use by |
2067 |
automata and the Reason-Phrase is intended for the human user. The |
2068 |
client is not required to examine or display the Reason-Phrase. |
2069 |
|
2070 |
The first digit of the Status-Code defines the class of response. The |
2071 |
last two digits do not have any categorization role. There are 5 values |
2072 |
for the first digit: |
2073 |
|
2074 |
|
2075 |
. 1xx: Informational - Request received, continuing process |
2076 |
|
2077 |
. 2xx: Success - The action was successfully received, understood, |
2078 |
and accepted |
2079 |
|
2080 |
. 3xx: Redirection - Further action must be taken in order to |
2081 |
complete the request |
2082 |
|
2083 |
. 4xx: Client Error - The request contains bad syntax or cannot be |
2084 |
fulfilled |
2085 |
|
2086 |
. 5xx: Server Error - The server failed to fulfill an apparently |
2087 |
valid request |
2088 |
The individual values of the numeric status codes defined for HTTP/1.1, |
2089 |
and an example set of corresponding Reason-Phrase's, are presented |
2090 |
below. The reason phrases listed here are only recommended -- they may |
2091 |
be replaced by local equivalents without affecting the protocol. |
2092 |
|
2093 |
|
2094 |
|
2095 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 36] |
2096 |
|
2097 |
|
2098 |
|
2099 |
|
2100 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2101 |
|
2102 |
|
2103 |
Status-Code = "100" ; Continue |
2104 |
| "101" ; Switching Protocols |
2105 |
| "200" ; OK |
2106 |
| "201" ; Created |
2107 |
| "202" ; Accepted |
2108 |
| "203" ; Non-Authoritative Information |
2109 |
| "204" ; No Content |
2110 |
| "205" ; Reset Content |
2111 |
| "206" ; Partial Content |
2112 |
| "300" ; Multiple Choices |
2113 |
| "301" ; Moved Permanently |
2114 |
| "302" ; Moved Temporarily |
2115 |
| "303" ; See Other |
2116 |
| "304" ; Not Modified |
2117 |
| "305" ; Use Proxy |
2118 |
| "400" ; Bad Request |
2119 |
| "401" ; Unauthorized |
2120 |
| "402" ; Payment Required |
2121 |
| "403" ; Forbidden |
2122 |
| "404" ; Not Found |
2123 |
| "405" ; Method Not Allowed |
2124 |
| "406" ; Not Acceptable |
2125 |
| "407" ; Proxy Authentication Required |
2126 |
| "408" ; Request Time-out |
2127 |
| "409" ; Conflict |
2128 |
| "410" ; Gone |
2129 |
| "411" ; Length Required |
2130 |
| "412" ; Precondition Failed |
2131 |
| "413" ; Request Entity Too Large |
2132 |
| "414" ; Request-URI Too Large |
2133 |
| "415" ; Unsupported Media Type |
2134 |
| "500" ; Internal Server Error |
2135 |
| "501" ; Not Implemented |
2136 |
| "502" ; Bad Gateway |
2137 |
| "503" ; Service Unavailable |
2138 |
| "504" ; Gateway Time-out |
2139 |
| "505" ; HTTP Version not supported |
2140 |
| extension-code |
2141 |
|
2142 |
extension-code = 3DIGIT |
2143 |
|
2144 |
Reason-Phrase = *<TEXT, excluding CR, LF> |
2145 |
|
2146 |
HTTP status codes are extensible. HTTP applications are not required to |
2147 |
understand the meaning of all registered status codes, though such |
2148 |
understanding is obviously desirable. However, applications MUST |
2149 |
understand the class of any status code, as indicated by the first |
2150 |
digit, and treat any unrecognized response as being equivalent to the |
2151 |
x00 status code of that class, with the exception that an unrecognized |
2152 |
response MUST NOT be cached. For example, if an unrecognized status code |
2153 |
of 431 is received by the client, it can safely assume that there was |
2154 |
|
2155 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37] |
2156 |
|
2157 |
|
2158 |
|
2159 |
|
2160 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2161 |
|
2162 |
|
2163 |
something wrong with its request and treat the response as if it had |
2164 |
received a 400 status code. In such cases, user agents SHOULD present to |
2165 |
the user the entity returned with the response, since that entity is |
2166 |
likely to include human-readable information which will explain the |
2167 |
unusual status. |
2168 |
|
2169 |
|
2170 |
6.2 Response Header Fields |
2171 |
|
2172 |
The response-header fields allow the server to pass additional |
2173 |
information about the response which cannot be placed in the Status- |
2174 |
Line. These header fields give information about the server and about |
2175 |
further access to the resource identified by the Request-URI. |
2176 |
|
2177 |
response-header = Age ; Section 14.6 |
2178 |
| Location ; Section 14.30 |
2179 |
| Proxy-Authenticate ; Section 14.33 |
2180 |
| Public ; Section 14.35 |
2181 |
| Retry-After ; Section 14.38 |
2182 |
| Server ; Section 14.39 |
2183 |
| Vary ; Section 14.43 |
2184 |
| WWW-Authenticate ; Section 14.43 |
2185 |
|
2186 |
Response-header field names can be extended reliably only in combination |
2187 |
with a change in the protocol version. However, new or experimental |
2188 |
header fields MAY be given the semantics of response-header fields if |
2189 |
all parties in the communication recognize them to be response-header |
2190 |
fields. Unrecognized header fields are treated as entity-header fields. |
2191 |
|
2192 |
|
2193 |
7 Entity |
2194 |
|
2195 |
Request and Response messages MAY transfer an entity if not otherwise |
2196 |
restricted by the request method or response status code. An entity |
2197 |
consists of entity-header fields and an entity-body, although some |
2198 |
responses will only include the entity-headers. |
2199 |
|
2200 |
In this section, both sender and recipient refer to either the client or |
2201 |
the server, depending on who sends and who receives the entity. |
2202 |
|
2203 |
|
2204 |
7.1 Entity Header Fields |
2205 |
|
2206 |
Entity-header fields define optional metainformation about the entity- |
2207 |
body or, if no body is present, about the resource identified by the |
2208 |
request. |
2209 |
|
2210 |
entity-header = Allow ; Section 14.7 |
2211 |
| Content-Base ; Section 14.11 |
2212 |
| Content-Encoding ; Section 14.12 |
2213 |
| Content-Language ; Section 14.13 |
2214 |
|
2215 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 38] |
2216 |
|
2217 |
|
2218 |
|
2219 |
|
2220 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2221 |
|
2222 |
|
2223 |
| Content-Length ; Section 14.14 |
2224 |
| Content-Location ; Section 14.15 |
2225 |
| Content-MD5 ; Section 14.16 |
2226 |
| Content-Range ; Section 14.17 |
2227 |
| Content-Type ; Section 14.18 |
2228 |
| ETag ; Section 14.20 |
2229 |
| Expires ; Section 14.21 |
2230 |
| Last-Modified ; Section 14.29 |
2231 |
| extension-header |
2232 |
|
2233 |
extension-header = message-header |
2234 |
|
2235 |
The extension-header mechanism allows additional entity-header fields to |
2236 |
be defined without changing the protocol, but these fields cannot be |
2237 |
assumed to be recognizable by the recipient. Unrecognized header fields |
2238 |
SHOULD be ignored by the recipient and forwarded by proxies. |
2239 |
|
2240 |
|
2241 |
7.2 Entity Body |
2242 |
|
2243 |
The entity-body (if any) sent with an HTTP request or response is in a |
2244 |
format and encoding defined by the entity-header fields. |
2245 |
|
2246 |
entity-body = *OCTET |
2247 |
|
2248 |
An entity-body is only present in a message when a message-body is |
2249 |
present, as described in section 4.3. The entity-body is obtained from |
2250 |
the message-body by decoding any Transfer-Encoding that may have been |
2251 |
applied to ensure safe and proper transfer of the message. |
2252 |
|
2253 |
|
2254 |
7.2.1 Type |
2255 |
|
2256 |
When an entity-body is included with a message, the data type of that |
2257 |
body is determined via the header fields Content-Type and Content- |
2258 |
Encoding. These define a two-layer, ordered encoding model: |
2259 |
|
2260 |
entity-body := Content-Encoding( Content-Type( data ) ) |
2261 |
|
2262 |
Content-Type specifies the media type of the underlying data. Content- |
2263 |
Encoding may be used to indicate any additional content codings applied |
2264 |
to the data, usually for the purpose of data compression, that are a |
2265 |
property of the requested resource. There is no default encoding. |
2266 |
|
2267 |
Any HTTP/1.1 message containing an entity-body SHOULD include a Content- |
2268 |
Type header field defining the media type of that body. If and only if |
2269 |
the media type is not given by a Content-Type field, the recipient MAY |
2270 |
attempt to guess the media type via inspection of its content and/or the |
2271 |
name extension(s) of the URL used to identify the resource. If the media |
2272 |
type remains unknown, the recipient SHOULD treat it as type |
2273 |
"application/octet-stream". |
2274 |
|
2275 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39] |
2276 |
|
2277 |
|
2278 |
|
2279 |
|
2280 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2281 |
|
2282 |
|
2283 |
7.2.2 Length |
2284 |
|
2285 |
The length of an entity-body is the length of the message-body after any |
2286 |
transfer codings have been removed. Section 4.4 defines how the length |
2287 |
of a message-body is determined. |
2288 |
|
2289 |
|
2290 |
8 Connections |
2291 |
|
2292 |
|
2293 |
8.1 Persistent Connections |
2294 |
|
2295 |
|
2296 |
8.1.1 Purpose |
2297 |
|
2298 |
Prior to persistent connections, a separate TCP connection was |
2299 |
established to fetch each URL, increasing the load on HTTP servers, and |
2300 |
causing congestion on the Internet. The use of inline images and other |
2301 |
associated data often requires a client to make multiple requests of the |
2302 |
same server in a short amount of time. An excellent analysis of these |
2303 |
performance problems is available [30]; analysis and results from a |
2304 |
prototype implementation are in [26]. |
2305 |
|
2306 |
Persistent HTTP connections have a number of advantages: |
2307 |
|
2308 |
. By opening and closing fewer TCP connections, CPU time is saved, |
2309 |
and memory used for TCP protocol control blocks is also saved. |
2310 |
. HTTP requests and responses can be pipelined on a connection. |
2311 |
Pipelining allows a client to make multiple requests without |
2312 |
waiting for each response, allowing a single TCP connection to be |
2313 |
used much more efficiently, with much lower elapsed time. |
2314 |
. Network congestion is reduced by reducing the number of packets |
2315 |
caused by TCP opens, and by allowing TCP sufficient time to |
2316 |
determine the congestion state of the network. |
2317 |
. HTTP can evolve more gracefully; since errors can be reported |
2318 |
without the penalty of closing the TCP connection. Clients using |
2319 |
future versions of HTTP might optimistically try a new feature, but |
2320 |
if communicating with an older server, retry with old semantics |
2321 |
after an error is reported. |
2322 |
HTTP implementations SHOULD implement persistent connections. |
2323 |
|
2324 |
|
2325 |
8.1.2 Overall Operation |
2326 |
|
2327 |
A significant difference between HTTP/1.1 and earlier versions of HTTP |
2328 |
is that persistent connections are the default behavior of any HTTP |
2329 |
connection. That is, unless otherwise indicated, the client may assume |
2330 |
that the server will maintain a persistent connection. |
2331 |
|
2332 |
Persistent connections provide a mechanism by which a client and a |
2333 |
server can signal the close of a TCP connection. This signaling takes |
2334 |
|
2335 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 40] |
2336 |
|
2337 |
|
2338 |
|
2339 |
|
2340 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2341 |
|
2342 |
|
2343 |
place using the Connection header field. Once a close has been signaled, |
2344 |
the client MUST not send any more requests on that connection. |
2345 |
|
2346 |
|
2347 |
8.1.2.1 Negotiation |
2348 |
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to maintain |
2349 |
a persistent connection unless a Connection header including the |
2350 |
connection-token "close" was sent in the request. If the server chooses |
2351 |
to close the connection immediately after sending the response, it |
2352 |
SHOULD send a Connection header including the connection-token close. |
2353 |
|
2354 |
An HTTP/1.1 client MAY expect a connection to remain open, but would |
2355 |
decide to keep it open based on whether the response from a server |
2356 |
contains a Connection header with the connection-token close. In case |
2357 |
the client does not want to maintain a connection for more than that |
2358 |
request, it SHOULD send a Connection header including the connection- |
2359 |
token close. |
2360 |
|
2361 |
If either the client or the server sends the close token in the |
2362 |
Connection header, that request becomes the last one for the connection. |
2363 |
|
2364 |
Clients and servers SHOULD NOT assume that a persistent connection is |
2365 |
maintained for HTTP versions less than 1.1 unless it is explicitly |
2366 |
signaled. See section 19.7.1 for more information on backwards |
2367 |
compatibility with HTTP/1.0 clients. |
2368 |
|
2369 |
In order to remain persistent, all messages on the connection must have |
2370 |
a self-defined message length (i.e., one not defined by closure of the |
2371 |
connection), as described in section 4.4. |
2372 |
|
2373 |
|
2374 |
8.1.2.2 Pipelining |
2375 |
A client that supports persistent connections MAY "pipeline" its |
2376 |
requests (i.e., send multiple requests without waiting for each |
2377 |
response). A server MUST send its responses to those requests in the |
2378 |
same order that the requests were received. |
2379 |
|
2380 |
Clients which assume persistent connections and pipeline immediately |
2381 |
after connection establishment SHOULD be prepared to retry their |
2382 |
connection if the first pipelined attempt fails. If a client does such a |
2383 |
retry, it MUST NOT pipeline before it knows the connection is |
2384 |
persistent. Clients MUST also be prepared to resend their requests if |
2385 |
the server closes the connection before sending all of the corresponding |
2386 |
responses. |
2387 |
|
2388 |
|
2389 |
8.1.3 Proxy Servers |
2390 |
|
2391 |
It is especially important that proxies correctly implement the |
2392 |
properties of the Connection header field as specified in 14.2.1. |
2393 |
|
2394 |
|
2395 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 41] |
2396 |
|
2397 |
|
2398 |
|
2399 |
|
2400 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2401 |
|
2402 |
|
2403 |
The proxy server MUST signal persistent connections separately with its |
2404 |
clients and the origin servers (or other proxy servers) that it connects |
2405 |
to. Each persistent connection applies to only one transport link. |
2406 |
|
2407 |
A proxy server MUST NOT establish a persistent connection with an |
2408 |
HTTP/1.0 client. |
2409 |
|
2410 |
|
2411 |
8.1.4 Practical Considerations |
2412 |
|
2413 |
Servers will usually have some time-out value beyond which they will no |
2414 |
longer maintain an inactive connection. Proxy servers might make this a |
2415 |
higher value since it is likely that the client will be making more |
2416 |
connections through the same server. The use of persistent connections |
2417 |
places no requirements on the length of this time-out for either the |
2418 |
client or the server. |
2419 |
|
2420 |
When a client or server wishes to time-out it SHOULD issue a graceful |
2421 |
close on the transport connection. Clients and servers SHOULD both |
2422 |
constantly watch for the other side of the transport close, and respond |
2423 |
to it as appropriate. If a client or server does not detect the other |
2424 |
side's close promptly it could cause unnecessary resource drain on the |
2425 |
network. |
2426 |
|
2427 |
A client, server, or proxy MAY close the transport connection at any |
2428 |
time. For example, a client MAY have started to send a new request at |
2429 |
the same time that the server has decided to close the "idle" |
2430 |
connection. From the server's point of view, the connection is being |
2431 |
closed while it was idle, but from the client's point of view, a request |
2432 |
is in progress. |
2433 |
|
2434 |
This means that clients, servers, and proxies MUST be able to recover |
2435 |
from asynchronous close events. Client software SHOULD reopen the |
2436 |
transport connection and retransmit the aborted request without user |
2437 |
interaction so long as the request method is idempotent (see section |
2438 |
9.1.2); other methods MUST NOT be automatically retried, although user |
2439 |
agents MAY offer a human operator the choice of retrying the request. |
2440 |
However, this automatic retry SHOULD NOT be repeated if the second |
2441 |
request fails. |
2442 |
|
2443 |
Servers SHOULD always respond to at least one request per connection, if |
2444 |
at all possible. Servers SHOULD NOT close a connection in the middle of |
2445 |
transmitting a response, unless a network or client failure is |
2446 |
suspected. |
2447 |
|
2448 |
It is suggested that clients which use persistent connections SHOULD |
2449 |
limit the number of simultaneous connections that they maintain to a |
2450 |
given server. A single-user client SHOULD maintain AT MOST 2 connections |
2451 |
with any server or proxy. A proxy SHOULD use up to 2*N connections to |
2452 |
another server or proxy, where N is the number of simultaneously active |
2453 |
|
2454 |
|
2455 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 42] |
2456 |
|
2457 |
|
2458 |
|
2459 |
|
2460 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2461 |
|
2462 |
|
2463 |
users. These guidelines are intended to improve HTTP response times and |
2464 |
avoid congestion of the Internet or other networks. |
2465 |
|
2466 |
|
2467 |
8.2 Message Transmission Requirements |
2468 |
|
2469 |
General requirements: |
2470 |
|
2471 |
. HTTP/1.1 servers SHOULD maintain persistent connections and use |
2472 |
TCP's flow control mechanisms to resolve temporary overloads, |
2473 |
rather than terminating connections with the expectation that |
2474 |
clients will retry. The latter technique can exacerbate network |
2475 |
congestion. |
2476 |
. An HTTP/1.1 (or later) client doing a PUT-like method SHOULD |
2477 |
monitor the network connection for an error status while it is |
2478 |
transmitting the request. If the client sees an error status, it |
2479 |
SHOULD immediately cease transmitting the body. If the body is |
2480 |
being sent using a "chunked" encoding, a zero length chunk is used |
2481 |
to mark the end of the message. If the body was preceded by a |
2482 |
Content-Length header, the client MUST close the connection. |
2483 |
. An HTTP/1.1 (or later) client MUST be prepared to accept a 100 |
2484 |
(Continue) status followed by a regular response. |
2485 |
. An HTTP/1.1 (or later) server that receives a request from a |
2486 |
HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue) |
2487 |
response; it SHOULD either wait for the request to be completed |
2488 |
normally (thus avoiding an interrupted request) or close the |
2489 |
connection prematurely. |
2490 |
Upon receiving a method subject to these requirements from an HTTP/1.1 |
2491 |
(or later) client, an HTTP/1.1 (or later) server MUST either respond |
2492 |
with 100 (Continue) status and continue to read from the input stream, |
2493 |
or respond with an error status. If it responds with an error status, it |
2494 |
MAY close the transport (TCP) connection or it MAY continue to read and |
2495 |
discard the rest of the request. It MUST NOT perform the requested |
2496 |
method if it returns an error status. |
2497 |
|
2498 |
Clients SHOULD remember the version number of at least the most recently |
2499 |
used server; if an HTTP/1.1 client has seen an HTTP/1.1 or later |
2500 |
response from the server, and it sees the connection close before |
2501 |
receiving any status from the server, the client SHOULD retry the |
2502 |
request without user interaction so long as the request method is |
2503 |
idempotent (see section 9.1.2); other methods MUST NOT be automatically |
2504 |
retried, although user agents MAY offer a human operator the choice of |
2505 |
retrying the request.. If the client does retry the request, the client |
2506 |
|
2507 |
. MUST first send the request header fields, and then |
2508 |
. MUST wait for the server to respond with either a 100 (Continue) |
2509 |
response, in which case the client should continue, or with an |
2510 |
error status. |
2511 |
If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from |
2512 |
the server, it should assume that the server implements HTTP/1.0 or |
2513 |
older and will not use the 100 (Continue) response. If in this case the |
2514 |
|
2515 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 43] |
2516 |
|
2517 |
|
2518 |
|
2519 |
|
2520 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2521 |
|
2522 |
|
2523 |
client sees the connection close before receiving any status from the |
2524 |
server, the client SHOULD retry the request. If the client does retry |
2525 |
the request, it should use the following "binary exponential backoff" |
2526 |
algorithm to be assured of obtaining a reliable response: |
2527 |
|
2528 |
1. Initiate a new connection to the server |
2529 |
2. Transmit the request-headers |
2530 |
3. Initialize a variable R to the estimated round-trip time to the |
2531 |
server (e.g., based on the time it took to establish the |
2532 |
connection), or to a constant value of 5 seconds if the round-trip |
2533 |
time is not available. |
2534 |
4. Compute T = R * (2**N), where N is the number of previous retries |
2535 |
of this request. |
2536 |
5. Wait either for an error response from the server, or for T seconds |
2537 |
(whichever comes first) |
2538 |
6. If no error response is received, after T seconds transmit the body |
2539 |
of the request. |
2540 |
7. If client sees that the connection is closed prematurely, repeat |
2541 |
from step 1 until the request is accepted, an error response is |
2542 |
received, or the user becomes impatient and terminates the retry |
2543 |
process. |
2544 |
No matter what the server version, if an error status is received, the |
2545 |
client |
2546 |
|
2547 |
. MUST NOT continue and |
2548 |
. MUST close the connection if it has not already completed sending |
2549 |
the full request body including any encoding mechanism used to |
2550 |
transmit the body. |
2551 |
An HTTP/1.1 (or later) client that sees the connection close after |
2552 |
receiving a 100 (Continue) but before receiving any other status SHOULD |
2553 |
retry the request, and need not wait for 100 (Continue) response (but |
2554 |
MAY do so if this simplifies the implementation). |
2555 |
|
2556 |
|
2557 |
9 Method Definitions |
2558 |
|
2559 |
The set of common methods for HTTP/1.1 is defined below. Although this |
2560 |
set can be expanded, additional methods cannot be assumed to share the |
2561 |
same semantics for separately extended clients and servers. |
2562 |
|
2563 |
The Host request-header field (section 14.23) MUST accompany all |
2564 |
HTTP/1.1 requests. |
2565 |
|
2566 |
|
2567 |
9.1.1 Safe Methods |
2568 |
|
2569 |
Implementers should be aware that the software represents the user in |
2570 |
their interactions over the Internet, and should be careful to allow the |
2571 |
user to be aware of any actions they may take which may have an |
2572 |
unexpected significance to themselves or others. |
2573 |
|
2574 |
|
2575 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 44] |
2576 |
|
2577 |
|
2578 |
|
2579 |
|
2580 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2581 |
|
2582 |
|
2583 |
In particular, the convention has been established that the GET and HEAD |
2584 |
methods should never have the significance of taking an action other |
2585 |
than retrieval. These methods should be considered "safe." This allows |
2586 |
user agents to represent other methods, such as POST, PUT and DELETE, in |
2587 |
a special way, so that the user is made aware of the fact that a |
2588 |
possibly unsafe action is being requested. |
2589 |
|
2590 |
Naturally, it is not possible to ensure that the server does not |
2591 |
generate side-effects as a result of performing a GET request; in fact, |
2592 |
some dynamic resources consider that a feature. The important |
2593 |
distinction here is that the user did not request the side-effects, so |
2594 |
therefore cannot be held accountable for them. |
2595 |
|
2596 |
|
2597 |
9.1.2 Idempotent Methods |
2598 |
|
2599 |
Methods may also have the property of "idempotence" in that (aside from |
2600 |
error or expiration issues) the results from N>0 identical requests is |
2601 |
the same as for a single request. The methods GET, HEAD, PUT and DELETE |
2602 |
share this property. |
2603 |
|
2604 |
|
2605 |
9.2 OPTIONS |
2606 |
|
2607 |
The OPTIONS method represents a request for information about the |
2608 |
communication options available on the request/response chain identified |
2609 |
by the Request-URI. This method allows the client to determine the |
2610 |
options and/or requirements associated with a resource, or the |
2611 |
capabilities of a server, without implying a resource action or |
2612 |
initiating a resource retrieval. |
2613 |
|
2614 |
Unless the server's response is an error, the response MUST NOT include |
2615 |
entity information other than what can be considered as communication |
2616 |
options (e.g., Allow is appropriate, but Content-Type is not). Responses |
2617 |
to this method are not cachable. |
2618 |
|
2619 |
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended |
2620 |
to apply to the server as a whole. A 200 response SHOULD include any |
2621 |
header fields which indicate optional features implemented by the server |
2622 |
(e.g., Public), including any extensions not defined by this |
2623 |
specification, in addition to any applicable general or response-header |
2624 |
fields. As described in section 5.1.2, an "OPTIONS *" request can be |
2625 |
applied through a proxy by specifying the destination server in the |
2626 |
Request-URI without any path information. |
2627 |
|
2628 |
If the Request-URI is not an asterisk, the OPTIONS request applies only |
2629 |
to the options that are available when communicating with that resource. |
2630 |
A 200 response SHOULD include any header fields which indicate optional |
2631 |
features implemented by the server and applicable to that resource |
2632 |
(e.g., Allow), including any extensions not defined by this |
2633 |
specification, in addition to any applicable general or response-header |
2634 |
|
2635 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 45] |
2636 |
|
2637 |
|
2638 |
|
2639 |
|
2640 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2641 |
|
2642 |
|
2643 |
fields. If the OPTIONS request passes through a proxy, the proxy MUST |
2644 |
edit the response to exclude those options known to be unavailable |
2645 |
through that proxy. |
2646 |
|
2647 |
|
2648 |
9.3 GET |
2649 |
|
2650 |
The GET method means retrieve whatever information (in the form of an |
2651 |
entity) is identified by the Request-URI. If the Request-URI refers to a |
2652 |
data-producing process, it is the produced data which shall be returned |
2653 |
as the entity in the response and not the source text of the process, |
2654 |
unless that text happens to be the output of the process. |
2655 |
|
2656 |
The semantics of the GET method change to a "conditional GET" if the |
2657 |
request message includes an If-Modified-Since , If-Unmodified-Since, If- |
2658 |
Match, If-None-Match, or If-Range header field. A conditional GET method |
2659 |
requests that the entity be transferred only under the circumstances |
2660 |
described by the conditional header field(s). The conditional GET method |
2661 |
is intended to reduce unnecessary network usage by allowing cached |
2662 |
entities to be refreshed without requiring multiple requests or |
2663 |
transferring data already held by the client. |
2664 |
|
2665 |
The semantics of the GET method change to a "partial GET" if the request |
2666 |
message includes a Range header field. A partial GET requests that only |
2667 |
part of the entity be transferred, as described in section 14.36. The |
2668 |
partial GET method is intended to reduce unnecessary network usage by |
2669 |
allowing partially-retrieved entities to be completed without |
2670 |
transferring data already held by the client. |
2671 |
|
2672 |
The response to a GET request is cachable if and only if it meets the |
2673 |
requirements for HTTP caching described in section 13. |
2674 |
|
2675 |
|
2676 |
9.4 HEAD |
2677 |
|
2678 |
The HEAD method is identical to GET except that the server MUST NOT |
2679 |
return a message-body in the response. The metainformation contained in |
2680 |
the HTTP headers in response to a HEAD request SHOULD be identical to |
2681 |
the information sent in response to a GET request. This method can be |
2682 |
used for obtaining metainformation about the entity implied by the |
2683 |
request without transferring the entity-body itself. This method is |
2684 |
often used for testing hypertext links for validity, accessibility, and |
2685 |
recent modification. |
2686 |
|
2687 |
The response to a HEAD request may be cachable in the sense that the |
2688 |
information contained in the response may be used to update a previously |
2689 |
cached entity from that resource. If the new field values indicate that |
2690 |
the cached entity differs from the current entity (as would be indicated |
2691 |
by a change in Content-Length, Content-MD5, ETag or Last-Modified), then |
2692 |
the cache MUST treat the cache entry as stale. |
2693 |
|
2694 |
|
2695 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 46] |
2696 |
|
2697 |
|
2698 |
|
2699 |
|
2700 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2701 |
|
2702 |
|
2703 |
9.5 POST |
2704 |
|
2705 |
The POST method is used to request that the destination server accept |
2706 |
the entity enclosed in the request as a new subordinate of the resource |
2707 |
identified by the Request-URI in the Request-Line. POST is designed to |
2708 |
allow a uniform method to cover the following functions: |
2709 |
|
2710 |
|
2711 |
. Annotation of existing resources; |
2712 |
|
2713 |
. Posting a message to a bulletin board, newsgroup, mailing list, or |
2714 |
similar group of articles; |
2715 |
|
2716 |
. Providing a block of data, such as the result of submitting a form, |
2717 |
to a data-handling process; |
2718 |
|
2719 |
. Extending a database through an append operation. |
2720 |
The actual function performed by the POST method is determined by the |
2721 |
server and is usually dependent on the Request-URI. The posted entity is |
2722 |
subordinate to that URI in the same way that a file is subordinate to a |
2723 |
directory containing it, a news article is subordinate to a newsgroup to |
2724 |
which it is posted, or a record is subordinate to a database. |
2725 |
|
2726 |
The action performed by the POST method might not result in a resource |
2727 |
that can be identified by a URI. In this case, either 200 (OK) or 204 |
2728 |
(No Content) is the appropriate response status, depending on whether or |
2729 |
not the response includes an entity that describes the result. |
2730 |
|
2731 |
If a resource has been created on the origin server, the response SHOULD |
2732 |
be 201 (Created) and contain an entity which describes the status of the |
2733 |
request and refers to the new resource , and a Location header (see |
2734 |
section 14.30). |
2735 |
|
2736 |
Responses to this method are not cachable, unless the response includes |
2737 |
appropriate Cache-Control or Expires header fields. However, the 303 |
2738 |
(See Other) response can be used to direct the user agent to retrieve a |
2739 |
cachable resource. |
2740 |
|
2741 |
POST requests must obey the message transmission requirements set out in |
2742 |
section 8.2. |
2743 |
|
2744 |
|
2745 |
9.6 PUT |
2746 |
|
2747 |
The PUT method requests that the enclosed entity be stored under the |
2748 |
supplied Request-URI. If the Request-URI refers to an already existing |
2749 |
resource, the enclosed entity SHOULD be considered as a modified version |
2750 |
of the one residing on the origin server. If the Request-URI does not |
2751 |
point to an existing resource, and that URI is capable of being defined |
2752 |
as a new resource by the requesting user agent, the origin server can |
2753 |
create the resource with that URI. If a new resource is created, the |
2754 |
|
2755 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 47] |
2756 |
|
2757 |
|
2758 |
|
2759 |
|
2760 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2761 |
|
2762 |
|
2763 |
origin server MUST inform the user agent via the 201 (Created) response. |
2764 |
If an existing resource is modified, either the 200 (OK) or 204 (No |
2765 |
Content) response codes SHOULD be sent to indicate successful completion |
2766 |
of the request. If the resource could not be created or modified with |
2767 |
the Request-URI, an appropriate error response SHOULD be given that |
2768 |
reflects the nature of the problem. The recipient of the entity MUST NOT |
2769 |
ignore any Content-* (e.g. Content-Range) headers that it does not |
2770 |
understand or implement and MUST return a 501 (Not Implemented) response |
2771 |
in such cases. |
2772 |
|
2773 |
If the request passes through a cache and the Request-URI identifies one |
2774 |
or more currently cached entities, those entries should be treated as |
2775 |
stale. Responses to this method are not cachable. |
2776 |
|
2777 |
The fundamental difference between the POST and PUT requests is |
2778 |
reflected in the different meaning of the Request-URI. The URI in a POST |
2779 |
request identifies the resource that will handle the enclosed entity. |
2780 |
That resource may be a data-accepting process, a gateway to some other |
2781 |
protocol, or a separate entity that accepts annotations. In contrast, |
2782 |
the URI in a PUT request identifies the entity enclosed with the request |
2783 |
-- the user agent knows what URI is intended and the server MUST NOT |
2784 |
attempt to apply the request to some other resource. If the server |
2785 |
desires that the request be applied to a different URI, it MUST send a |
2786 |
301 (Moved Permanently) response; the user agent MAY then make its own |
2787 |
decision regarding whether or not to redirect the request. |
2788 |
|
2789 |
A single resource MAY be identified by many different URIs. For example, |
2790 |
an article may have a URI for identifying "the current version" which is |
2791 |
separate from the URI identifying each particular version. In this case, |
2792 |
a PUT request on a general URI may result in several other URIs being |
2793 |
defined by the origin server. |
2794 |
|
2795 |
HTTP/1.1 does not define how a PUT method affects the state of an origin |
2796 |
server. |
2797 |
|
2798 |
PUT requests must obey the message transmission requirements set out in |
2799 |
section 8.2. |
2800 |
|
2801 |
|
2802 |
9.7 DELETE |
2803 |
|
2804 |
The DELETE method requests that the origin server delete the resource |
2805 |
identified by the Request-URI. This method MAY be overridden by human |
2806 |
intervention (or other means) on the origin server. The client cannot be |
2807 |
guaranteed that the operation has been carried out, even if the status |
2808 |
code returned from the origin server indicates that the action has been |
2809 |
completed successfully. However, the server SHOULD not indicate success |
2810 |
unless, at the time the response is given, it intends to delete the |
2811 |
resource or move it to an inaccessible location. |
2812 |
|
2813 |
|
2814 |
|
2815 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 48] |
2816 |
|
2817 |
|
2818 |
|
2819 |
|
2820 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2821 |
|
2822 |
|
2823 |
A successful response SHOULD be 200 (OK) if the response includes an |
2824 |
entity describing the status, 202 (Accepted) if the action has not yet |
2825 |
been enacted, or 204 (No Content) if the response is OK but does not |
2826 |
include an entity. |
2827 |
|
2828 |
If the request passes through a cache and the Request-URI identifies one |
2829 |
or more currently cached entities, those entries should be treated as |
2830 |
stale. Responses to this method are not cachable. |
2831 |
|
2832 |
|
2833 |
9.8 TRACE |
2834 |
|
2835 |
The TRACE method is used to invoke a remote, application-layer loop-back |
2836 |
of the request message. The final recipient of the request SHOULD |
2837 |
reflect the message received back to the client as the entity-body of a |
2838 |
200 (OK) response. The final recipient is either the origin server or |
2839 |
the first proxy or gateway to receive a Max-Forwards value of zero (0) |
2840 |
in the request (see section 14.31). A TRACE request MUST NOT include an |
2841 |
entity. |
2842 |
|
2843 |
TRACE allows the client to see what is being received at the other end |
2844 |
of the request chain and use that data for testing or diagnostic |
2845 |
information. The value of the Via header field (section 14.44) is of |
2846 |
particular interest, since it acts as a trace of the request chain. Use |
2847 |
of the Max-Forwards header field allows the client to limit the length |
2848 |
of the request chain, which is useful for testing a chain of proxies |
2849 |
forwarding messages in an infinite loop. |
2850 |
|
2851 |
If successful, the response SHOULD contain the entire request message in |
2852 |
the entity-body, with a Content-Type of "message/http". Responses to |
2853 |
this method MUST NOT be cached. |
2854 |
|
2855 |
|
2856 |
10 Status Code Definitions |
2857 |
|
2858 |
Each Status-Code is described below, including a description of which |
2859 |
method(s) it can follow and any metainformation required in the |
2860 |
response. |
2861 |
|
2862 |
|
2863 |
10.1 Informational 1xx |
2864 |
|
2865 |
This class of status code indicates a provisional response, consisting |
2866 |
only of the Status-Line and optional headers, and is terminated by an |
2867 |
empty line. Since HTTP/1.0 did not define any 1xx status codes, servers |
2868 |
MUST NOT send a 1xx response to an HTTP/1.0 client except under |
2869 |
experimental conditions. |
2870 |
|
2871 |
|
2872 |
|
2873 |
|
2874 |
|
2875 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 49] |
2876 |
|
2877 |
|
2878 |
|
2879 |
|
2880 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2881 |
|
2882 |
|
2883 |
10.1.1 100 Continue |
2884 |
|
2885 |
The client may continue with its request. This interim response is used |
2886 |
to inform the client that the initial part of the request has been |
2887 |
received and has not yet been rejected by the server. The client SHOULD |
2888 |
continue by sending the remainder of the request or, if the request has |
2889 |
already been completed, ignore this response. The server MUST send a |
2890 |
final response after the request has been completed. |
2891 |
|
2892 |
|
2893 |
10.1.2 101 Switching Protocols |
2894 |
|
2895 |
The server understands and is willing to comply with the client's |
2896 |
request, via the Upgrade message header field (section 14.41), for a |
2897 |
change in the application protocol being used on this connection. The |
2898 |
server will switch protocols to those defined by the response's Upgrade |
2899 |
header field immediately after the empty line which terminates the 101 |
2900 |
response. |
2901 |
|
2902 |
The protocol should only be switched when it is advantageous to do so. |
2903 |
For example, switching to a newer version of HTTP is advantageous over |
2904 |
older versions, and switching to a real-time, synchronous protocol may |
2905 |
be advantageous when delivering resources that use such features. |
2906 |
|
2907 |
|
2908 |
10.2 Successful 2xx |
2909 |
|
2910 |
This class of status code indicates that the client's request was |
2911 |
successfully received, understood, and accepted. |
2912 |
|
2913 |
|
2914 |
10.2.1 200 OK |
2915 |
|
2916 |
The request has succeeded. The information returned with the response is |
2917 |
dependent on the method used in the request, for example: |
2918 |
|
2919 |
GET an entity corresponding to the requested resource is sent in the |
2920 |
response; |
2921 |
|
2922 |
HEAD the entity-header fields corresponding to the requested resource |
2923 |
are sent in the response without any message-body; |
2924 |
|
2925 |
POST an entity describing or containing the result of the action; |
2926 |
|
2927 |
TRACE an entity containing the request message as received by the end |
2928 |
server. |
2929 |
|
2930 |
|
2931 |
|
2932 |
|
2933 |
|
2934 |
|
2935 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 50] |
2936 |
|
2937 |
|
2938 |
|
2939 |
|
2940 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
2941 |
|
2942 |
|
2943 |
10.2.2 201 Created |
2944 |
|
2945 |
The request has been fulfilled and resulted in a new resource being |
2946 |
created. The newly created resource can be referenced by the URI(s) |
2947 |
returned in the entity of the response, with the most specific URL for |
2948 |
the resource given by a Location header field. The origin server MUST |
2949 |
create the resource before returning the 201 status code. If the action |
2950 |
cannot be carried out immediately, the server should respond with 202 |
2951 |
(Accepted) response instead. |
2952 |
|
2953 |
|
2954 |
10.2.3 202 Accepted |
2955 |
|
2956 |
The request has been accepted for processing, but the processing has not |
2957 |
been completed. The request MAY or MAY NOT eventually be acted upon, as |
2958 |
it MAY be disallowed when processing actually takes place. There is no |
2959 |
facility for re-sending a status code from an asynchronous operation |
2960 |
such as this. |
2961 |
|
2962 |
The 202 response is intentionally non-committal. Its purpose is to allow |
2963 |
a server to accept a request for some other process (perhaps a batch- |
2964 |
oriented process that is only run once per day) without requiring that |
2965 |
the user agent's connection to the server persist until the process is |
2966 |
completed. The entity returned with this response SHOULD include an |
2967 |
indication of the request's current status and either a pointer to a |
2968 |
status monitor or some estimate of when the user can expect the request |
2969 |
to be fulfilled. |
2970 |
|
2971 |
|
2972 |
10.2.4 203 Non-Authoritative Information |
2973 |
|
2974 |
The returned metainformation in the entity-header is not the definitive |
2975 |
set as available from the origin server, but is gathered from a local or |
2976 |
a third-party copy. The set presented MAY be a subset or superset of the |
2977 |
original version. For example, including local annotation information |
2978 |
about the resource MAY result in a superset of the metainformation known |
2979 |
by the origin server. Use of this response code is not required and is |
2980 |
only appropriate when the response would otherwise be 200 (OK). |
2981 |
|
2982 |
|
2983 |
10.2.5 204 No Content |
2984 |
|
2985 |
The server has fulfilled the request but there is no new information to |
2986 |
send back. If the client is a user agent, it SHOULD NOT change its |
2987 |
document view from that which caused the request to be sent. This |
2988 |
response is primarily intended to allow input for actions to take place |
2989 |
without causing a change to the user agent's active document view. The |
2990 |
response MAY include new metainformation in the form of entity-headers, |
2991 |
which SHOULD apply to the document currently in the user agent's active |
2992 |
view. |
2993 |
|
2994 |
|
2995 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 51] |
2996 |
|
2997 |
|
2998 |
|
2999 |
|
3000 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3001 |
|
3002 |
|
3003 |
The 204 response MUST NOT include an message-body, and thus is always |
3004 |
terminated by the first empty line after the header fields. |
3005 |
|
3006 |
|
3007 |
10.2.6 205 Reset Content |
3008 |
|
3009 |
The server has fulfilled the request and the user agent SHOULD reset the |
3010 |
document view which caused the request to be sent. This response is |
3011 |
primarily intended to allow input for actions to take place via user |
3012 |
input, followed by a clearing of the form in which the input is given so |
3013 |
that the user can easily initiate another input action. The response |
3014 |
MUST NOT include an entity. |
3015 |
|
3016 |
|
3017 |
10.2.7 206 Partial Content |
3018 |
|
3019 |
The server has fulfilled the partial GET request for the resource. The |
3020 |
request must have included a Range header field (section 14.36) |
3021 |
indicating the desired range. The response MUST include a Content-Range |
3022 |
header field (section 14.17) indicating the range included with this |
3023 |
response. The Content-Length header field in the response MUST match the |
3024 |
actual number of OCTETs transmitted in the message-body. |
3025 |
|
3026 |
A cache that does not support the Range and Content-Range headers MUST |
3027 |
NOT cache 206 (Partial) responses. |
3028 |
|
3029 |
|
3030 |
10.3 Redirection 3xx |
3031 |
|
3032 |
This class of status code indicates that further action needs to be |
3033 |
taken by the user agent in order to fulfill the request. The action |
3034 |
required MAY be carried out by the user agent without interaction with |
3035 |
the user if and only if the method used in the second request is GET or |
3036 |
HEAD. A user agent SHOULD NOT automatically redirect a request more than |
3037 |
5 times, since such redirections usually indicate an infinite loop. |
3038 |
|
3039 |
|
3040 |
10.3.1 300 Multiple Choices |
3041 |
|
3042 |
The requested resource is available in one or more variants, each with |
3043 |
their own specific location, and agent-driven negotiation information |
3044 |
(section 12) is being provided so that the user (or user agent) can |
3045 |
select a preferred representation. |
3046 |
|
3047 |
Unless it was a HEAD request, the response SHOULD include an entity |
3048 |
containing a list of resource characteristics and location(s) from which |
3049 |
the user or user agent can choose the one most appropriate. The entity |
3050 |
format is specified by the media type given in the Content-Type header |
3051 |
field. Depending upon the format and the capabilities of the user agent, |
3052 |
selection of the most appropriate choice may be performed automatically. |
3053 |
|
3054 |
|
3055 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 52] |
3056 |
|
3057 |
|
3058 |
|
3059 |
|
3060 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3061 |
|
3062 |
|
3063 |
However, this specification does not define any standard for such |
3064 |
automatic selection. |
3065 |
|
3066 |
If the server has a preferred choice of representation, it SHOULD |
3067 |
include the specific URL for that representation in the Location field; |
3068 |
user agents MAY use the Location field value for automatic redirection. |
3069 |
This response is cachable unless indicated otherwise. |
3070 |
|
3071 |
|
3072 |
10.3.2 301 Moved Permanently |
3073 |
|
3074 |
The requested resource has been assigned a new permanent URI and any |
3075 |
future references to this resource SHOULD be done using one of the |
3076 |
returned URIs. Clients with link editing capabilities SHOULD |
3077 |
automatically re-link references to the Request-URI to one or more of |
3078 |
the new references returned by the server, where possible. This response |
3079 |
is cachable unless indicated otherwise. |
3080 |
|
3081 |
If the new URI is a location, its URL SHOULD be given by the Location |
3082 |
field in the response. Unless the request method was HEAD, the entity of |
3083 |
the response SHOULD contain a short hypertext note with a hyperlink to |
3084 |
the new URI(s). |
3085 |
|
3086 |
If the 301 status code is received in response to a request other than |
3087 |
GET or HEAD, the user agent MUST NOT automatically redirect the request |
3088 |
unless it can be confirmed by the user, since this might change the |
3089 |
conditions under which the request was issued. |
3090 |
|
3091 |
Note: When automatically redirecting a POST request after receiving |
3092 |
a 301 status code, some existing HTTP/1.0 user agents will |
3093 |
erroneously change it into a GET request. |
3094 |
|
3095 |
|
3096 |
10.3.3 302 Moved Temporarily |
3097 |
|
3098 |
The requested resource resides temporarily under a different URI. Since |
3099 |
the redirection may be altered on occasion, the client SHOULD continue |
3100 |
to use the Request-URI for future requests. This response is only |
3101 |
cachable if indicated by a Cache-Control or Expires header field. |
3102 |
|
3103 |
If the new URI is a location, its URL SHOULD be given by the Location |
3104 |
field in the response. Unless the request method was HEAD, the entity of |
3105 |
the response SHOULD contain a short hypertext note with a hyperlink to |
3106 |
the new URI(s). |
3107 |
|
3108 |
If the 302 status code is received in response to a request other than |
3109 |
GET or HEAD, the user agent MUST NOT automatically redirect the request |
3110 |
unless it can be confirmed by the user, since this might change the |
3111 |
conditions under which the request was issued. |
3112 |
|
3113 |
|
3114 |
|
3115 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 53] |
3116 |
|
3117 |
|
3118 |
|
3119 |
|
3120 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3121 |
|
3122 |
|
3123 |
Note: When automatically redirecting a POST request after receiving |
3124 |
a 302 status code, some existing HTTP/1.0 user agents will |
3125 |
erroneously change it into a GET request. |
3126 |
|
3127 |
|
3128 |
10.3.4 303 See Other |
3129 |
|
3130 |
The response to the request can be found under a different URI and |
3131 |
SHOULD be retrieved using a GET method on that resource. This method |
3132 |
exists primarily to allow the output of a POST-activated script to |
3133 |
redirect the user agent to a selected resource. The new URI is not a |
3134 |
substitute reference for the originally requested resource. The 303 |
3135 |
response is not cachable, but the response to the second (redirected) |
3136 |
request MAY be cachable. |
3137 |
|
3138 |
If the new URI is a location, its URL SHOULD be given by the Location |
3139 |
field in the response. Unless the request method was HEAD, the entity of |
3140 |
the response SHOULD contain a short hypertext note with a hyperlink to |
3141 |
the new URI(s). |
3142 |
|
3143 |
|
3144 |
10.3.5 304 Not Modified |
3145 |
|
3146 |
If the client has performed a conditional GET request and access is |
3147 |
allowed, but the document has not been modified, the server SHOULD |
3148 |
respond with this status code. The response MUST NOT contain a message- |
3149 |
body. Header fields contained in the response MUST include any values |
3150 |
that, if an unconditional request had been made, might be different from |
3151 |
values sent with any prior response for the entity The response MUST |
3152 |
also include any values that caches use for matching requests and |
3153 |
responses with cache entries. The response SHOULD NOT include header |
3154 |
fields whose values cannot possibly have changed, such as Content-Type. |
3155 |
Examples of relevant header fields include: Date, Server, Content- |
3156 |
Length, Content-MD5, Content-Version, Cache-Control, ETag, Vary and |
3157 |
Expires. |
3158 |
|
3159 |
If a 304 response indicates an entity not currently cached, then the |
3160 |
cache MUST disregard the response and repeat the request without the |
3161 |
conditional. |
3162 |
|
3163 |
If a cache uses a received 304 response to update a cache entry, the |
3164 |
cache MUST update the entry to reflect any new field values given in the |
3165 |
response. |
3166 |
|
3167 |
The 304 response MUST NOT include an message-body, and thus is always |
3168 |
terminated by the first empty line after the header fields. |
3169 |
|
3170 |
|
3171 |
|
3172 |
|
3173 |
|
3174 |
|
3175 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 54] |
3176 |
|
3177 |
|
3178 |
|
3179 |
|
3180 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3181 |
|
3182 |
|
3183 |
10.3.6 305 Use Proxy |
3184 |
|
3185 |
The requested resource MUST be accessed through the proxy given by the |
3186 |
Location field. The Location field gives the URL of the proxy. The |
3187 |
recipient is expected to repeat the request via the proxy. |
3188 |
|
3189 |
|
3190 |
10.4 Client Error 4xx |
3191 |
|
3192 |
The 4xx class of status code is intended for cases in which the client |
3193 |
seems to have erred. Except when responding to a HEAD request, the |
3194 |
server SHOULD include an entity containing an explanation of the error |
3195 |
situation, and whether it is a temporary or permanent condition. These |
3196 |
status codes are applicable to any request method. User agents SHOULD |
3197 |
display any included entity to the user. |
3198 |
|
3199 |
Note: If the client is sending data, a server implementation using |
3200 |
TCP should be careful to ensure that the client acknowledges |
3201 |
receipt of the packet(s) containing the response, before the server |
3202 |
closes the input connection. If the client continues sending data |
3203 |
to the server after the close, the server's TCP stack will send a |
3204 |
reset packet to the client, which may erase the client's |
3205 |
unacknowledged input buffers before they can be read and |
3206 |
interpreted by the HTTP application. |
3207 |
|
3208 |
|
3209 |
10.4.1 400 Bad Request |
3210 |
|
3211 |
The request could not be understood by the server due to malformed |
3212 |
syntax. The client SHOULD NOT repeat the request without modifications. |
3213 |
|
3214 |
|
3215 |
10.4.2 401 Unauthorized |
3216 |
|
3217 |
The request requires user authentication. The response MUST include a |
3218 |
WWW-Authenticate header field (section 14.43) containing a challenge |
3219 |
applicable to the requested resource. The client MAY repeat the request |
3220 |
with a suitable Authorization header field (section 14.8). If the |
3221 |
request already included Authorization credentials, then the 401 |
3222 |
response indicates that authorization has been refused for those |
3223 |
credentials. If the 401 response contains the same challenge as the |
3224 |
prior response, and the user agent has already attempted authentication |
3225 |
at least once, then the user SHOULD be presented the entity that was |
3226 |
given in the response, since that entity MAY include relevant diagnostic |
3227 |
information. HTTP access authentication is explained in section 11. |
3228 |
|
3229 |
|
3230 |
10.4.3 402 Payment Required |
3231 |
|
3232 |
This code is reserved for future use. |
3233 |
|
3234 |
|
3235 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 55] |
3236 |
|
3237 |
|
3238 |
|
3239 |
|
3240 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3241 |
|
3242 |
|
3243 |
10.4.4 403 Forbidden |
3244 |
|
3245 |
The server understood the request, but is refusing to fulfill it. |
3246 |
Authorization will not help and the request SHOULD NOT be repeated. If |
3247 |
the request method was not HEAD and the server wishes to make public why |
3248 |
the request has not been fulfilled, it SHOULD describe the reason for |
3249 |
the refusal in the entity. This status code is commonly used when the |
3250 |
server does not wish to reveal exactly why the request has been refused, |
3251 |
or when no other response is applicable. |
3252 |
|
3253 |
|
3254 |
10.4.5 404 Not Found |
3255 |
|
3256 |
The server has not found anything matching the Request-URI. No |
3257 |
indication is given of whether the condition is temporary or permanent. |
3258 |
If the server does not wish to make this information available to the |
3259 |
client, the status code 403 (Forbidden) can be used instead. The 410 |
3260 |
(Gone) status code SHOULD be used if the server knows, through some |
3261 |
internally configurable mechanism, that an old resource is permanently |
3262 |
unavailable and has no forwarding address. |
3263 |
|
3264 |
|
3265 |
10.4.6 405 Method Not Allowed |
3266 |
|
3267 |
The method specified in the Request-Line is not allowed for the resource |
3268 |
identified by the Request-URI. The response MUST include an Allow header |
3269 |
containing a list of valid methods for the requested resource. |
3270 |
|
3271 |
|
3272 |
10.4.7 406 Not Acceptable |
3273 |
|
3274 |
The resource identified by the request is only capable of generating |
3275 |
response entities which have content characteristics not acceptable |
3276 |
according to the accept headers sent in the request. |
3277 |
|
3278 |
Unless it was a HEAD request, the response SHOULD include an entity |
3279 |
containing a list of available entity characteristics and location(s) |
3280 |
from which the user or user agent can choose the one most appropriate. |
3281 |
The entity format is specified by the media type given in the Content- |
3282 |
Type header field. Depending upon the format and the capabilities of the |
3283 |
user agent, selection of the most appropriate choice may be performed |
3284 |
automatically. However, this specification does not define any standard |
3285 |
for such automatic selection. |
3286 |
|
3287 |
Note: HTTP/1.1 servers are allowed to return responses which are |
3288 |
not acceptable according to the accept headers sent in the request. |
3289 |
In some cases, this may even be preferable to sending a 406 |
3290 |
response. User agents are encouraged to inspect the headers of an |
3291 |
incoming response to determine if it is acceptable. If the response |
3292 |
could be unacceptable, a user agent SHOULD temporarily stop receipt |
3293 |
of more data and query the user for a decision on further actions. |
3294 |
|
3295 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56] |
3296 |
|
3297 |
|
3298 |
|
3299 |
|
3300 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3301 |
|
3302 |
|
3303 |
10.4.8 407 Proxy Authentication Required |
3304 |
|
3305 |
This code is similar to 401 (Unauthorized), but indicates that the |
3306 |
client MUST first authenticate itself with the proxy. The proxy MUST |
3307 |
return a Proxy-Authenticate header field (section 14.33) containing a |
3308 |
challenge applicable to the proxy for the requested resource. The client |
3309 |
MAY repeat the request with a suitable Proxy-Authorization header field |
3310 |
(section 14.34). HTTP access authentication is explained in section 11. |
3311 |
|
3312 |
|
3313 |
10.4.9 408 Request Timeout |
3314 |
|
3315 |
The client did not produce a request within the time that the server was |
3316 |
prepared to wait. The client MAY repeat the request without |
3317 |
modifications at any later time. |
3318 |
|
3319 |
|
3320 |
10.4.10 409 Conflict |
3321 |
|
3322 |
The request could not be completed due to a conflict with the current |
3323 |
state of the resource. This code is only allowed in situations where it |
3324 |
is expected that the user might be able to resolve the conflict and |
3325 |
resubmit the request. The response body SHOULD include enough |
3326 |
information for the user to recognize the source of the conflict. |
3327 |
Ideally, the response entity would include enough information for the |
3328 |
user or user-agent to fix the problem; however, that may not be possible |
3329 |
and is not required. |
3330 |
|
3331 |
Conflicts are most likely to occur in response to a PUT request. If |
3332 |
versioning is being used and the entity being PUT includes changes to a |
3333 |
resource which conflict with those made by an earlier (third-party) |
3334 |
request, the server MAY use the 409 response to indicate that it can't |
3335 |
complete the request. In this case, the response entity SHOULD contain a |
3336 |
list of the differences between the two versions in a format defined by |
3337 |
the response Content-Type. |
3338 |
|
3339 |
|
3340 |
10.4.11 410 Gone |
3341 |
|
3342 |
The requested resource is no longer available at the server and no |
3343 |
forwarding address is known. This condition SHOULD be considered |
3344 |
permanent. Clients with link editing capabilities SHOULD delete |
3345 |
references to the Request-URI after user approval. If the server does |
3346 |
not know, or has no facility to determine, whether or not the condition |
3347 |
is permanent, the status code 404 (Not Found) SHOULD be used instead. |
3348 |
This response is cachable unless indicated otherwise. |
3349 |
|
3350 |
The 410 response is primarily intended to assist the task of web |
3351 |
maintenance by notifying the recipient that the resource is |
3352 |
intentionally unavailable and that the server owners desire that remote |
3353 |
links to that resource be removed. Such an event is common for limited- |
3354 |
|
3355 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 57] |
3356 |
|
3357 |
|
3358 |
|
3359 |
|
3360 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3361 |
|
3362 |
|
3363 |
time, promotional services and for resources belonging to individuals no |
3364 |
longer working at the server's site. It is not necessary to mark all |
3365 |
permanently unavailable resources as "gone" or to keep the mark for any |
3366 |
length of time -- that is left to the discretion of the server owner. |
3367 |
|
3368 |
|
3369 |
10.4.12 411 Length Required |
3370 |
|
3371 |
The server refuses to accept the request without a defined Content- |
3372 |
Length. The client MAY repeat the request if it adds a valid Content- |
3373 |
Length header field containing the length of the message-body in the |
3374 |
request message. |
3375 |
|
3376 |
|
3377 |
10.4.13 412 Precondition Failed |
3378 |
|
3379 |
The precondition given in one or more of the request-header fields |
3380 |
evaluated to false when it was tested on the server. This response code |
3381 |
allows the client to place preconditions on the current resource |
3382 |
metainformation (header field data) and thus prevent the requested |
3383 |
method from being applied to a resource other than the one intended. |
3384 |
|
3385 |
|
3386 |
10.4.14 413 Request Entity Too Large |
3387 |
|
3388 |
The server is refusing to process a request because the request entity |
3389 |
is larger than the server is willing or able to process. The server may |
3390 |
close the connection to prevent the client from continuing the request. |
3391 |
|
3392 |
If the condition is temporary, the server SHOULD include a Retry-After |
3393 |
header field to indicate that it is temporary and after what time the |
3394 |
client may try again. |
3395 |
|
3396 |
|
3397 |
10.4.15 414 Request-URI Too Long |
3398 |
|
3399 |
The server is refusing to service the request because the Request-URI is |
3400 |
longer than the server is willing to interpret. This rare condition is |
3401 |
only likely to occur when a client has improperly converted a POST |
3402 |
request to a GET request with long query information, when the client |
3403 |
has descended into a URL "black hole" of redirection (e.g., a redirected |
3404 |
URL prefix that points to a suffix of itself), or when the server is |
3405 |
under attack by a client attempting to exploit security holes present in |
3406 |
some servers using fixed-length buffers for reading or manipulating the |
3407 |
Request-URI. |
3408 |
|
3409 |
|
3410 |
|
3411 |
|
3412 |
|
3413 |
|
3414 |
|
3415 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 58] |
3416 |
|
3417 |
|
3418 |
|
3419 |
|
3420 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3421 |
|
3422 |
|
3423 |
10.4.16 415 Unsupported Media Type |
3424 |
|
3425 |
The server is refusing to service the request because the entity of the |
3426 |
request is in a format not supported by the requested resource for the |
3427 |
requested method. |
3428 |
|
3429 |
|
3430 |
10.5 Server Error 5xx |
3431 |
|
3432 |
Response status codes beginning with the digit "5" indicate cases in |
3433 |
which the server is aware that it has erred or is incapable of |
3434 |
performing the request. Except when responding to a HEAD request, the |
3435 |
server SHOULD include an entity containing an explanation of the error |
3436 |
situation, and whether it is a temporary or permanent condition. User |
3437 |
agents SHOULD display any included entity to the user. These response |
3438 |
codes are applicable to any request method. |
3439 |
|
3440 |
|
3441 |
10.5.1 500 Internal Server Error |
3442 |
|
3443 |
The server encountered an unexpected condition which prevented it from |
3444 |
fulfilling the request. |
3445 |
|
3446 |
|
3447 |
10.5.2 501 Not Implemented |
3448 |
|
3449 |
The server does not support the functionality required to fulfill the |
3450 |
request. This is the appropriate response when the server does not |
3451 |
recognize the request method and is not capable of supporting it for any |
3452 |
resource. |
3453 |
|
3454 |
|
3455 |
10.5.3 502 Bad Gateway |
3456 |
|
3457 |
The server, while acting as a gateway or proxy, received an invalid |
3458 |
response from the upstream server it accessed in attempting to fulfill |
3459 |
the request. |
3460 |
|
3461 |
|
3462 |
10.5.4 503 Service Unavailable |
3463 |
|
3464 |
The server is currently unable to handle the request due to a temporary |
3465 |
overloading or maintenance of the server. The implication is that this |
3466 |
is a temporary condition which will be alleviated after some delay. If |
3467 |
known, the length of the delay may be indicated in a Retry-After header. |
3468 |
If no Retry-After is given, the client SHOULD handle the response as it |
3469 |
would for a 500 response. |
3470 |
|
3471 |
Note: The existence of the 503 status code does not imply that a |
3472 |
server must use it when becoming overloaded. Some servers may wish |
3473 |
to simply refuse the connection. |
3474 |
|
3475 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 59] |
3476 |
|
3477 |
|
3478 |
|
3479 |
|
3480 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3481 |
|
3482 |
|
3483 |
10.5.5 504 Gateway Timeout |
3484 |
|
3485 |
The server, while acting as a gateway or proxy, did not receive a timely |
3486 |
response from the upstream server it accessed in attempting to complete |
3487 |
the request. |
3488 |
|
3489 |
|
3490 |
10.5.6 505 HTTP Version Not Supported |
3491 |
|
3492 |
The server does not support, or refuses to support, the HTTP protocol |
3493 |
version that was used in the request message. The server is indicating |
3494 |
that it is unable or unwilling to complete the request using the same |
3495 |
major version as the client, as described in section 3.1, other than |
3496 |
with this error message. The response SHOULD contain an entity |
3497 |
describing why that version is not supported and what other protocols |
3498 |
are supported by that server. |
3499 |
|
3500 |
|
3501 |
11 Access Authentication |
3502 |
|
3503 |
HTTP provides a simple challenge-response authentication mechanism which |
3504 |
MAY be used by a server to challenge a client request and by a client to |
3505 |
provide authentication information. It uses an extensible, case- |
3506 |
insensitive token to identify the authentication scheme, followed by a |
3507 |
comma-separated list of attribute-value pairs which carry the parameters |
3508 |
necessary for achieving authentication via that scheme. |
3509 |
|
3510 |
auth-scheme = token |
3511 |
|
3512 |
auth-param = token "=" quoted-string |
3513 |
|
3514 |
The 401 (Unauthorized) response message is used by an origin server to |
3515 |
challenge the authorization of a user agent. This response MUST include |
3516 |
a WWW-Authenticate header field containing at least one challenge |
3517 |
applicable to the requested resource. |
3518 |
|
3519 |
challenge = auth-scheme 1*SP realm *( "," auth-param ) |
3520 |
|
3521 |
realm = "realm" "=" realm-value |
3522 |
realm-value = quoted-string |
3523 |
|
3524 |
The realm attribute (case-insensitive) is required for all |
3525 |
authentication schemes which issue a challenge. The realm value (case- |
3526 |
sensitive), in combination with the canonical root URL (see section |
3527 |
5.1.2) of the server being accessed, defines the protection space. These |
3528 |
realms allow the protected resources on a server to be partitioned into |
3529 |
a set of protection spaces, each with its own authentication scheme |
3530 |
and/or authorization database. The realm value is a string, generally |
3531 |
assigned by the origin server, which may have additional semantics |
3532 |
specific to the authentication scheme. |
3533 |
|
3534 |
|
3535 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 60] |
3536 |
|
3537 |
|
3538 |
|
3539 |
|
3540 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3541 |
|
3542 |
|
3543 |
A user agent that wishes to authenticate itself with a server--usually, |
3544 |
but not necessarily, after receiving a 401 or 411 response--MAY do so by |
3545 |
including an Authorization header field with the request. The |
3546 |
Authorization field value consists of credentials containing the |
3547 |
authentication information of the user agent for the realm of the |
3548 |
resource being requested. |
3549 |
|
3550 |
credentials = basic-credentials |
3551 |
| auth-scheme #auth-param |
3552 |
|
3553 |
The domain over which credentials can be automatically applied by a user |
3554 |
agent is determined by the protection space. If a prior request has been |
3555 |
authorized, the same credentials MAY be reused for all other requests |
3556 |
within that protection space for a period of time determined by the |
3557 |
authentication scheme, parameters, and/or user preference. Unless |
3558 |
otherwise defined by the authentication scheme, a single protection |
3559 |
space cannot extend outside the scope of its server. |
3560 |
|
3561 |
If the server does not wish to accept the credentials sent with a |
3562 |
request, it SHOULD return a 401 (Unauthorized) response. The response |
3563 |
MUST include a WWW-Authenticate header field containing the (possibly |
3564 |
new) challenge applicable to the requested resource and an entity |
3565 |
explaining the refusal. |
3566 |
|
3567 |
The HTTP protocol does not restrict applications to this simple |
3568 |
challenge-response mechanism for access authentication. Additional |
3569 |
mechanisms MAY be used, such as encryption at the transport level or via |
3570 |
message encapsulation, and with additional header fields specifying |
3571 |
authentication information. However, these additional mechanisms are not |
3572 |
defined by this specification. |
3573 |
|
3574 |
Proxies MUST be completely transparent regarding user agent |
3575 |
authentication. That is, they MUST forward the WWW-Authenticate and |
3576 |
Authorization headers untouched, and follow the rules found in section |
3577 |
14.8. |
3578 |
|
3579 |
HTTP/1.1 allows a client to pass authentication information to and from |
3580 |
a proxy via the Proxy-Authenticate and Proxy-Authorization headers. |
3581 |
|
3582 |
|
3583 |
11.1 Basic Authentication Scheme |
3584 |
|
3585 |
The "basic" authentication scheme is based on the model that the user |
3586 |
agent must authenticate itself with a user-ID and a password for each |
3587 |
realm. The realm value should be considered an opaque string which can |
3588 |
only be compared for equality with other realms on that server. The |
3589 |
server will service the request only if it can validate the user-ID and |
3590 |
password for the protection space of the Request-URI. There are no |
3591 |
optional authentication parameters. |
3592 |
|
3593 |
|
3594 |
|
3595 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 61] |
3596 |
|
3597 |
|
3598 |
|
3599 |
|
3600 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3601 |
|
3602 |
|
3603 |
Upon receipt of an unauthorized request for a URI within the protection |
3604 |
space, the server MAY respond with a challenge like the following: |
3605 |
|
3606 |
WWW-Authenticate: Basic realm="WallyWorld" |
3607 |
|
3608 |
where "WallyWorld" is the string assigned by the server to identify the |
3609 |
protection space of the Request-URI. |
3610 |
|
3611 |
To receive authorization, the client sends the userid and password, |
3612 |
separated by a single colon (":") character, within a base64 encoded |
3613 |
string in the credentials. |
3614 |
|
3615 |
basic-credentials = "Basic" SP basic-cookie |
3616 |
|
3617 |
basic-cookie = <base64 [7] encoding of user-pass, |
3618 |
except not limited to 76 char/line> |
3619 |
|
3620 |
user-pass = userid ":" password |
3621 |
|
3622 |
userid = *<TEXT excluding ":"> |
3623 |
|
3624 |
password = *TEXT |
3625 |
|
3626 |
Userids might be case sensitive. |
3627 |
|
3628 |
If the user agent wishes to send the userid "Aladdin" and password "open |
3629 |
sesame", it would use the following header field: |
3630 |
|
3631 |
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
3632 |
|
3633 |
See section 15 for security considerations associated with Basic |
3634 |
authentication. |
3635 |
|
3636 |
|
3637 |
11.2 Digest Authentication Scheme |
3638 |
|
3639 |
Note for the RFC editor: This section is reserved for including the |
3640 |
Digest Authentication specification, or if the RFC editor chooses to |
3641 |
issue a single RFC rather than two RFC's, this section should be |
3642 |
deleted. |
3643 |
|
3644 |
|
3645 |
12 Content Negotiation |
3646 |
|
3647 |
Most HTTP responses include an entity which contains information for |
3648 |
interpretation by a human user. Naturally, it is desirable to supply the |
3649 |
user with the "best available" entity corresponding to the request. |
3650 |
Unfortunately for servers and caches, not all users have the same |
3651 |
preferences for what is "best," and not all user agents are equally |
3652 |
capable of rendering all entity types. For that reason, HTTP has |
3653 |
provisions for several mechanisms for "content negotiation" -- the |
3654 |
|
3655 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 62] |
3656 |
|
3657 |
|
3658 |
|
3659 |
|
3660 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3661 |
|
3662 |
|
3663 |
process of selecting the best representation for a given response when |
3664 |
there are multiple representations available. |
3665 |
|
3666 |
Note: This is not called "format negotiation" because the alternate |
3667 |
representations may be of the same media type, but use different |
3668 |
capabilities of that type, be in different languages, etc. |
3669 |
|
3670 |
Any response containing an entity-body MAY be subject to negotiation, |
3671 |
including error responses. |
3672 |
|
3673 |
There are two kinds of content negotiation which are possible in HTTP: |
3674 |
server-driven and agent-driven negotiation. These two kinds of |
3675 |
negotiation are orthogonal and thus may be used separately or in |
3676 |
combination. One method of combination, referred to as transparent |
3677 |
negotiation, occurs when a cache uses the agent-driven negotiation |
3678 |
information provided by the origin server in order to provide server- |
3679 |
driven negotiation for subsequent requests. |
3680 |
|
3681 |
|
3682 |
12.1 Server-driven Negotiation |
3683 |
|
3684 |
If the selection of the best representation for a response is made by an |
3685 |
algorithm located at the server, it is called server-driven negotiation. |
3686 |
Selection is based on the available representations of the response (the |
3687 |
dimensions over which it can vary; e.g. language, content-coding, etc.) |
3688 |
and the contents of particular header fields in the request message or |
3689 |
on other information pertaining to the request (such as the network |
3690 |
address of the client). |
3691 |
|
3692 |
Server-driven negotiation is advantageous when the algorithm for |
3693 |
selecting from among the available representations is difficult to |
3694 |
describe to the user agent, or when the server desires to send its "best |
3695 |
guess" to the client along with the first response (hoping to avoid the |
3696 |
round-trip delay of a subsequent request if the "best guess" is good |
3697 |
enough for the user). In order to improve the server's guess, the user |
3698 |
agent MAY include request header fields (Accept, Accept-Language, |
3699 |
Accept-Encoding, etc.) which describe its preferences for such a |
3700 |
response. |
3701 |
|
3702 |
Server-driven negotiation has disadvantages: |
3703 |
|
3704 |
1. It is impossible for the server to accurately determine what might be |
3705 |
"best" for any given user, since that would require complete |
3706 |
knowledge of both the capabilities of the user agent and the intended |
3707 |
use for the response (e.g., does the user want to view it on screen |
3708 |
or print it on paper?). |
3709 |
|
3710 |
2. Having the user agent describe its capabilities in every request can |
3711 |
be both very inefficient (given that only a small percentage of |
3712 |
responses have multiple representations) and a potential violation of |
3713 |
the user's privacy. |
3714 |
|
3715 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 63] |
3716 |
|
3717 |
|
3718 |
|
3719 |
|
3720 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3721 |
|
3722 |
|
3723 |
3. It complicates the implementation of an origin server and the |
3724 |
algorithms for generating responses to a request. |
3725 |
|
3726 |
4. It may limit a public cache's ability to use the same response for |
3727 |
multiple user's requests. |
3728 |
|
3729 |
HTTP/1.1 includes the following request-header fields for enabling |
3730 |
server-driven negotiation through description of user agent capabilities |
3731 |
and user preferences: Accept (section 14.1), Accept-Charset (section |
3732 |
14.2), Accept-Encoding (section 14.3), Accept-Language (section 14.4), |
3733 |
and User-Agent (section 14.42). However, an origin server is not limited |
3734 |
to these dimensions and MAY vary the response based on any aspect of the |
3735 |
request, including information outside the request-header fields or |
3736 |
within extension header fields not defined by this specification. |
3737 |
|
3738 |
HTTP/1.1 origin servers MUST include an appropriate Vary header field |
3739 |
(section 14.43) in any response based on server-driven negotiation. The |
3740 |
Vary header field describes the dimensions over which the response might |
3741 |
vary (i.e. the dimensions over which the origin server picks its "best |
3742 |
guess" response from multiple representations). |
3743 |
|
3744 |
HTTP/1.1 public caches MUST recognize the Vary header field when it is |
3745 |
included in a response and obey the requirements described in section |
3746 |
13.5 that describes the interactions between caching and content |
3747 |
negotiation. |
3748 |
|
3749 |
|
3750 |
12.2 Agent-driven Negotiation |
3751 |
|
3752 |
With agent-driven negotiation, selection of the best representation for |
3753 |
a response is performed by the user agent after receiving an initial |
3754 |
response from the origin server. Selection is based on a list of the |
3755 |
available representations of the response included within the header |
3756 |
fields (this specification reserves the keyword Alternates, to be |
3757 |
defined in a separate specification [27]) or entity-body of the initial |
3758 |
response, with each representation identified by its own URI. Selection |
3759 |
from among the representations may be performed automatically (if the |
3760 |
user agent is capable of doing so) or manually by the user selecting |
3761 |
from a generated (possibly hypertext) menu. |
3762 |
|
3763 |
Agent-driven negotiation is advantageous when the response would vary |
3764 |
over commonly-used dimensions (such as type, language, or encoding), |
3765 |
when the origin server is unable to determine a user agent's |
3766 |
capabilities from examining the request, and generally when public |
3767 |
caches are used to distribute server load and reduce network usage. |
3768 |
|
3769 |
Agent-driven negotiation suffers from the disadvantage of needing a |
3770 |
second request to obtain the best alternate representation. This second |
3771 |
request is only efficient when caching is used. In addition, this |
3772 |
specification does not define any mechanism for supporting automatic |
3773 |
|
3774 |
|
3775 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 64] |
3776 |
|
3777 |
|
3778 |
|
3779 |
|
3780 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3781 |
|
3782 |
|
3783 |
selection, though it also does not prevent any such mechanism from being |
3784 |
developed as an extension and used within HTTP/1.1. |
3785 |
|
3786 |
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) |
3787 |
status codes for enabling agent-driven negotiation when the server is |
3788 |
unwilling or unable to provide a varying response using server-driven |
3789 |
negotiation. |
3790 |
|
3791 |
|
3792 |
12.3 Transparent Negotiation |
3793 |
|
3794 |
Transparent negotiation is a combination of both server-driven and |
3795 |
agent-driven negotiation. When a cache is supplied with a form of the |
3796 |
list of available representations of the response (as in agent-driven |
3797 |
negotiation) and the dimensions of variance are completely understood by |
3798 |
the cache, then the cache becomes capable of performing server-driven |
3799 |
negotiation on behalf of the origin server for subsequent requests on |
3800 |
that resource. |
3801 |
|
3802 |
Transparent negotiation has the advantage of distributing the |
3803 |
negotiation work that would otherwise be required of the origin server |
3804 |
and also removing the second request delay of agent-driven negotiation |
3805 |
when the cache is able to correctly guess the right response. |
3806 |
|
3807 |
This specification does not define any mechanism for transparent |
3808 |
negotiation, though it also does not prevent any such mechanism from |
3809 |
being developed as an extension and used within HTTP/1.1. An HTTP/1.1 |
3810 |
cache performing transparent negotiation MUST include a Vary header |
3811 |
field in the response (defining the dimensions of its variance) to |
3812 |
ensure correct interoperation with all HTTP/1.1 clients. The agent- |
3813 |
driven negotiation information supplied by the origin server SHOULD be |
3814 |
included with the transparently negotiated response. |
3815 |
|
3816 |
|
3817 |
13 Caching in HTTP |
3818 |
|
3819 |
HTTP is typically used for distributed information systems, where |
3820 |
performance can be improved by the use of response caches. The HTTP/1.1 |
3821 |
protocol includes a number of elements intended to make caching work as |
3822 |
well as possible. Because these elements are inextricable from other |
3823 |
aspects of the protocol, and because they interact with each other, it |
3824 |
is useful to describe the basic caching design of HTTP separately from |
3825 |
the detailed descriptions of methods, headers, response codes, etc. |
3826 |
|
3827 |
Caching would be useless if it did not significantly improve |
3828 |
performance. The goal of caching in HTTP/1.1 is to eliminate the need to |
3829 |
send requests in many cases, and to eliminate the need to send full |
3830 |
responses in many other cases. The former reduces the number of network |
3831 |
round-trips required for many operations; we use an "expiration" |
3832 |
mechanism for this purpose (see section 13.2). The latter reduces |
3833 |
|
3834 |
|
3835 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 65] |
3836 |
|
3837 |
|
3838 |
|
3839 |
|
3840 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3841 |
|
3842 |
|
3843 |
network bandwidth requirements; we use a "validation" mechanism for this |
3844 |
purpose (see section 13.3). |
3845 |
|
3846 |
Requirements for performance, availability, and disconnected operation |
3847 |
require us to be able to relax the goal of semantic transparency. The |
3848 |
HTTP/1.1 protocol allows origin servers, caches, and clients to |
3849 |
explicitly reduce transparency when necessary. However, because non- |
3850 |
transparent operation may confuse non-expert users, and may be |
3851 |
incompatible with certain server applications (such as those for |
3852 |
ordering merchandise), the protocol requires that transparency may be |
3853 |
relaxed |
3854 |
|
3855 |
. only by an explicit protocol-level request when relaxed by client |
3856 |
or origin server |
3857 |
. only with an explicit warning to the end user when relaxed by cache |
3858 |
or client |
3859 |
Therefore, the HTTP/1.1 protocol provides these important elements: |
3860 |
|
3861 |
1. Protocol features that provide full semantic transparency when this |
3862 |
is required by all parties. |
3863 |
2. Protocol features that allow an origin server or end-user client to |
3864 |
explicitly request and control non-transparent operation. |
3865 |
3. Protocol features that allow a cache to attach warnings to |
3866 |
responses that do not preserve the requested approximation of |
3867 |
semantic transparency. |
3868 |
A basic principle is that it must be possible for the clients to detect |
3869 |
any potential relaxation of semantic transparency. |
3870 |
|
3871 |
Note: The server, cache, or client implementer may be faced with |
3872 |
design decisions not explicitly discussed in this specification. If |
3873 |
a decision may affect semantic transparency, the implementer ought |
3874 |
to err on the side of maintaining transparency unless a careful and |
3875 |
complete analysis shows significant benefits in breaking |
3876 |
transparency. |
3877 |
|
3878 |
|
3879 |
13.1.1 Cache Correctness |
3880 |
|
3881 |
If the cache can communicate with the origin-server, then a correct |
3882 |
cache MUST respond to a request with a response that meets one of the |
3883 |
following conditions: |
3884 |
|
3885 |
1. Its end-to-end headers (see section 13.4.1) and entity-body value |
3886 |
are equivalent to what the server would have returned for that |
3887 |
request if the resource had not been modified since the response |
3888 |
was cached, by revalidating the response with the origin server, if |
3889 |
is not fresh. |
3890 |
2. It is "fresh enough" (see section 13.2). In the default case, this |
3891 |
means it meets the least restrictive freshness requirement of the |
3892 |
client, server, and cache (see section 14.9); if the origin-server |
3893 |
|
3894 |
|
3895 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 66] |
3896 |
|
3897 |
|
3898 |
|
3899 |
|
3900 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3901 |
|
3902 |
|
3903 |
so specifies, it is the freshness requirement of the origin-server |
3904 |
alone. |
3905 |
3. It includes a warning if the freshness demand of the client or the |
3906 |
origin-server is violated (see section 13.1.5 and 14.45). |
3907 |
and it is the most up-to-date response appropriate to the request the |
3908 |
cache has (see section 13.2.5, 13.2.6, and 13.10). |
3909 |
|
3910 |
If the cache can not communicate with the origin server, then a correct |
3911 |
cache SHOULD respond as above if the response can be correctly served |
3912 |
from the cache; if not it MUST return an error or warning indicating |
3913 |
that there was a communication failure. |
3914 |
|
3915 |
|
3916 |
13.1.2 Warnings |
3917 |
|
3918 |
Whenever a cache returns a response that is neither first-hand nor |
3919 |
"fresh enough" (in the sense of condition 2 in 13.1.1), it must attach a |
3920 |
warning to that effect, using a Warning response-header. This warning |
3921 |
allows clients to take appropriate action. |
3922 |
|
3923 |
Warnings may be used for other purposes, both cache-related and |
3924 |
otherwise. The use of a warning, rather than an error status code, |
3925 |
distinguish these responses from true failures. |
3926 |
|
3927 |
Warnings are always cachable, because they never weaken the transparency |
3928 |
of a response. This means that warnings can be passed to HTTP/1.0 caches |
3929 |
without danger; such caches will simply pass the warning along as a |
3930 |
entity-header in the response. |
3931 |
|
3932 |
Warnings are assigned numbers between 0 and 99. This specification |
3933 |
defines the code numbers and meanings of each currently assigned |
3934 |
warnings, allowing a client or cache to take automated action in some |
3935 |
(but not all) cases. |
3936 |
|
3937 |
Warnings also carry a warning text. The text may be in any appropriate |
3938 |
natural language (perhaps based on the client's Accept headers), and |
3939 |
include an optional indication of what character set is used. |
3940 |
|
3941 |
Multiple warnings may be attached to a response (either by the origin |
3942 |
server or by a cache), including multiple warnings with the same code |
3943 |
number. For example, a server may provide the same warning with texts in |
3944 |
both English and Basque. |
3945 |
|
3946 |
When multiple warnings are attached to a response, it may not be |
3947 |
practical or reasonable to display all of them to the user. This version |
3948 |
of HTTP does not specify strict priority rules for deciding which |
3949 |
warnings to display and in what order, but does suggest some heuristics. |
3950 |
|
3951 |
The Warning header and the currently defined warnings are described in |
3952 |
section 14.45. |
3953 |
|
3954 |
|
3955 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 67] |
3956 |
|
3957 |
|
3958 |
|
3959 |
|
3960 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
3961 |
|
3962 |
|
3963 |
13.1.3 Cache-control Mechanisms |
3964 |
|
3965 |
The basic cache mechanisms in HTTP/1.1 (server-specified expiration |
3966 |
times and validators) are implicit directives to caches. In some cases, |
3967 |
a server or client may need to provide explicit directives to the HTTP |
3968 |
caches. We use the Cache-Control header for this purpose. |
3969 |
|
3970 |
The Cache-Control header allows a client or server to transmit a variety |
3971 |
of directives in either requests or responses. These directives |
3972 |
typically override the default caching algorithms. As a general rule, if |
3973 |
there is any apparent conflict between header values, the most |
3974 |
restrictive interpretation should be applied (that is, the one that is |
3975 |
most likely to preserve semantic transparency). However, in some cases, |
3976 |
Cache-Control directives are explicitly specified as weakening the |
3977 |
approximation of semantic transparency (for example, "max-stale" or |
3978 |
"public"). |
3979 |
|
3980 |
The Cache-Control directives are described in detail in section 14.9. |
3981 |
|
3982 |
|
3983 |
13.1.4 Explicit User Agent Warnings |
3984 |
|
3985 |
Many user agents make it possible for users to override the basic |
3986 |
caching mechanisms. For example, the user agent may allow the user to |
3987 |
specify that cached entities (even explicitly stale ones) are never |
3988 |
validated. Or the user agent might habitually add "Cache-Control: max- |
3989 |
stale=3600" or "Cache-Control: reload" to every request. The user should |
3990 |
have to explicitly request either non-transparent behavior, or behavior |
3991 |
that results in abnormally ineffective caching. |
3992 |
|
3993 |
If the user has overridden the basic caching mechanisms, the user agent |
3994 |
should explicitly indicate to the user whenever this results in the |
3995 |
display of information that might not meet the server's transparency |
3996 |
requirements (in particular, if the displayed entity is known to be |
3997 |
stale). Since the protocol normally allows the user agent to determine |
3998 |
if responses are stale or not, this indication need only be displayed |
3999 |
when this actually happens. The indication need not be a dialog box; it |
4000 |
could be an icon (for example, a picture of a rotting fish) or some |
4001 |
other visual indicator. |
4002 |
|
4003 |
If the user has overridden the caching mechanisms in a way that would |
4004 |
abnormally reduce the effectiveness of caches, the user agent should |
4005 |
continually display an indication (for example, a picture of currency in |
4006 |
flames) so that the user does not inadvertently consume excess resources |
4007 |
or suffer from excessive latency. |
4008 |
|
4009 |
|
4010 |
13.1.5 Exceptions to the Rules and Warnings |
4011 |
|
4012 |
In some cases, the operator of a cache may choose to configure it to |
4013 |
return stale responses even when not requested by clients. This decision |
4014 |
|
4015 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 68] |
4016 |
|
4017 |
|
4018 |
|
4019 |
|
4020 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4021 |
|
4022 |
|
4023 |
should not be made lightly, but may be necessary for reasons of |
4024 |
availability or performance, especially when the cache is poorly |
4025 |
connected to the origin server. Whenever a cache returns a stale |
4026 |
response, it MUST mark it as such (using a Warning header). This allows |
4027 |
the client software to alert the user that there may be a potential |
4028 |
problem. |
4029 |
|
4030 |
It also allows the user to take steps to obtain a first-hand or fresh |
4031 |
response. For this reason, a cache SHOULD NOT return a stale response if |
4032 |
the client explicitly requests a first-hand or fresh one, unless it is |
4033 |
impossible to comply for technical or policy reasons. |
4034 |
|
4035 |
|
4036 |
13.1.6 Client-controlled Behavior |
4037 |
|
4038 |
While the origin server (and to a lesser extent, intermediate caches, by |
4039 |
their contribution to the age of a response) are the primary source of |
4040 |
expiration information, in some cases the client may need to control a |
4041 |
cache's decision about whether to return a cached response without |
4042 |
validating it. Clients do this using several directives of the Cache- |
4043 |
Control header. |
4044 |
|
4045 |
A client's request may specify the maximum age it is willing to accept |
4046 |
of an unvalidated response; specifying a value of zero forces the |
4047 |
cache(s) to revalidate all responses. A client may also specify the |
4048 |
minimum time remaining before a response expires. Both of these options |
4049 |
increase constraints on the behavior of caches, and so cannot further |
4050 |
relax the cache's approximation of semantic transparency. |
4051 |
|
4052 |
A client may also specify that it will accept stale responses, up to |
4053 |
some maximum amount of staleness. This loosens the constraints on the |
4054 |
caches, and so may violate the origin server's specified constraints on |
4055 |
semantic transparency, but may be necessary to support disconnected |
4056 |
operation, or high availability in the face of poor connectivity. |
4057 |
|
4058 |
|
4059 |
13.2 Expiration Model |
4060 |
|
4061 |
|
4062 |
13.2.1 Server-Specified Expiration |
4063 |
|
4064 |
HTTP caching works best when caches can entirely avoid making requests |
4065 |
to the origin server. The primary mechanism for avoiding requests is for |
4066 |
an origin server to provide an explicit expiration time in the future, |
4067 |
indicating that a response may be used to satisfy subsequent requests. |
4068 |
In other words, a cache can return a fresh response without first |
4069 |
contacting the server. |
4070 |
|
4071 |
Our expectation is that servers will assign future explicit expiration |
4072 |
times to responses in the belief that the entity is not likely to |
4073 |
change, in a semantically significant way, before the expiration time is |
4074 |
|
4075 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 69] |
4076 |
|
4077 |
|
4078 |
|
4079 |
|
4080 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4081 |
|
4082 |
|
4083 |
reached. This normally preserves semantic transparency, as long as the |
4084 |
server's expiration times are carefully chosen. |
4085 |
|
4086 |
The expiration mechanism applies only to responses taken from a cache |
4087 |
and not to first-hand responses forwarded immediately to the requesting |
4088 |
client. |
4089 |
|
4090 |
If an origin server wishes to force a semantically transparent cache to |
4091 |
validate every request, it may assign an explicit expiration time in the |
4092 |
past. This means that the response is always stale, and so the cache |
4093 |
SHOULD validate it before using it for subsequent requests. See section |
4094 |
14.9.4 for a more restrictive way to force revalidation. |
4095 |
|
4096 |
If an origin server wishes to force any HTTP/1.1 cache, no matter how |
4097 |
it is configured, to validate every request, it should use the "must- |
4098 |
revalidate" Cache-Control directive (see section 14.9). |
4099 |
|
4100 |
Servers specify explicit expiration times using either the Expires |
4101 |
header, or the max-age directive of the Cache-Control header. |
4102 |
|
4103 |
An expiration time cannot be used to force a user agent to refresh its |
4104 |
display or reload a resource; its semantics apply only to caching |
4105 |
mechanisms, and such mechanisms need only check a resource's expiration |
4106 |
status when a new request for that resource is initiated. See section |
4107 |
13.11 for explanation of the difference between caches and history |
4108 |
mechanisms. |
4109 |
|
4110 |
|
4111 |
13.2.2 Heuristic Expiration |
4112 |
|
4113 |
Since origin servers do not always provide explicit expiration times, |
4114 |
HTTP caches typically assign heuristic expiration times, employing |
4115 |
algorithms that use other header values (such as the Last-Modified time) |
4116 |
to estimate a plausible expiration time. The HTTP/1.1 specification does |
4117 |
not provide specific algorithms, but does impose worst-case constraints |
4118 |
on their results. Since heuristic expiration times may compromise |
4119 |
semantic transparency, they should be used cautiously, and we encourage |
4120 |
origin servers to provide explicit expiration times as much as possible. |
4121 |
|
4122 |
|
4123 |
13.2.3 Age Calculations |
4124 |
|
4125 |
In order to know if a cached entry is fresh, a cache needs to know if |
4126 |
its age exceeds its freshness lifetime. We discuss how to calculate the |
4127 |
latter in section 13.2.4; this section describes how to calculate the |
4128 |
age of a response or cache entry. |
4129 |
|
4130 |
In this discussion, we use the term "now" to mean "the current value of |
4131 |
the clock at the host performing the calculation." All HTTP |
4132 |
implementations, but especially origin servers and caches, should use |
4133 |
|
4134 |
|
4135 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 70] |
4136 |
|
4137 |
|
4138 |
|
4139 |
|
4140 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4141 |
|
4142 |
|
4143 |
NTP [28] or some similar protocol to synchronize their clocks to a |
4144 |
globally accurate time standard. |
4145 |
|
4146 |
Also note that HTTP/1.1 requires origin servers to send a Date header |
4147 |
with every response, giving the time at which the response was |
4148 |
generated. We use the term "date_value" to denote the value of the Date |
4149 |
header, in a form appropriate for arithmetic operations. |
4150 |
|
4151 |
HTTP/1.1 uses the Age response-header to help convey age information |
4152 |
between caches. The Age header value is the sender's estimate of the |
4153 |
amount of time since the response was generated at the origin server. In |
4154 |
the case of a cached response that has been revalidated with the origin |
4155 |
server, the Age value is based on the time of revalidation, not of the |
4156 |
original response. |
4157 |
|
4158 |
In essence, the Age value is the sum of the time that the response has |
4159 |
been resident in each of the caches along the path from the origin |
4160 |
server, plus the amount of time it has been in transit along network |
4161 |
paths. |
4162 |
|
4163 |
We use the term "age_value" to denote the value of the Age header, in a |
4164 |
form appropriate for arithmetic operations. |
4165 |
|
4166 |
A response's age can be calculated in two entirely independent ways: |
4167 |
|
4168 |
1. now minus date_value, if the local clock is reasonably well |
4169 |
synchronized to the origin server's clock. If the result is |
4170 |
negative, the result is replaced by zero. |
4171 |
2. age_value, if all of the caches along the response path implement |
4172 |
HTTP/1.1. |
4173 |
Given that we have two independent ways to compute the age of a response |
4174 |
when it is received, we can combine these as |
4175 |
|
4176 |
corrected_received_age = max(now - date_value, age_value) |
4177 |
|
4178 |
and as long as we have either nearly synchronized clocks or all-HTTP/1.1 |
4179 |
paths, one gets a reliable (conservative) result. |
4180 |
|
4181 |
Note that this correction is applied at each HTTP/1.1 cache along the |
4182 |
path, so that if there is an HTTP/1.0 cache in the path, the correct |
4183 |
received age is computed as long as the receiving cache's clock is |
4184 |
nearly in sync. We don't need end-to-end clock synchronization (although |
4185 |
it is good to have), and there is no explicit clock synchronization |
4186 |
step. |
4187 |
|
4188 |
Because of network-imposed delays, some significant interval may pass |
4189 |
from the time that a server generates a response and the time it is |
4190 |
received at the next outbound cache or client. If uncorrected, this |
4191 |
delay could result in improperly low ages. |
4192 |
|
4193 |
|
4194 |
|
4195 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 71] |
4196 |
|
4197 |
|
4198 |
|
4199 |
|
4200 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4201 |
|
4202 |
|
4203 |
Because the request that resulted in the returned Age value must have |
4204 |
been initiated prior to that Age value's generation, we can correct for |
4205 |
delays imposed by the network by recording the time at which the request |
4206 |
was initiated. Then, when an Age value is received, it MUST be |
4207 |
interpreted relative to the time the request was initiated, not the time |
4208 |
that the response was received. This algorithm results in conservative |
4209 |
behavior no matter how much delay is experienced. So, we compute: |
4210 |
|
4211 |
corrected_initial_age = corrected_received_age |
4212 |
+ (now - request_time) |
4213 |
|
4214 |
where "request_time" is the time (according to the local clock) when the |
4215 |
request that elicited this response was sent. |
4216 |
|
4217 |
Summary of age calculation algorithm, when a cache receives a response: |
4218 |
|
4219 |
/* |
4220 |
* age_value |
4221 |
* is the value of Age: header received by the cache with |
4222 |
* this response. |
4223 |
* date_value |
4224 |
* is the value of the origin server's Date: header |
4225 |
* request_time |
4226 |
* is the (local) time when the cache made the request |
4227 |
* that resulted in this cached response |
4228 |
* response_time |
4229 |
* is the (local) time when the cache received the |
4230 |
* response |
4231 |
* now |
4232 |
* is the current (local) time |
4233 |
*/ |
4234 |
apparent_age = max(0, response_time - date_value); |
4235 |
corrected_received_age = max(apparent_age, age_value); |
4236 |
response_delay = response_time - request_time; |
4237 |
corrected_initial_age = corrected_received_age + response_delay; |
4238 |
resident_time = now - response_time; |
4239 |
current_age = corrected_initial_age + resident_time; |
4240 |
|
4241 |
When a cache sends a response, it must add to the corrected_initial_age |
4242 |
the amount of time that the response was resident locally. It must then |
4243 |
transmit this total age, using the Age header, to the next recipient |
4244 |
cache. |
4245 |
|
4246 |
Note that a client cannot reliably tell that a response is first- |
4247 |
hand, but the presence of an Age header indicates that a response |
4248 |
is definitely not first-hand. Also, if the Date in a response is |
4249 |
earlier than the client's local request time, the response is |
4250 |
probably not first-hand (in the absence of serious clock skew). |
4251 |
|
4252 |
|
4253 |
|
4254 |
|
4255 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 72] |
4256 |
|
4257 |
|
4258 |
|
4259 |
|
4260 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4261 |
|
4262 |
|
4263 |
13.2.4 Expiration Calculations |
4264 |
|
4265 |
In order to decide whether a response is fresh or stale, we need to |
4266 |
compare its freshness lifetime to its age. The age is calculated as |
4267 |
described in section 13.2.3; this section describes how to calculate the |
4268 |
freshness lifetime, and to determine if a response has expired. In the |
4269 |
discussion below, the values can be represented in any form appropriate |
4270 |
for arithmetic operations. |
4271 |
|
4272 |
We use the term "expires_value" to denote the value of the Expires |
4273 |
header. We use the term "max_age_value" to denote an appropriate value |
4274 |
of the number of seconds carried by the max-age directive of the Cache- |
4275 |
Control header in a response (see section 14.10. |
4276 |
|
4277 |
The max-age directive takes priority over Expires, so if max-age is |
4278 |
present in a response, the calculation is simply: |
4279 |
|
4280 |
freshness_lifetime = max_age_value |
4281 |
|
4282 |
Otherwise, if Expires is present in the response, the calculation is: |
4283 |
|
4284 |
freshness_lifetime = expires_value - date_value |
4285 |
|
4286 |
Note that neither of these calculations is vulnerable to clock skew, |
4287 |
since all of the information comes from the origin server. |
4288 |
|
4289 |
If neither Expires nor Cache-Control: max-age appears in the response, |
4290 |
and the response does not include other restrictions on caching, the |
4291 |
cache MAY compute a freshness lifetime using a heuristic. If the value |
4292 |
is greater than 24 hours, the cache must attach Warning 13 to any |
4293 |
response whose age is more than 24 hours if such warning has not already |
4294 |
been added. |
4295 |
|
4296 |
Also, if the response does have a Last-Modified time, the heuristic |
4297 |
expiration value SHOULD be no more than some fraction of the interval |
4298 |
since that time. A typical setting of this fraction might be 10%. |
4299 |
|
4300 |
The calculation to determine if a response has expired is quite simple: |
4301 |
|
4302 |
response_is_fresh = (freshness_lifetime > current_age) |
4303 |
|
4304 |
|
4305 |
13.2.5 Disambiguating Expiration Values |
4306 |
|
4307 |
Because expiration values are assigned optimistically, it is possible |
4308 |
for two caches to contain fresh values for the same resource that are |
4309 |
different. |
4310 |
|
4311 |
If a client performing a retrieval receives a non-first-hand response |
4312 |
for a request that was already fresh in its own cache, and the Date |
4313 |
header in its existing cache entry is newer than the Date on the new |
4314 |
|
4315 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 73] |
4316 |
|
4317 |
|
4318 |
|
4319 |
|
4320 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4321 |
|
4322 |
|
4323 |
response, then the client MAY ignore the response. If so, it MAY retry |
4324 |
the request with a "Cache-Control: max-age=0" directive (see section |
4325 |
14.9), to force a check with the origin server. |
4326 |
|
4327 |
If a cache has two fresh responses for the same representation with |
4328 |
different validators, it MUST use the one with the more recent Date |
4329 |
header. This situation may arise because the cache is pooling responses |
4330 |
from other caches, or because a client has asked for a reload or a |
4331 |
revalidation of an apparently fresh cache entry. |
4332 |
|
4333 |
|
4334 |
13.2.6 Disambiguating Multiple Responses |
4335 |
|
4336 |
Because a client may be receiving responses via multiple paths, so that |
4337 |
some responses flow through one set of caches and other responses flow |
4338 |
through a different set of caches, a client may receive responses in an |
4339 |
order different from that in which the origin server sent them. We would |
4340 |
like the client to use the most recently generated response, even if |
4341 |
older responses are still apparently fresh. |
4342 |
|
4343 |
Neither the entity tag nor the expiration value can impose an ordering |
4344 |
on responses, since it is possible that a later response intentionally |
4345 |
carries an earlier expiration time. However, the HTTP/1.1 specification |
4346 |
requires the transmission of Date headers on every response, and the |
4347 |
Date values are ordered to a granularity of one second. |
4348 |
|
4349 |
When a client tries to revalidate a cache entry, and the response it |
4350 |
receives contains a Date header that appears to be older than the one |
4351 |
for the existing entry, then the client SHOULD repeat the request |
4352 |
unconditionally, and include |
4353 |
|
4354 |
Cache-Control: max-age=0 |
4355 |
|
4356 |
to force any intermediate caches to validate their copies directly with |
4357 |
the origin server, or |
4358 |
|
4359 |
Cache-Control: no-cache |
4360 |
|
4361 |
to force any intermediate caches to obtain a new copy from the origin |
4362 |
server. |
4363 |
|
4364 |
If the Date values are equal, then the client may use either response |
4365 |
(or may, if it is being extremely prudent, request a new response). |
4366 |
Servers MUST NOT depend on clients being able to choose |
4367 |
deterministically between responses generated during the same second, if |
4368 |
their expiration times overlap. |
4369 |
|
4370 |
|
4371 |
|
4372 |
|
4373 |
|
4374 |
|
4375 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 74] |
4376 |
|
4377 |
|
4378 |
|
4379 |
|
4380 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4381 |
|
4382 |
|
4383 |
13.3 Validation Model |
4384 |
|
4385 |
When a cache has a stale entry that it would like to use as a response |
4386 |
to a client's request, it first has to check with the origin server (or |
4387 |
possibly an intermediate cache with a fresh response) to see if its |
4388 |
cached entry is still usable. We call this "validating" the cache entry. |
4389 |
Since we do not want to have to pay the overhead of retransmitting the |
4390 |
full response if the cached entry is good, and we do not want to pay the |
4391 |
overhead of an extra round trip if the cached entry is invalid, the |
4392 |
HTTP/1.1 protocol supports the use of conditional methods. |
4393 |
|
4394 |
The key protocol features for supporting conditional methods are those |
4395 |
concerned with "cache validators." When an origin server generates a |
4396 |
full response, it attaches some sort of validator to it, which is kept |
4397 |
with the cache entry. When a client (end-user or cache) makes a |
4398 |
conditional request for a resource for which it has a cache entry, it |
4399 |
includes the associated validator in the request. |
4400 |
|
4401 |
The server then checks that validator against the current validator for |
4402 |
the entity, and, if they match, it responds with a special status code |
4403 |
(usually, 304 (Not Modified)) and no entity-body. Otherwise, it returns |
4404 |
a full response (including entity-body). Thus, we avoid transmitting the |
4405 |
full response if the validator matches, and we avoid an extra round trip |
4406 |
if it does not match. |
4407 |
|
4408 |
Note: the comparison functions used to decide if validators match |
4409 |
are defined in section 13.3.3. |
4410 |
|
4411 |
In HTTP/1.1, a conditional request looks exactly the same as a normal |
4412 |
request for the same resource, except that it carries a special header |
4413 |
(which includes the validator) that implicitly turns the method |
4414 |
(usually, GET) into a conditional. |
4415 |
|
4416 |
The protocol includes both positive and negative senses of cache- |
4417 |
validating conditions. That is, it is possible to request either that a |
4418 |
method be performed if and only if a validator matches or if and only if |
4419 |
no validators match. |
4420 |
|
4421 |
Note: a response that lacks a validator may still be cached, and |
4422 |
served from cache until it expires, unless this is explicitly |
4423 |
prohibited by a Cache-Control directive. However, a cache cannot do |
4424 |
a conditional retrieval if it does not have a validator for the |
4425 |
entity, which means it will not be refreshable after it expires. |
4426 |
|
4427 |
|
4428 |
13.3.1 Last-modified Dates |
4429 |
|
4430 |
The Last-Modified entity-header field value is often used as a cache |
4431 |
validator. In simple terms, a cache entry is considered to be valid if |
4432 |
the entity has not been modified since the Last-Modified value. |
4433 |
|
4434 |
|
4435 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 75] |
4436 |
|
4437 |
|
4438 |
|
4439 |
|
4440 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4441 |
|
4442 |
|
4443 |
13.3.2 Entity Tag Cache Validators |
4444 |
|
4445 |
The ETag entity-header field value, an entity tag, provides for an |
4446 |
"opaque" cache validator. This may allow more reliable validation in |
4447 |
situations where it is inconvenient to store modification dates, where |
4448 |
the one-second resolution of HTTP date values is not sufficient, or |
4449 |
where the origin server wishes to avoid certain paradoxes that may arise |
4450 |
from the use of modification dates. |
4451 |
|
4452 |
Entity Tags are described in section 3.11. The headers used with entity |
4453 |
tags are described in sections 14.20, 14.25, 14.26 and 14.43. |
4454 |
|
4455 |
|
4456 |
13.3.3 Weak and Strong Validators |
4457 |
|
4458 |
Since both origin servers and caches will compare two validators to |
4459 |
decide if they represent the same or different entities, one normally |
4460 |
would expect that if the entity (the entity-body or any entity-headers) |
4461 |
changes in any way, then the associated validator would change as well. |
4462 |
If this is true, then we call this validator a "strong validator." |
4463 |
|
4464 |
However, there may be cases when a server prefers to change the |
4465 |
validator only on semantically significant changes, and not when |
4466 |
insignificant aspects of the entity change. A validator that does not |
4467 |
always change when the resource changes is a "weak validator." |
4468 |
|
4469 |
Entity tags are normally "strong validators," but the protocol provides |
4470 |
a mechanism to tag an entity tag as "weak." One can think of a strong |
4471 |
validator as one that changes whenever the bits of an entity changes, |
4472 |
while a weak value changes whenever the meaning of an entity changes. |
4473 |
Alternatively, one can think of a strong validator as part of an |
4474 |
identifier for a specific entity, while a weak validator is part of an |
4475 |
identifier for a set of semantically equivalent entities. |
4476 |
|
4477 |
Note: One example of a strong validator is an integer that is |
4478 |
incremented in stable storage every time an entity is changed. |
4479 |
|
4480 |
An entity's modification time, if represented with one-second |
4481 |
resolution, could be a weak validator, since it is possible that |
4482 |
the resource may be modified twice during a single second. |
4483 |
|
4484 |
Support for weak validators is optional; however, weak validators |
4485 |
allow for more efficient caching of equivalent objects; for |
4486 |
example, a hit counter on a site is probably good enough if it is |
4487 |
updated every few days or weeks, and any value during that period |
4488 |
is likely "good enough" to be equivalent. |
4489 |
|
4490 |
A "use" of a validator is either when a client generates a request and |
4491 |
includes the validator in a validating header field, or when a server |
4492 |
compares two validators. |
4493 |
|
4494 |
|
4495 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 76] |
4496 |
|
4497 |
|
4498 |
|
4499 |
|
4500 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4501 |
|
4502 |
|
4503 |
Strong validators are usable in any context. Weak validators are only |
4504 |
usable in contexts that do not depend on exact equality of an entity. |
4505 |
For example, either kind is usable for a conditional GET of a full |
4506 |
entity. However, only a strong validator is usable for a sub-range |
4507 |
retrieval, since otherwise the client may end up with an internally |
4508 |
inconsistent entity. |
4509 |
|
4510 |
The only function that the HTTP/1.1 protocol defines on validators is |
4511 |
comparison. There are two validator comparison functions, depending on |
4512 |
whether the comparison context allows the use of weak validators or not: |
4513 |
|
4514 |
. The strong comparison function: in order to be considered equal, |
4515 |
both validators must be identical in every way, and neither may be |
4516 |
weak. |
4517 |
. The weak comparison function: in order to be considered equal, both |
4518 |
validators must be identical in every way, but either or both of |
4519 |
them may be tagged as "weak" without affecting the result. |
4520 |
The weak comparison function MAY be used for simple (non-subrange) GET |
4521 |
requests. The strong comparison function MUST be used in all other |
4522 |
cases. |
4523 |
|
4524 |
An entity tag is strong unless it is explicitly tagged as weak. Section |
4525 |
14.20 gives the syntax for entity tags. |
4526 |
|
4527 |
A Last-Modified time, when used as a validator in a request, is |
4528 |
implicitly weak unless it is possible to deduce that it is strong, using |
4529 |
the following rules: |
4530 |
|
4531 |
. The validator is being compared by an origin server to the actual |
4532 |
current validator for the entity and, |
4533 |
. That origin server reliably knows that the associated entity did |
4534 |
not change twice during the second covered by the presented |
4535 |
validator. |
4536 |
or |
4537 |
|
4538 |
. The validator is about to be used by a client in an If-Modified- |
4539 |
Since or If-Unmodified-Since header, because the client has a cache |
4540 |
entry for the associated entity, and |
4541 |
. That cache entry includes a Date value, which gives the time when |
4542 |
the origin server sent the original response, and |
4543 |
. The presented Last-Modified time is at least 60 seconds before the |
4544 |
Date value. |
4545 |
or |
4546 |
|
4547 |
. The validator is being compared by an intermediate cache to the |
4548 |
validator stored in its cache entry for the entity, and |
4549 |
. That cache entry includes a Date value, which gives the time when |
4550 |
the origin server sent the original response, and |
4551 |
. The presented Last-Modified time is at least 60 seconds before the |
4552 |
Date value. |
4553 |
|
4554 |
|
4555 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 77] |
4556 |
|
4557 |
|
4558 |
|
4559 |
|
4560 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4561 |
|
4562 |
|
4563 |
This method relies on the fact that if two different responses were sent |
4564 |
by the origin server during the same second, but both had the same Last- |
4565 |
Modified time, then at least one of those responses would have a Date |
4566 |
value equal to its Last-Modified time. The arbitrary 60-second limit |
4567 |
guards against the possibility that the Date and Last-Modified values |
4568 |
are generated from different clocks, or at somewhat different times |
4569 |
during the preparation of the response. An implementation may use a |
4570 |
value larger than 60 seconds, if it is believed that 60 seconds is too |
4571 |
short. |
4572 |
|
4573 |
If a client wishes to perform a sub-range retrieval on a value for which |
4574 |
it has only a Last-Modified time and no opaque validator, it may do this |
4575 |
only if the Last-Modified time is strong in the sense described here. |
4576 |
|
4577 |
A cache or origin server receiving a cache-conditional request, other |
4578 |
than a full-body GET request, MUST use the strong comparison function to |
4579 |
evaluate the condition. |
4580 |
|
4581 |
These rules allow HTTP/1.1 caches and clients to safely perform sub- |
4582 |
range retrievals on values that have been obtained from HTTP/1.0 |
4583 |
servers. |
4584 |
|
4585 |
|
4586 |
13.3.4 Rules for When to Use Entity Tags and Last-modified Dates |
4587 |
|
4588 |
We adopt a set of rules and recommendations for origin servers, clients, |
4589 |
and caches regarding when various validator types should be used, and |
4590 |
for what purposes. |
4591 |
|
4592 |
HTTP/1.1 origin servers: |
4593 |
|
4594 |
. SHOULD send a entity tag validator unless it is not feasible to |
4595 |
generate one. |
4596 |
. MAY send a weak entity tag instead of a strong entity tag, if |
4597 |
performance considerations support the use of weak entity tags, or |
4598 |
if it is unfeasible to send a strong entity tag . |
4599 |
. SHOULD send a Last-Modified value if it is feasible to send one, |
4600 |
unless the risk of a breakdown in semantic transparency that could |
4601 |
result from using this date in an If-Modified-Since header would |
4602 |
lead to serious problems. |
4603 |
In other words, the preferred behavior for an HTTP/1.1 origin server is |
4604 |
to send both a strong entity tag and a Last-Modified value. |
4605 |
|
4606 |
In order to be legal, a strong entity tag MUST change whenever the |
4607 |
associated entity value changes in any way. A weak entity tag SHOULD |
4608 |
change whenever the associated entity changes in a semantically |
4609 |
significant way. |
4610 |
|
4611 |
Note: in order to provide semantically transparent caching, an |
4612 |
origin server must avoid reusing a specific strong entity tag value |
4613 |
for two different entities, or reusing a specific weak entity tag |
4614 |
|
4615 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 78] |
4616 |
|
4617 |
|
4618 |
|
4619 |
|
4620 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4621 |
|
4622 |
|
4623 |
value for two semantically different entities. Cache entries may |
4624 |
persist for arbitrarily long periods, regardless of expiration |
4625 |
times, so it may be inappropriate to expect that a cache will never |
4626 |
again attempt to validate an entry using a validator that it |
4627 |
obtained at some point in the past. |
4628 |
|
4629 |
HTTP/1.1 clients: |
4630 |
|
4631 |
. If an entity tag has been provided by the origin server, MUST use |
4632 |
that entity tag in any cache-conditional request (using If-Match or |
4633 |
If-None-Match). |
4634 |
. If only a Last-Modified value has been provided by the origin |
4635 |
server, SHOULD use that value in non-subrange cache-conditional |
4636 |
requests (using If-Modified-Since). |
4637 |
. If only a Last-Modified value has been provided by an HTTP/1.0 |
4638 |
origin server, MAY use that value in subrange cache-conditional |
4639 |
requests (using If-Unmodified-Since:). The user agent should |
4640 |
provide a way to disable this, in case of difficulty. |
4641 |
. If both an entity tag and a Last-Modified value have been provided |
4642 |
by the origin server, SHOULD use both validators in cache- |
4643 |
conditional requests. This allows both HTTP/1.0 and HTTP/1.1 caches |
4644 |
to respond appropriately. |
4645 |
An HTTP/1.1 cache, upon receiving a request, MUST use the most |
4646 |
restrictive validator when deciding whether the client's cache entry |
4647 |
matches the cache's own cache entry. This is only an issue when the |
4648 |
request contains both an entity tag and a last-modified-date validator |
4649 |
(If-Modified-Since or If-Unmodified-Since). |
4650 |
|
4651 |
A note on rationale: The general principle behind these rules is |
4652 |
that HTTP/1.1 servers and clients should transmit as much non- |
4653 |
redundant information as is available in their responses and |
4654 |
requests. HTTP/1.1 systems receiving this information will make the |
4655 |
most conservative assumptions about the validators they receive. |
4656 |
|
4657 |
HTTP/1.0 clients and caches will ignore entity tags. Generally, |
4658 |
last-modified values received or used by these systems will support |
4659 |
transparent and efficient caching, and so HTTP/1.1 origin servers |
4660 |
should provide Last-Modified values. In those rare cases where the |
4661 |
use of a Last-Modified value as a validator by an HTTP/1.0 system |
4662 |
could result in a serious problem, then HTTP/1.1 origin servers |
4663 |
should not provide one. |
4664 |
|
4665 |
|
4666 |
13.3.5 Non-validating Conditionals |
4667 |
|
4668 |
The principle behind entity tags is that only the service author knows |
4669 |
the semantics of a resource well enough to select an appropriate cache |
4670 |
validation mechanism, and the specification of any validator comparison |
4671 |
function more complex than byte-equality would open up a can of worms. |
4672 |
Thus, comparisons of any other headers (except Last-Modified, for |
4673 |
|
4674 |
|
4675 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 79] |
4676 |
|
4677 |
|
4678 |
|
4679 |
|
4680 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4681 |
|
4682 |
|
4683 |
compatibility with HTTP/1.0) are never used for purposes of validating a |
4684 |
cache entry. |
4685 |
|
4686 |
|
4687 |
13.4 Constructing Responses From Caches |
4688 |
|
4689 |
The purpose of an HTTP cache is to store information received in |
4690 |
response to requests, for use in responding to future requests. In many |
4691 |
cases, a cache simply returns the appropriate parts of a response to the |
4692 |
requester. However, if the cache holds a cache entry based on a previous |
4693 |
response, it may have to combine parts of a new response with what is |
4694 |
held in the cache entry. |
4695 |
|
4696 |
|
4697 |
13.4.1 End-to-end and Hop-by-hop Headers |
4698 |
|
4699 |
For the purpose of defining the behavior of caches and non-caching |
4700 |
proxies, we divide HTTP headers into two categories: |
4701 |
|
4702 |
. End-to-end headers, which must be transmitted to the ultimate |
4703 |
recipient of a request or response. End-to-end headers in responses |
4704 |
must be stored as part of a cache entry and transmitted in any |
4705 |
response formed from a cache entry. |
4706 |
. Hop-by-hop headers, which are meaningful only for a single |
4707 |
transport-level connection, and are not stored by caches or |
4708 |
forwarded by proxies. |
4709 |
The following HTTP/1.1 headers are hop-by-hop headers: |
4710 |
|
4711 |
. Accept-Ranges |
4712 |
. Connection |
4713 |
. Keep-Alive |
4714 |
. Public |
4715 |
. Proxy-Authenticate |
4716 |
. Transfer-Encoding |
4717 |
. Upgrade |
4718 |
All other headers defined by HTTP/1.1 are end-to-end headers. |
4719 |
|
4720 |
Hop-by-hop headers introduced in future versions of HTTP MUST be listed |
4721 |
in a Connection header, as described in section 14.10. |
4722 |
|
4723 |
|
4724 |
13.4.2 Non-modifiable Headers |
4725 |
|
4726 |
Some features of the HTTP/1.1 protocol, such as Digest Authentication, |
4727 |
depend on the value of certain end-to-end headers. A cache or non- |
4728 |
caching proxy SHOULD NOT modify an end-to-end header unless the |
4729 |
definition of that header requires or specifically allows that. |
4730 |
|
4731 |
A cache or non-caching proxy MUST NOT modify any of the following fields |
4732 |
in a request or response, nor may it add any of these fields if not |
4733 |
already present: |
4734 |
|
4735 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 80] |
4736 |
|
4737 |
|
4738 |
|
4739 |
|
4740 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4741 |
|
4742 |
|
4743 |
. Content-Encoding |
4744 |
. Content-Length |
4745 |
. Content-Location |
4746 |
. Content-Range |
4747 |
. Content-Type |
4748 |
. Expires |
4749 |
. Last-Modified |
4750 |
Warning: unnecessary modification of end-to-end headers may cause |
4751 |
authentication failures if stronger authentication mechanisms are |
4752 |
introduced in later versions of HTTP. Such authentication |
4753 |
mechanisms may rely on the values of header fields not listed here. |
4754 |
|
4755 |
|
4756 |
13.4.3 Combining Headers |
4757 |
|
4758 |
When a cache makes a validating request to a server, and the server |
4759 |
provides a 304 (Not Modified) response, the cache must construct a |
4760 |
response to send to the requesting client. The cache uses the entity- |
4761 |
body stored in the cache entry as the entity-body of this outgoing |
4762 |
response. The end-to-end headers stored in the cache entry are used for |
4763 |
the constructed response, except that any end-to-end headers provided in |
4764 |
the 304 response MUST replace the corresponding headers from the cache |
4765 |
entry. Unless the cache decides to remove the cache entry, it MUST also |
4766 |
replace the end-to-end headers stored with the cache entry with |
4767 |
corresponding headers received in the incoming response. |
4768 |
|
4769 |
In other words, the set of end-to-end headers received in the incoming |
4770 |
response overrides all corresponding end-to-end headers stored with the |
4771 |
cache entry. The cache may add Warning headers (see section 14.45) to |
4772 |
this set. |
4773 |
|
4774 |
If a header field-name in the incoming response matches more than one |
4775 |
header in the cache entry, all such old headers are replaced. |
4776 |
|
4777 |
Note: this rule allows an origin server to use a 304 (Not Modified) |
4778 |
response to update any header associated with a previous response |
4779 |
for the same entity, although it might not always be meaningful or |
4780 |
correct to do so. This rule does not allow an origin server to use |
4781 |
a 304 (not Modified) response to entirely delete a header that it |
4782 |
had provided with a previous response. |
4783 |
|
4784 |
|
4785 |
13.4.4 Combining Byte Ranges |
4786 |
|
4787 |
A response may transfer only a subrange of the bytes of an entity-body, |
4788 |
either because the request included one or more Range specifications, or |
4789 |
because a connection was broken prematurely. After several such |
4790 |
transfers, a cache may have received several ranges of the same entity- |
4791 |
body. |
4792 |
|
4793 |
|
4794 |
|
4795 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 81] |
4796 |
|
4797 |
|
4798 |
|
4799 |
|
4800 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4801 |
|
4802 |
|
4803 |
If a cache has a stored non-empty set of subranges for an entity, and an |
4804 |
incoming response transfers another subrange, the cache MAY combine the |
4805 |
new subrange with the existing set if both the following conditions are |
4806 |
met: |
4807 |
|
4808 |
. Both the incoming response and the cache entry must have a cache |
4809 |
validator. |
4810 |
. The two cache validators must match using the strong comparison |
4811 |
function (see section 13.3.3). |
4812 |
If either requirement is not meant, the cache must use only the most |
4813 |
recent partial response (based on the Date values transmitted with every |
4814 |
response, and using the incoming response if these values are equal or |
4815 |
missing), and must discard the other partial information. |
4816 |
|
4817 |
|
4818 |
13.5 Caching Negotiated Responses |
4819 |
|
4820 |
Use of server-driven content negotiation (section 12), as indicated by |
4821 |
the presence of a Vary header field in a response, alters the conditions |
4822 |
and procedure by which a cache can use the response for subsequent |
4823 |
requests. |
4824 |
|
4825 |
A server MUST use the Vary header field (section 14.43) to inform a |
4826 |
cache of what header field dimensions are used to select among multiple |
4827 |
representations of a response. A cache may use the selected |
4828 |
representation (the entity included with that particular response) for |
4829 |
replying to subsequent requests on that resource only when the |
4830 |
subsequent requests have the same or equivalent values for all header |
4831 |
fields specified in the Vary response-header. Requests with a different |
4832 |
value for one or more of those header fields would be forwarded toward |
4833 |
the origin server. |
4834 |
|
4835 |
If an entity tag was assigned to the representation, the forwarded |
4836 |
request SHOULD be conditional and include the entity tags in an If-None- |
4837 |
Match header field from all its cache entries for the Request-URI. |
4838 |
|
4839 |
This conveys to the server the set of entities currently held by the |
4840 |
cache, so that if any one of these entities matches the requested |
4841 |
entity, the server can use the ETag header in its 304 (Not Modified) |
4842 |
response to tell the cache which entry is appropriate. If the entity-tag |
4843 |
of the new response matches that of an existing entry, the new response |
4844 |
SHOULD be used to update the header fields of the existing entry, and |
4845 |
the result MUST be returned to the client. |
4846 |
|
4847 |
The Vary header field may also inform the cache that the representation |
4848 |
was selected using criteria not limited to the request-headers; in this |
4849 |
case, a cache MUST NOT use the response in a reply to a subsequent |
4850 |
request unless the cache relays the new request to the origin server in |
4851 |
a conditional request and the server responds with 304 (Not Modified), |
4852 |
including an entity tag or Content-Location that indicates which entity |
4853 |
should be used. |
4854 |
|
4855 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 82] |
4856 |
|
4857 |
|
4858 |
|
4859 |
|
4860 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4861 |
|
4862 |
|
4863 |
If any of the existing cache entries contains only partial content for |
4864 |
the associated entity, its entity-tag SHOULD NOT be included in the If- |
4865 |
None-Match header unless the request is for a range that would be fully |
4866 |
satisfied by that entry. |
4867 |
|
4868 |
If a cache receives a successful response whose Content-Location field |
4869 |
matches that of an existing cache entry for the same Request-URI, whose |
4870 |
entity-tag differs from that of the existing entry, and whose Date is |
4871 |
more recent than that of the existing entry, the existing entry SHOULD |
4872 |
NOT be returned in response to future requests, and should be deleted |
4873 |
from the cache. |
4874 |
|
4875 |
|
4876 |
13.6 Shared and Non-Shared Caches |
4877 |
|
4878 |
For reasons of security and privacy, it is necessary to make a |
4879 |
distinction between "shared" and "non-shared" caches. A non-shared cache |
4880 |
is one that is accessible only to a single user. Accessibility in this |
4881 |
case SHOULD be enforced by appropriate security mechanisms. All other |
4882 |
caches are considered to be "shared." Other sections of this |
4883 |
specification place certain constraints on the operation of shared |
4884 |
caches in order to prevent loss of privacy or failure of access |
4885 |
controls. |
4886 |
|
4887 |
|
4888 |
13.7 Errors or Incomplete Response Cache Behavior |
4889 |
|
4890 |
A cache that receives an incomplete response (for example, with fewer |
4891 |
bytes of data than specified in a Content-Length header) may store the |
4892 |
response. However, the cache MUST treat this as a partial response. |
4893 |
Partial responses may be combined as described in section 13.4.4; the |
4894 |
result might be a full response or might still be partial. A cache MUST |
4895 |
NOT return a partial response to a client without explicitly marking it |
4896 |
as such, using the 206 (Partial Content) status code. A cache MUST NOT |
4897 |
return a partial response using a status code of 200 (OK). |
4898 |
|
4899 |
If a cache receives a 5xx response while attempting to revalidate an |
4900 |
entry, it may either forward this response to the requesting client, or |
4901 |
act as if the server failed to respond. In the latter case, it MAY |
4902 |
return a previously received response unless the cached entry includes |
4903 |
the "must-revalidate" Cache-Control directive (see section 14.9). |
4904 |
|
4905 |
|
4906 |
13.7.1 Caching and Status Codes |
4907 |
|
4908 |
A response received with a status code of 200, 206 or 301 may be stored |
4909 |
by a cache and used in reply to a subsequent request, subject to the |
4910 |
expiration mechanism, unless a Cache-Control directive prohibits |
4911 |
caching. However, a cache that does not support the Range and Content- |
4912 |
Range headers MUST NOT cache 206 (Partial Content) responses. |
4913 |
|
4914 |
|
4915 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 83] |
4916 |
|
4917 |
|
4918 |
|
4919 |
|
4920 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4921 |
|
4922 |
|
4923 |
A response received with any other status code MUST NOT be returned in a |
4924 |
reply to a subsequent request unless it carries at least one of the |
4925 |
following: |
4926 |
|
4927 |
. an Expires header |
4928 |
. a max-age Cache-Control directive |
4929 |
. a must-revalidate Cache-Control directive |
4930 |
. a public Cache-Control directive |
4931 |
|
4932 |
|
4933 |
|
4934 |
13.7.2 Side Effects of GET and HEAD |
4935 |
|
4936 |
Unless the origin server explicitly prohibits the caching of their |
4937 |
responses, the application of GET and HEAD methods to any resources |
4938 |
SHOULD NOT have side effects that would lead to erroneous behavior if |
4939 |
these responses are taken from a cache. They may still have side |
4940 |
effects, but a cache is not required to consider such side effects in |
4941 |
its caching decisions. Caches are always expected to observe an origin |
4942 |
server's explicit restrictions on caching. |
4943 |
|
4944 |
We note one exception to this rule: since some applications have |
4945 |
traditionally used GETs and HEADs with query URLs (those containing a |
4946 |
"?" in the rel_path part) to perform operations with significant side |
4947 |
effects, caches MUST NOT treat responses to such URLs as fresh unless |
4948 |
the server provides an explicit expiration time. |
4949 |
|
4950 |
This specifically means that responses from HTTP/1.0 servers for such |
4951 |
URIs should not be taken from a cache. |
4952 |
|
4953 |
See section 9.1.1 for related information. |
4954 |
|
4955 |
|
4956 |
13.8 Invalidation After Updates or Deletions |
4957 |
|
4958 |
The effect of certain methods at the origin server may cause one or more |
4959 |
existing cache entries to become non-transparently invalid. That is, |
4960 |
although they may continue to be "fresh," they do not accurately reflect |
4961 |
what the origin server would return for a new request. |
4962 |
|
4963 |
There is no way for the HTTP protocol to guarantee that all such cache |
4964 |
entries are marked invalid. For example, the request that caused the |
4965 |
change at the origin server may not have gone through the proxy where a |
4966 |
cache entry is stored. However, several rules help reduce the likelihood |
4967 |
of erroneous behavior. |
4968 |
|
4969 |
In this section, the phrase "invalidate an entity" means that the cache |
4970 |
should either remove all instances of that entity from its storage, or |
4971 |
should mark these as "invalid" and in need of a mandatory revalidation |
4972 |
before they can be returned in response to a subsequent request. |
4973 |
|
4974 |
|
4975 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 84] |
4976 |
|
4977 |
|
4978 |
|
4979 |
|
4980 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
4981 |
|
4982 |
|
4983 |
Some HTTP methods may invalidate an entity. This is either the entity |
4984 |
referred to by the Request-URI, or by the Location or Content-Location |
4985 |
response-headers (if present). These methods are: |
4986 |
|
4987 |
. PUT |
4988 |
. DELETE |
4989 |
. POST |
4990 |
In order to prevent denial of service attacks, an invalidation based on |
4991 |
the URI in a Location or Content-Location header MUST only be performed |
4992 |
if the host part is the same as in the Request-URI. |
4993 |
|
4994 |
|
4995 |
13.9 Write-Through Mandatory |
4996 |
|
4997 |
All methods that may be expected to cause modifications to the origin |
4998 |
server's resources MUST be written through to the origin server. This |
4999 |
currently includes all methods except for GET and HEAD. A cache MUST NOT |
5000 |
reply to such a request from a client before having transmitted the |
5001 |
request to the inbound server, and having received a corresponding |
5002 |
response from the inbound server. This does not prevent a cache from |
5003 |
sending a 100 (Continue) response before the inbound server has replied. |
5004 |
|
5005 |
The alternative (known as "write-back" or "copy-back" caching) is not |
5006 |
allowed in HTTP/1.1, due to the difficulty of providing consistent |
5007 |
updates and the problems arising from server, cache, or network failure |
5008 |
prior to write-back. |
5009 |
|
5010 |
|
5011 |
13.10 Cache Replacement |
5012 |
|
5013 |
If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.7) |
5014 |
response is received from a resource while any existing responses for |
5015 |
the same resource are cached, the cache SHOULD use the new response to |
5016 |
reply to the current request. It may insert it into cache storage and |
5017 |
may, if it meets all other requirements, use it to respond to any future |
5018 |
requests that would previously have caused the old response to be |
5019 |
returned. If it inserts the new response into cache storage it should |
5020 |
follow the rules in section 13.4.3. |
5021 |
|
5022 |
Note: a new response that has an older Date header value than |
5023 |
existing cached responses is not cachable. |
5024 |
|
5025 |
|
5026 |
13.11 History Lists |
5027 |
|
5028 |
User agents often have history mechanisms, such as "Back" buttons and |
5029 |
history lists, which can be used to redisplay an entity retrieved |
5030 |
earlier in a session. |
5031 |
|
5032 |
History mechanisms and caches are different. In particular history |
5033 |
mechanisms SHOULD NOT try to show a semantically transparent view of the |
5034 |
|
5035 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 85] |
5036 |
|
5037 |
|
5038 |
|
5039 |
|
5040 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5041 |
|
5042 |
|
5043 |
current state of a resource. Rather, a history mechanism is meant to |
5044 |
show exactly what the user saw at the time when the resource was |
5045 |
retrieved . |
5046 |
|
5047 |
By default, an expiration time does not apply to history mechanisms. If |
5048 |
the entity is still in storage, a history mechanism should display it |
5049 |
even if the entity has expired, unless the user has specifically |
5050 |
configured the agent to refresh expired history documents. |
5051 |
|
5052 |
This should not be construed to prohibit the history mechanism from |
5053 |
telling the user that a view may be stale. |
5054 |
|
5055 |
Note: if history list mechanisms unnecessarily prevent users from |
5056 |
viewing stale resources, this will tend to force service authors to |
5057 |
avoid using HTTP expiration controls and cache controls when they |
5058 |
would otherwise like to. Service authors may consider it important |
5059 |
that users not be presented with error messages or warning messages |
5060 |
when they use navigation controls (such as BACK) to view previously |
5061 |
fetched resources. Even though sometimes such resources ought not |
5062 |
to cached, or ought to expire quickly, user interface |
5063 |
considerations may force service authors to resort to other means |
5064 |
of preventing caching (e.g. "once-only" URLs) in order not to |
5065 |
suffer the effects of improperly functioning history mechanisms. |
5066 |
|
5067 |
|
5068 |
14 Header Field Definitions |
5069 |
|
5070 |
This section defines the syntax and semantics of all standard HTTP/1.1 |
5071 |
header fields. For entity-header fields, both sender and recipient refer |
5072 |
to either the client or the server, depending on who sends and who |
5073 |
receives the entity. |
5074 |
|
5075 |
|
5076 |
14.1 Accept |
5077 |
|
5078 |
The Accept request-header field can be used to specify certain media |
5079 |
types which are acceptable for the response. Accept headers can be used |
5080 |
to indicate that the request is specifically limited to a small set of |
5081 |
desired types, as in the case of a request for an in-line image. |
5082 |
|
5083 |
Accept = "Accept" ":" #( |
5084 |
media-range |
5085 |
[ ( ":" | ";" ) |
5086 |
range-parameter |
5087 |
*( ";" range-parameter ) ] |
5088 |
| extension-token ) |
5089 |
|
5090 |
media-range = ( "*/*" |
5091 |
| ( type "/" "*" ) |
5092 |
| ( type "/" subtype ) |
5093 |
) *( ";" parameter ) |
5094 |
|
5095 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 86] |
5096 |
|
5097 |
|
5098 |
|
5099 |
|
5100 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5101 |
|
5102 |
|
5103 |
range-parameter = ( "q" "=" qvalue ) |
5104 |
| extension-range-parameter |
5105 |
|
5106 |
extension-range-parameter = ( token "=" token ) |
5107 |
|
5108 |
extension-token = token |
5109 |
|
5110 |
The asterisk "*" character is used to group media types into ranges, |
5111 |
with "*/*" indicating all media types and "type/*" indicating all |
5112 |
subtypes of that type. The range-parameter q is used to indicate the |
5113 |
media type quality factor for the range, which represents the user's |
5114 |
preference for that range of media types. The default value is q=1. In |
5115 |
Accept headers sent by HTTP/1.1 clients, the character separating media- |
5116 |
ranges from range-parameters SHOULD be a ":". HTTP/1.1 servers SHOULD be |
5117 |
tolerant of use of the ";" separator by HTTP/1.0 clients. |
5118 |
|
5119 |
The example |
5120 |
|
5121 |
Accept: audio/*: q=0.2, audio/basic |
5122 |
|
5123 |
SHOULD be interpreted as "I prefer audio/basic, but send me any audio |
5124 |
type if it is the best available after an 80% mark-down in quality." |
5125 |
|
5126 |
If no Accept header is present, then it is assumed that the client |
5127 |
accepts all media types. If Accept headers are present, and if the |
5128 |
server cannot send a response which is acceptable according to the |
5129 |
Accept headers, then the server SHOULD send an error response with the |
5130 |
406 (not acceptable) status code, though the sending of an unacceptable |
5131 |
response is also allowed. |
5132 |
|
5133 |
A more elaborate example is |
5134 |
|
5135 |
Accept: text/plain: q=0.5, text/html, |
5136 |
text/x-dvi: q=0.8, text/x-c |
5137 |
|
5138 |
Verbally, this would be interpreted as "text/html and text/x-c are the |
5139 |
preferred media types, but if they do not exist, then send the text/x- |
5140 |
dvi entity, and if that does not exist, send the text/plain entity." |
5141 |
|
5142 |
Media ranges can be overridden by more specific media ranges or specific |
5143 |
media types. If more than one media range applies to a given type, the |
5144 |
most specific reference has precedence. For example, |
5145 |
|
5146 |
Accept: text/*, text/html, text/html;level=1, */* |
5147 |
|
5148 |
have the following precedence: |
5149 |
|
5150 |
1) text/html;level=1 |
5151 |
2) text/html |
5152 |
3) text/* |
5153 |
4) */* |
5154 |
|
5155 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 87] |
5156 |
|
5157 |
|
5158 |
|
5159 |
|
5160 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5161 |
|
5162 |
|
5163 |
The media type quality factor associated with a given type is determined |
5164 |
by finding the media range with the highest precedence which matches |
5165 |
that type. For example, |
5166 |
|
5167 |
Accept: text/*:q=0.3, text/html:q=0.7, text/html;level=1, |
5168 |
text/html;level=2:q=0.4, */*:q=0.5 |
5169 |
|
5170 |
would cause the following values to be associated: |
5171 |
|
5172 |
text/html;level=1 = 1 |
5173 |
text/html = 0.7 |
5174 |
text/plain = 0.3 |
5175 |
image/jpeg = 0.5 |
5176 |
text/html;level=2 = 0.4 |
5177 |
text/html;level=3 = 0.7 |
5178 |
|
5179 |
Note: A user agent may be provided with a default set of quality |
5180 |
values for certain media ranges. However, unless the user agent is |
5181 |
a closed system which cannot interact with other rendering agents, |
5182 |
this default set should be configurable by the user. |
5183 |
|
5184 |
|
5185 |
14.2 Accept-Charset |
5186 |
|
5187 |
The Accept-Charset request-header field can be used to indicate what |
5188 |
character sets are acceptable for the response. This field allows |
5189 |
clients capable of understanding more comprehensive or special-purpose |
5190 |
character sets to signal that capability to a server which is capable of |
5191 |
representing documents in those character sets. The ISO-8859-1 character |
5192 |
set can be assumed to be acceptable to all user agents. |
5193 |
|
5194 |
Accept-Charset = "Accept-Charset" ":" |
5195 |
1#( charset [ ";" "q" "=" qvalue ] ) |
5196 |
|
5197 |
Character set values are described in section 3.4. Each charset may be |
5198 |
given an associated quality value which represents the user's preference |
5199 |
for that charset. The default value is q=1. An example is |
5200 |
|
5201 |
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
5202 |
|
5203 |
If no Accept-Charset header is present, the default is that any |
5204 |
character set is acceptable. If an Accept-Charset header is present, and |
5205 |
if the server cannot send a response which is acceptable according to |
5206 |
the Accept-Charset header, then the server SHOULD send an error response |
5207 |
with the 406 (not acceptable) status code, though the sending of an |
5208 |
unacceptable response is also allowed. |
5209 |
|
5210 |
|
5211 |
|
5212 |
|
5213 |
|
5214 |
|
5215 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 88] |
5216 |
|
5217 |
|
5218 |
|
5219 |
|
5220 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5221 |
|
5222 |
|
5223 |
14.3 Accept-Encoding |
5224 |
|
5225 |
The Accept-Encoding request-header field is similar to Accept, but |
5226 |
restricts the content-coding values (section 14.12) which are acceptable |
5227 |
in the response. |
5228 |
|
5229 |
Accept-Encoding = "Accept-Encoding" ":" |
5230 |
#( content-coding ) |
5231 |
|
5232 |
An example of its use is |
5233 |
|
5234 |
Accept-Encoding: compress, gzip |
5235 |
|
5236 |
If no Accept-Encoding header is present in a request, the server MAY |
5237 |
assume that the client will accept any content coding. If an Accept- |
5238 |
Encoding header is present, and if the server cannot send a response |
5239 |
which is acceptable according to the Accept-Encoding header, then the |
5240 |
server SHOULD send an error response with the 406 (Not Acceptable) |
5241 |
status code. |
5242 |
|
5243 |
An empty Accept-Encoding value indicates none are acceptable. |
5244 |
|
5245 |
|
5246 |
14.4 Accept-Language |
5247 |
|
5248 |
The Accept-Language request-header field is similar to Accept, but |
5249 |
restricts the set of natural languages that are preferred as a response |
5250 |
to the request. |
5251 |
|
5252 |
Accept-Language = "Accept-Language" ":" |
5253 |
1#( language-range [ ";" "q" "=" qvalue ] ) |
5254 |
|
5255 |
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) |
5256 |
|
5257 |
Each language-range MAY be given an associated quality value which |
5258 |
represents an estimate of the user's preference for the languages |
5259 |
specified by that range. The quality value defaults to "q=1". For |
5260 |
example, |
5261 |
|
5262 |
Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
5263 |
|
5264 |
would mean: "I prefer Danish, but will accept British English and other |
5265 |
types of English." A language-range matches a language-tag if it exactly |
5266 |
equals the tag, or if it exactly equals a prefix of the tag such that |
5267 |
the first tag character following the prefix is "-". The special range |
5268 |
"*", if present in the Accept-Language field, matches every tag not |
5269 |
matched by any other range present in the Accept-Language field. |
5270 |
|
5271 |
Note: This use of a prefix matching rule does not imply that |
5272 |
language tags are assigned to languages in such a way that it is |
5273 |
always true that if a user understands a language with a certain |
5274 |
|
5275 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 89] |
5276 |
|
5277 |
|
5278 |
|
5279 |
|
5280 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5281 |
|
5282 |
|
5283 |
tag, then this user will also understand all languages with tags |
5284 |
for which this tag is a prefix. The prefix rule simply allows the |
5285 |
use of prefix tags if this is the case. |
5286 |
|
5287 |
The language quality factor assigned to a language-tag by the Accept- |
5288 |
Language field is the quality value of the longest language-range in the |
5289 |
field that matches the language-tag. If no language-range in the field |
5290 |
matches the tag, the language quality factor assigned is 0. If no |
5291 |
Accept-Language header is present in the request, the server SHOULD |
5292 |
assume that all languages are equally acceptable. If an Accept-Language |
5293 |
header is present, then all languages which are assigned a quality |
5294 |
factor greater than 0 are acceptable. |
5295 |
|
5296 |
It may be contrary to the privacy expectations of the user to send an |
5297 |
Accept-Language header with the complete linguistic preferences of the |
5298 |
user in every request. For a discussion of this issue, see section 15.7. |
5299 |
|
5300 |
Note: As intelligibility is highly dependent on the individual |
5301 |
user, it is recommended that client applications make the choice of |
5302 |
linguistic preference available to the user. If the choice is not |
5303 |
made available, then the Accept-Language header field must not be |
5304 |
given in the request. |
5305 |
|
5306 |
|
5307 |
14.5 Accept-Ranges |
5308 |
|
5309 |
The Accept-Ranges response header allows the server to indicate its |
5310 |
acceptance of range requests for a resource: |
5311 |
|
5312 |
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges |
5313 |
|
5314 |
acceptable-ranges = 1#range-unit | "none" |
5315 |
|
5316 |
Origin servers that accept byte-range requests MAY send |
5317 |
|
5318 |
Accept-Ranges: bytes |
5319 |
|
5320 |
but are not required to do so. Clients MAY generate byte-range requests |
5321 |
without having received this header for the plain resource involved. |
5322 |
|
5323 |
Servers that do not accept any kind of range request for a resource MAY |
5324 |
send |
5325 |
|
5326 |
Accept-Ranges: none |
5327 |
|
5328 |
to advise the client not to attempt a range request. |
5329 |
|
5330 |
|
5331 |
|
5332 |
|
5333 |
|
5334 |
|
5335 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 90] |
5336 |
|
5337 |
|
5338 |
|
5339 |
|
5340 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5341 |
|
5342 |
|
5343 |
14.6 Age |
5344 |
|
5345 |
The Age response-header field allows a cache to transmit age values |
5346 |
using: |
5347 |
|
5348 |
Age = "Age" ":" age-value |
5349 |
|
5350 |
age-value = delta-seconds |
5351 |
|
5352 |
Age values are non-negative decimal integers, representing time in |
5353 |
seconds. See section 13.2.3 for discussion of the use of Age. |
5354 |
|
5355 |
If a cache receives a value larger than the largest positive integer it |
5356 |
can represent, or if any of its age calculations overflows, it MUST |
5357 |
transmit an Age header with a value of 2147483648 (2^31). HTTP/1.1 |
5358 |
caches MUST send an Age header in every response. Caches SHOULD use an |
5359 |
arithmetic type of at least 31 bits of range. |
5360 |
|
5361 |
|
5362 |
14.7 Allow |
5363 |
|
5364 |
The Allow entity-header field lists the set of methods supported by the |
5365 |
resource identified by the Request-URI. The purpose of this field is |
5366 |
strictly to inform the recipient of valid methods associated with the |
5367 |
resource. An Allow header field MUST be present in a 405 (Method Not |
5368 |
Allowed) response. |
5369 |
|
5370 |
Allow = "Allow" ":" 1#method |
5371 |
|
5372 |
Example of use: |
5373 |
|
5374 |
Allow: GET, HEAD, PUT |
5375 |
|
5376 |
This field cannot prevent a client from trying other methods. However, |
5377 |
the indications given by the Allow header field value SHOULD be |
5378 |
followed. The actual set of allowed methods is defined by the origin |
5379 |
server at the time of each request. |
5380 |
|
5381 |
The Allow header field MAY be provided with a PUT request to recommend |
5382 |
the methods to be supported by the new or modified resource. The server |
5383 |
is not required to support these methods and SHOULD include an Allow |
5384 |
header in the response giving the actual supported methods. |
5385 |
|
5386 |
A proxy MUST NOT modify the Allow header field even if it does not |
5387 |
understand all the methods specified, since the user agent MAY have |
5388 |
other means of communicating with the origin server. |
5389 |
|
5390 |
The Allow header field does not indicate what methods are implemented at |
5391 |
the server level. Servers MAY use the Public response-header field |
5392 |
(section 14.35) to describe what methods are implemented on the server |
5393 |
as a whole. |
5394 |
|
5395 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 91] |
5396 |
|
5397 |
|
5398 |
|
5399 |
|
5400 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5401 |
|
5402 |
|
5403 |
14.8 Authorization |
5404 |
|
5405 |
A user agent that wishes to authenticate itself with a server--usually, |
5406 |
but not necessarily, after receiving a 401 response--MAY do so by |
5407 |
including an Authorization request-header field with the request. The |
5408 |
Authorization field value consists of credentials containing the |
5409 |
authentication information of the user agent for the realm of the |
5410 |
resource being requested. |
5411 |
|
5412 |
Authorization = "Authorization" ":" credentials |
5413 |
|
5414 |
HTTP access authentication is described in section 11. If a request is |
5415 |
authenticated and a realm specified, the same credentials SHOULD be |
5416 |
valid for all other requests within this realm. |
5417 |
|
5418 |
When a shared cache (see section 13.6) receives a request containing an |
5419 |
Authorization field, it MUST NOT return the corresponding response as a |
5420 |
reply to any other request, unless one of the following specific |
5421 |
exceptions holds: |
5422 |
|
5423 |
1. If the response includes the "proxy-revalidate" Cache-Control |
5424 |
directive, the cache MAY use that response in replying to a |
5425 |
subsequent request, but a proxy cache MUST first revalidate it with |
5426 |
the origin server, using the request-headers from the new request |
5427 |
to allow the origin server to authenticate the new request. |
5428 |
2. If the response includes the "must-revalidate" Cache-Control |
5429 |
directive, the cache MAY use that response in replying to a |
5430 |
subsequent request, but all caches MUST first revalidate it with |
5431 |
the origin server, using the request-headers from the new request |
5432 |
to allow the origin server to authenticate the new request. |
5433 |
3. If the response includes the "public" Cache-Control directive, it |
5434 |
may be returned in reply to any subsequent request. |
5435 |
|
5436 |
14.9 Cache-Control |
5437 |
|
5438 |
The Cache-Control general-header field is used to specify directives |
5439 |
that MUST be obeyed by all caching mechanisms along the request/response |
5440 |
chain. The directives specify behavior intended to prevent caches from |
5441 |
adversely interfering with the request or response. These directives |
5442 |
typically override the default caching algorithms. Cache directives are |
5443 |
unidirectional in that the presence of a directive in a request does not |
5444 |
imply that the same directive should be given in the response. |
5445 |
|
5446 |
Cache directives must be passed through by a proxy or gateway |
5447 |
application, regardless of their significance to that application, since |
5448 |
the directives may be applicable to all recipients along the |
5449 |
request/response chain. It is not possible to specify a cache-directive |
5450 |
for a specific cache. |
5451 |
|
5452 |
Cache-Control = "Cache-Control" ":" 1#cache-directive |
5453 |
|
5454 |
|
5455 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 92] |
5456 |
|
5457 |
|
5458 |
|
5459 |
|
5460 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5461 |
|
5462 |
|
5463 |
cache-directive = cache-request-directive |
5464 |
| cache-response-directive |
5465 |
|
5466 |
cache-request-directive = |
5467 |
| "no-cache" [ "=" <"> 1#field-name <"> ] |
5468 |
| "no-store" |
5469 |
| "max-age" "=" delta-seconds |
5470 |
| "max-stale" "=" delta-seconds |
5471 |
| "min-fresh" "=" delta-seconds |
5472 |
| "min-vers" "=" HTTP-Version |
5473 |
| "only-if-cached" |
5474 |
|
5475 |
cache-response-directive = |
5476 |
"public" |
5477 |
| "private" [ "=" <"> 1#field-name <"> ] |
5478 |
| "no-cache" [ "=" <"> 1#field-name <"> ] |
5479 |
| "no-store" |
5480 |
| "no-transform" |
5481 |
| "must-revalidate" |
5482 |
| "proxy-revalidate" |
5483 |
| "max-age" "=" delta-seconds |
5484 |
| "min-vers" "=" HTTP-Version |
5485 |
|
5486 |
When a directive appears without any 1#field-name parameter, the |
5487 |
directive applies to the entire request or response. When such a |
5488 |
directive appears with a 1#field-name parameter, it applies only to the |
5489 |
named field or fields, and not to the rest of the request or response. |
5490 |
This mechanism supports extensibility; implementations of future |
5491 |
versions of the HTTP protocol may apply these directives to header |
5492 |
fields not defined in HTTP/1.1. |
5493 |
|
5494 |
The cache-control directives can be broken down into these general |
5495 |
categories: |
5496 |
|
5497 |
. Restrictions on what is cachable; these may only be imposed by the |
5498 |
origin server. |
5499 |
. Restrictions on what may be stored by a cache; these may be imposed |
5500 |
by either the origin server or the user-agent. |
5501 |
. Modifications of the basic expiration mechanism; these may be |
5502 |
imposed by either the origin server or the user-agent. |
5503 |
. Controls over cache revalidation and reload; these may only be |
5504 |
imposed by an user-agent. |
5505 |
. Miscellaneous restrictions |
5506 |
|
5507 |
14.9.1 Cache-Control Restrictions on What is Cachable |
5508 |
|
5509 |
Unless specifically constrained by a Cache-Control directive, a caching |
5510 |
system may always store a successful response (see section 13.7) as a |
5511 |
cache entry, may return it without validation if it is fresh, and may |
5512 |
return it after successful validation. If there is neither a cache |
5513 |
validator nor an explicit expiration time associated with a response, we |
5514 |
|
5515 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 93] |
5516 |
|
5517 |
|
5518 |
|
5519 |
|
5520 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5521 |
|
5522 |
|
5523 |
do not expect it to be cached, but certain caches may violate this |
5524 |
expectation (for example, when little or no network connectivity is |
5525 |
available). A client can usually detect that such a response was taken |
5526 |
from a cache by comparing the Date header to the current time. |
5527 |
|
5528 |
Note that some HTTP/1.0 caches are known to violate this |
5529 |
expectation without providing any Warning. |
5530 |
|
5531 |
However, in some cases it may be inappropriate for a cache to retain a |
5532 |
entity, or to return it in response to a subsequent request. This may be |
5533 |
because absolute semantic transparency is deemed necessary by the |
5534 |
service author, or because of security or privacy considerations. |
5535 |
Certain Cache-Control directives are therefore provided so that the |
5536 |
server can indicate that certain resource entities, or portions thereof, |
5537 |
may not be cached regardless of other considerations. |
5538 |
|
5539 |
Note that section 14.8 normally prevents a shared cache from saving and |
5540 |
returning a response to a previous request if that request included an |
5541 |
Authorization header. |
5542 |
|
5543 |
The following Cache-Control response directives add or remove |
5544 |
restrictions on what is cachable: |
5545 |
|
5546 |
public |
5547 |
Overrides the restriction in section 14.8 that prevents a shared |
5548 |
cache from saving and returning a response to a previous request if |
5549 |
that request included an Authorization header. However, any other |
5550 |
constraints on caching still apply. |
5551 |
|
5552 |
private |
5553 |
Indicates that all or part of the response message is intended for a |
5554 |
single user and MUST NOT be cached by a shared cache. This allows an |
5555 |
origin server to state that the specified parts of the response are |
5556 |
intended for only one user and are not a valid response for requests |
5557 |
by other users. A private (non-shared) cache may ignore this |
5558 |
directive. |
5559 |
|
5560 |
Note: This usage of the word private only controls where the |
5561 |
response may be cached, and cannot ensure the privacy of the |
5562 |
message content. Note in particular that HTTP/1.0 caches will not |
5563 |
recognize or obey this directive. |
5564 |
|
5565 |
no-cache |
5566 |
indicates that all or part of the response message MUST NOT be cached |
5567 |
anywhere. This allows an origin server to prevent caching even by |
5568 |
caches that have been configured to return stale responses to client |
5569 |
requests. |
5570 |
|
5571 |
Note: HTTP/1.0 caches will not recognize or obey this directive. |
5572 |
|
5573 |
|
5574 |
|
5575 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 94] |
5576 |
|
5577 |
|
5578 |
|
5579 |
|
5580 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5581 |
|
5582 |
|
5583 |
14.9.2 What May be Stored by Caches |
5584 |
|
5585 |
The no-store directive applies to the entire message, and may be sent |
5586 |
either in a response or in a request. If sent in a request, a cache MUST |
5587 |
NOT store any part of either this request or any response to it. If sent |
5588 |
in a response, a cache MUST NOT store any part of either this response |
5589 |
or the request that elicited it. This directive applies to both non- |
5590 |
shared and shared caches. |
5591 |
|
5592 |
Even when this directive is associated with a response, users may |
5593 |
explicitly store such a response outside of the caching system (e.g., |
5594 |
with a "Save As" dialog). History buffers may store such responses as |
5595 |
part of their normal operation. |
5596 |
|
5597 |
The purpose of this directive is to meet the stated requirements of |
5598 |
certain users and service authors who are concerned about accidental |
5599 |
releases of information via unanticipated accesses to cache data |
5600 |
structures. While the use of this directive may improve privacy in some |
5601 |
cases, we caution that it is NOT in any way a reliable or sufficient |
5602 |
mechanism for ensuring privacy. In particular, HTTP/1.0 caches will not |
5603 |
recognize or obey this directive; malicious or compromised caches may |
5604 |
not recognize or obey this directive; and communications networks may be |
5605 |
vulnerable to eavesdropping. |
5606 |
|
5607 |
The min-vers directive applies to the entire message, and may be sent |
5608 |
either in a response or in a request. If sent in a request, a cache |
5609 |
whose HTTP version number is less than the specified version MUST NOT |
5610 |
store any part of either this request or any response to it. If sent in |
5611 |
a response, a cache whose HTTP version number is less than the specified |
5612 |
version MUST NOT store any part of either this response or the request |
5613 |
that elicited it, nor may any cache transmit a stored (non-first-hand) |
5614 |
copy of the response to any client with a lower HTTP version number. |
5615 |
This directive applies to both non-shared and shared caches, and is made |
5616 |
mandatory to allow for future protocol extensions that may affect |
5617 |
caching. |
5618 |
|
5619 |
Note that the lowest version that can be sensibly included in a |
5620 |
min-vers directive is HTTP/1.1, since HTTP/1.0 caches do not obey |
5621 |
it. |
5622 |
|
5623 |
|
5624 |
14.9.3 Modifications of the Basic Expiration Mechanism |
5625 |
|
5626 |
The expiration time of a entity may be specified by the origin server |
5627 |
using the Expires header (see section 14.21). Alternatively, it may be |
5628 |
specified using the max-age directive in a response. |
5629 |
|
5630 |
If a response includes both an Expires header and a max-age directive, |
5631 |
the max-age directive overrides the Expires header, even if the Expires |
5632 |
header is more restrictive. This rule allows an origin server to |
5633 |
provide, for a given response, a longer expiration time to an HTTP/1.1 |
5634 |
|
5635 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 95] |
5636 |
|
5637 |
|
5638 |
|
5639 |
|
5640 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5641 |
|
5642 |
|
5643 |
(or later) cache than to an HTTP/1.0 cache. This may be useful if |
5644 |
certain HTTP/1.0 caches improperly calculate ages or expiration times, |
5645 |
perhaps due to synchronized clocks. |
5646 |
|
5647 |
Other directives allow an end-user client to modify the basic expiration |
5648 |
mechanism. These directives may be specified on a request: |
5649 |
|
5650 |
max-age |
5651 |
Indicates that the client is willing to accept a response whose age |
5652 |
is no greater than the specified time in seconds. Unless max-stale |
5653 |
directive is also included, the client is not willing to accept a |
5654 |
stale response. |
5655 |
|
5656 |
min-fresh |
5657 |
Indicates that the client is willing to accept a response whose |
5658 |
freshness lifetime is no less than its current age plus the specified |
5659 |
time in seconds. That is, the client wants a response that will still |
5660 |
be fresh for at least the specified number of seconds. |
5661 |
|
5662 |
max-stale |
5663 |
Indicates that the client is willing to accept a response that has |
5664 |
exceeded its expiration time by no more than the specified number of |
5665 |
seconds. If a cache returns a stale response in response to such a |
5666 |
request, it MUST mark it as stale using the Warning header. |
5667 |
|
5668 |
If a cache returns a stale response, either because of a max-stale |
5669 |
directive on a request, or because the cache is configured to override |
5670 |
the expiration time of a response, the cache MUST attach a Warning |
5671 |
header to the stale response, using Warning 10 (Response is stale). |
5672 |
|
5673 |
|
5674 |
14.9.4 Cache Revalidation and Reload Controls |
5675 |
|
5676 |
Sometimes an end-user client may want or need to insist that a cache |
5677 |
revalidate its cache entry with the origin server (and not just with the |
5678 |
next cache along the path to the origin server), or to reload its cache |
5679 |
entry from the origin server. End-to-end revalidation may be necessary |
5680 |
if either the cache or the origin server has overestimated the |
5681 |
expiration time of the cached response. End-to-end reload may be |
5682 |
necessary if the cache entry has become corrupted for some reason. |
5683 |
|
5684 |
End-to-end revalidation may be requested either when the client does not |
5685 |
have its own local cached copy, in which case we call it "unspecified |
5686 |
end-to-end revalidation", or when the client does have a local cached |
5687 |
copy, in which case we call it "specific end-to-end revalidation." |
5688 |
|
5689 |
The client can specify these three kinds of action using Cache-Control |
5690 |
request directives: |
5691 |
|
5692 |
End-to-end reload |
5693 |
The request includes a "no-cache" Cache-Control directive or, for |
5694 |
|
5695 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 96] |
5696 |
|
5697 |
|
5698 |
|
5699 |
|
5700 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5701 |
|
5702 |
|
5703 |
compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field |
5704 |
names may be included with the no-cache directive in a request. The |
5705 |
server MUST NOT use a cached copy when responding to such a request. |
5706 |
|
5707 |
Specific end-to-end revalidation |
5708 |
The request includes a "max-age=0" Cache-Control directive, which |
5709 |
forces each cache along the path to the origin server to revalidate |
5710 |
its own entry, if any, with the next cache or server. The initial |
5711 |
request includes a cache-validating conditional with the client's |
5712 |
current validator. |
5713 |
|
5714 |
Unspecified end-to-end revalidation |
5715 |
The request includes "max-age=0" Cache-Control directive, which |
5716 |
forces each cache along the path to the origin server to revalidate |
5717 |
its own entry, if any, with the next cache or server. The initial |
5718 |
request does not include a cache-validating conditional; the first |
5719 |
cache along the path (if any) that holds a cache entry for this |
5720 |
resource includes a cache-validating conditional with its current |
5721 |
validator. |
5722 |
|
5723 |
When an intermediate cache is forced, by means of a max-age=0 directive, |
5724 |
to revalidate its own cache entry, and the client has supplied its own |
5725 |
validator in the request, the supplied validator may differ from the |
5726 |
validator currently stored with the cache entry. In this case, the cache |
5727 |
may use either validator in making its own request without affecting |
5728 |
semantic transparency. |
5729 |
|
5730 |
However, the choice of validator may affect performance. The best |
5731 |
approach is for the intermediate cache to use its own validator when |
5732 |
making its request. If the server replies with 304 (Not Modified), then |
5733 |
the cache should return its now validated copy to the client with a 200 |
5734 |
(OK) response. If the server replies with a new entity and cache |
5735 |
validator, however, the intermediate cache should compare the returned |
5736 |
validator with the one provided in the client's request, using the |
5737 |
strong comparison function. If the client's validator is equal to the |
5738 |
origin server's, then the intermediate cache simply returns 304 (Not |
5739 |
Modified). Otherwise, it returns the new entity with a 200 (OK) |
5740 |
response. |
5741 |
|
5742 |
If a request includes the no-cache directive, it should not include min- |
5743 |
fresh, max-stale, or max-age. |
5744 |
|
5745 |
In some cases, such as times of extremely poor network connectivity, a |
5746 |
client may want a cache to return only those responses that it currently |
5747 |
has stored, and not to reload or revalidate with the origin server. To |
5748 |
do this, the client may include the only-if-cached directive in a |
5749 |
request. If it receives this directive, a cache SHOULD either respond |
5750 |
using a cached entry that is consistent with the other constraints of |
5751 |
the request, or respond with a 504 (Gateway Timeout) status. However, if |
5752 |
a group of caches is being operated as a unified system with good |
5753 |
|
5754 |
|
5755 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 97] |
5756 |
|
5757 |
|
5758 |
|
5759 |
|
5760 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5761 |
|
5762 |
|
5763 |
internal connectivity, such a request MAY be forwarded within that group |
5764 |
of caches. |
5765 |
|
5766 |
Because a cache may be configured to ignore a server's specified |
5767 |
expiration time, and because a client request may include a max-stale |
5768 |
directive, which has a similar effect, the protocol also includes a |
5769 |
mechanism for the origin server to require revalidation of a cache entry |
5770 |
on any subsequent use. When the must-revalidate directive is present in |
5771 |
a response received by a cache, that cache MUST NOT use the entry after |
5772 |
it becomes stale to respond to a subsequent request without first |
5773 |
revalidating it with the origin server. (I.e., the cache must do an end- |
5774 |
to-end revalidation every time, if, based solely on the origin server's |
5775 |
Expires or max-age value, the cached response is stale.) |
5776 |
|
5777 |
The must-revalidate directive is necessary to support reliable operation |
5778 |
for certain protocol features. In all circumstances an HTTP/1.1 cache |
5779 |
MUST obey the must-revalidate directive; in particular, if the cache |
5780 |
cannot reach the origin server for any reason, it MUST generate a 504 |
5781 |
(Gateway Timeout) response. |
5782 |
|
5783 |
Servers should send the must-revalidate directive if and only if failure |
5784 |
to revalidate a request on the entity could result in incorrect |
5785 |
operation, such as a silently unexecuted financial transaction. |
5786 |
Recipients MUST NOT take any automated action that violates this |
5787 |
directive, and MUST NOT automatically provide an unvalidated copy of the |
5788 |
entity if revalidation fails. |
5789 |
|
5790 |
Although this is not recommended, user agents operating under severe |
5791 |
connectivity constraints may violate this directive but, if so, MUST |
5792 |
explicitly warn the user that an unvalidated response has been provided. |
5793 |
The warning MUST be provided on each unvalidated access, and SHOULD |
5794 |
require explicit user confirmation. |
5795 |
|
5796 |
The proxy-revalidate directive has the same meaning as the must- |
5797 |
revalidate directive, except that it does not apply to user-agent |
5798 |
caches. |
5799 |
|
5800 |
|
5801 |
14.9.5 Miscellaneous Restrictions |
5802 |
|
5803 |
In certain circumstances, an intermediate cache (proxy) may find it |
5804 |
useful to convert the encoding of an entity-body. For example, a proxy |
5805 |
might use a compressed content-coding to transfer the body to a client |
5806 |
on a slow link. |
5807 |
|
5808 |
Because end-to-end authentication of entity bodies and/or entity-headers |
5809 |
relies on the specific encoding of these values, such transformations |
5810 |
may cause authentication failures. Therefore, an intermediate cache MUST |
5811 |
NOT change the encoding of an entity-body if the response includes the |
5812 |
no-transform directive. |
5813 |
|
5814 |
|
5815 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 98] |
5816 |
|
5817 |
|
5818 |
|
5819 |
|
5820 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5821 |
|
5822 |
|
5823 |
14.10 Connection |
5824 |
|
5825 |
The Connection general-header field allows the sender to specify options |
5826 |
that are desired for that particular connection and MUST NOT be |
5827 |
communicated by proxies over further connections. |
5828 |
|
5829 |
The Connection header has the following grammar: |
5830 |
|
5831 |
Connection-header = "Connection" ":" 1#(connection-token) |
5832 |
connection-token = token |
5833 |
|
5834 |
HTTP/1.1 proxies MUST parse the Connection header field and, for every |
5835 |
connection-token in this field, remove a corresponding header field from |
5836 |
the request before the request is forwarded. The use of a connection |
5837 |
option is specified by the presence of a connection token in the |
5838 |
Connection header field, not by the corresponding additional header |
5839 |
field (which may not be present). |
5840 |
|
5841 |
When a client wishes to close a persistent connection it SHOULD send a |
5842 |
close connection-token, : |
5843 |
|
5844 |
Connection: close |
5845 |
|
5846 |
|
5847 |
14.11 Content-Base |
5848 |
|
5849 |
The Content-Base entity-header field may be used to specify the base URI |
5850 |
for resolving relative URLs within the entity. This header field is |
5851 |
described as Base in RFC 1808 , which is expected to be revised soon. |
5852 |
|
5853 |
Content-Base = "Content-Base" ":" absoluteURI |
5854 |
|
5855 |
If no Content-Base field is present, the base URI of an entity is |
5856 |
defined either by its Content-Location (if that Content-Location URI is |
5857 |
an absolute URI) or the URI used to initiate the request, in that order |
5858 |
of precedence. Note, however, that the base URI of the contents within |
5859 |
the entity-body may be redefined within that entity-body. |
5860 |
|
5861 |
|
5862 |
14.12 Content-Encoding |
5863 |
|
5864 |
The Content-Encoding entity-header field is used as a modifier to the |
5865 |
media-type. When present, its value indicates what additional content |
5866 |
codings have been applied to the entity-body, and thus what decoding |
5867 |
mechanisms MUST be applied in order to obtain the media-type referenced |
5868 |
by the Content-Type header field. Content-Encoding is primarily used to |
5869 |
allow a document to be compressed without losing the identity of its |
5870 |
underlying media type. |
5871 |
|
5872 |
Content-Encoding = "Content-Encoding" ":" 1#content-coding |
5873 |
|
5874 |
|
5875 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 99] |
5876 |
|
5877 |
|
5878 |
|
5879 |
|
5880 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5881 |
|
5882 |
|
5883 |
Content codings are defined in section 3.5. An example of its use is |
5884 |
|
5885 |
Content-Encoding: gzip |
5886 |
|
5887 |
The Content-Encoding is a characteristic of the entity identified by the |
5888 |
Request-URI. Typically, the entity-body is stored with this encoding and |
5889 |
is only decoded before rendering or analogous usage. |
5890 |
|
5891 |
If multiple encodings have been applied to a entity, the content codings |
5892 |
MUST be listed in the order in which they were applied. Additional |
5893 |
information about the encoding parameters MAY be provided by other |
5894 |
entity-header fields not defined by this specification. |
5895 |
|
5896 |
|
5897 |
14.13 Content-Language |
5898 |
|
5899 |
The Content-Language entity-header field describes the natural |
5900 |
language(s) of the intended audience for the enclosed entity. Note that |
5901 |
this may not be equivalent to all the languages used within the entity- |
5902 |
body. |
5903 |
|
5904 |
Content-Language = "Content-Language" ":" 1#language-tag |
5905 |
|
5906 |
Language tags are defined in section 3.10. The primary purpose of |
5907 |
Content-Language is to allow a user to identify and differentiate |
5908 |
entities according to the user's own preferred language. Thus, if the |
5909 |
body content is intended only for a Danish-literate audience, the |
5910 |
appropriate field is |
5911 |
|
5912 |
Content-Language: da |
5913 |
|
5914 |
If no Content-Language is specified, the default is that the content is |
5915 |
intended for all language audiences. This may mean that the sender does |
5916 |
not consider it to be specific to any natural language, or that the |
5917 |
sender does not know for which language it is intended. |
5918 |
|
5919 |
Multiple languages MAY be listed for content that is intended for |
5920 |
multiple audiences. For example, a rendition of the "Treaty of |
5921 |
Waitangi," presented simultaneously in the original Maori and English |
5922 |
versions, would call for |
5923 |
|
5924 |
Content-Language: mi, en |
5925 |
|
5926 |
However, just because multiple languages are present within an entity |
5927 |
does not mean that it is intended for multiple linguistic audiences. An |
5928 |
example would be a beginner's language primer, such as "A First Lesson |
5929 |
in Latin," which is clearly intended to be used by an English-literate |
5930 |
audience. In this case, the Content-Language should only include "en". |
5931 |
|
5932 |
Content-Language may be applied to any media type -- it is not limited |
5933 |
to textual documents. |
5934 |
|
5935 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 100] |
5936 |
|
5937 |
|
5938 |
|
5939 |
|
5940 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
5941 |
|
5942 |
|
5943 |
14.14 Content-Length |
5944 |
|
5945 |
The Content-Length entity-header field indicates the size of the |
5946 |
message-body, in decimal number of octets, sent to the recipient or, in |
5947 |
the case of the HEAD method, the size of the entity-body that would have |
5948 |
been sent had the request been a GET. |
5949 |
|
5950 |
Content-Length = "Content-Length" ":" 1*DIGIT |
5951 |
|
5952 |
An example is |
5953 |
|
5954 |
Content-Length: 3495 |
5955 |
|
5956 |
Applications SHOULD use this field to indicate the size of the message- |
5957 |
body to be transferred, regardless of the media type of the entity. It |
5958 |
must be possible for the recipient to reliably determine the end of |
5959 |
HTTP/1.1 requests containing an entity-body, e.g., because the request |
5960 |
has a valid Content-Length field, uses Transfer-Encoding: chunked or a |
5961 |
multipart body. |
5962 |
|
5963 |
Any Content-Length greater than or equal to zero is a valid value. |
5964 |
Section 4.4 describes how to determine the length of an message-body if |
5965 |
a Content-Length is not given. |
5966 |
|
5967 |
Note: The meaning of this field is significantly different from the |
5968 |
corresponding definition in MIME, where it is an optional field |
5969 |
used within the "message/external-body" content-type. In HTTP, it |
5970 |
SHOULD be sent whenever the message's length can be determined |
5971 |
prior to being transferred. |
5972 |
|
5973 |
|
5974 |
14.15 Content-Location |
5975 |
|
5976 |
The Content-Location entity-header field may be used to supply the |
5977 |
resource location for the entity enclosed in the message. In the case |
5978 |
where a resource has multiple entities associated with it, and those |
5979 |
entities actually have separate locations by which they might be |
5980 |
individually accessed, the server should provide a Content-Location for |
5981 |
the particular variant which is returned. In addition, a server SHOULD |
5982 |
provide a Content-Location with any response which was internally |
5983 |
redirected to a resource other than the one identified by the request. |
5984 |
|
5985 |
Content-Location = "Content-Location" ":" |
5986 |
( absoluteURI | relativeURI ) |
5987 |
|
5988 |
If no Content-Base header field is present, the value of Content- |
5989 |
Location also defines the base URL for the entity (see section 14.11). |
5990 |
|
5991 |
The Content-Location value is not a replacement for the original |
5992 |
requested URI; it is only a statement of the location of this particular |
5993 |
|
5994 |
|
5995 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 101] |
5996 |
|
5997 |
|
5998 |
|
5999 |
|
6000 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6001 |
|
6002 |
|
6003 |
entity at the time of the request. Future requests MAY use the Content- |
6004 |
Location URI if the desire is to identify that particular variant. |
6005 |
|
6006 |
A cache cannot assume that an entity with a Content-Location different |
6007 |
from the URI used to retrieve it can be used to respond to later |
6008 |
requests on that Content-Location URI. However, the Content-Location can |
6009 |
be used to differentiate between multiple entities retrieved from a |
6010 |
single requested resource, as described in section 13.5. |
6011 |
|
6012 |
If the Content-Location is a relative URI, the URI is interpreted |
6013 |
relative to any Content-Base URI provided in the response. If no |
6014 |
Content-Base is provided, the relative URI is interpreted relative to |
6015 |
the Request-URI. |
6016 |
|
6017 |
|
6018 |
14.16 Content-MD5 |
6019 |
|
6020 |
The Content-MD5 entity-header field, as defined in RFC 1864 [23] is an |
6021 |
MD5 digest of the entity-body, for the purpose of providing an end-to- |
6022 |
end message integrity check (MIC) of the entity-body. (Note: an MIC is |
6023 |
good for detecting accidental modification of the entity-body in |
6024 |
transit, but is not proof against malicious attacks.) |
6025 |
|
6026 |
ContentMD5 = "Content-MD5" ":" md5-digest |
6027 |
|
6028 |
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> |
6029 |
|
6030 |
The Content-MD5 header field may be generated by an origin server to |
6031 |
function as an integrity check of the entity-body. Only origin-servers |
6032 |
may generate the Content-MD5 header field; proxies and gateways MUST NOT |
6033 |
generate it, as this would defeat its value as an end-to-end integrity |
6034 |
check. Any recipient of the entity-body, including gateways and proxies, |
6035 |
MAY check that the digest value in this header field matches that of the |
6036 |
entity-body as received. |
6037 |
|
6038 |
The MD5 digest is computed based on the content of the entity-body, |
6039 |
including any Content-Encoding that has been applied, but not including |
6040 |
any Transfer-Encoding that may have been applied to the message-body. If |
6041 |
the message is received with a Transfer-Encoding, that encoding must be |
6042 |
removed prior to checking the Content-MD5 value against the received |
6043 |
entity. |
6044 |
|
6045 |
This has the result that the digest is computed on the octets of the |
6046 |
entity-body exactly as, and in the order that, they would be sent if no |
6047 |
Transfer-Encoding were being applied. |
6048 |
|
6049 |
HTTP extends RFC 1864 to permit the digest to be computed for MIME |
6050 |
composite media-types (e.g., multipart/* and message/rfc822), but this |
6051 |
does not change how the digest is computed as defined in the preceding |
6052 |
paragraph. |
6053 |
|
6054 |
|
6055 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 102] |
6056 |
|
6057 |
|
6058 |
|
6059 |
|
6060 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6061 |
|
6062 |
|
6063 |
Note: There are several consequences of this. The entity-body for |
6064 |
composite types may contain many body-parts, each with its own MIME |
6065 |
and HTTP headers (including Content-MD5, Content-Transfer-Encoding, |
6066 |
and Content-Encoding headers). If a body-part has a Content- |
6067 |
Transfer-Encoding or Content-Encoding header, it is assumed that |
6068 |
the content of the body-part has had the encoding applied, and the |
6069 |
body-part is included in the Content-MD5 digest as is -- i.e., |
6070 |
after the application. The Transfer-Encoding header field is not |
6071 |
allowed within body-parts. |
6072 |
|
6073 |
Note: while the definition of Content-MD5 is exactly the same for |
6074 |
HTTP as in RFC 1864 for MIME entity-bodies, there are several ways |
6075 |
in which the application of Content-MD5 to HTTP entity-bodies |
6076 |
differs from its application to MIME entity-bodies. One is that |
6077 |
HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does |
6078 |
use Transfer-Encoding and Content-Encoding. Another is that HTTP |
6079 |
more frequently uses binary content types than MIME, so it is worth |
6080 |
noting that, in such cases, the byte order used to compute the |
6081 |
digest is the transmission byte order defined for the type. Lastly, |
6082 |
HTTP allows transmission of text types with any of several line |
6083 |
break conventions and not just the canonical form using CRLF. |
6084 |
Conversion of all line breaks to CRLF should not be done before |
6085 |
computing or checking the digest: the line break convention used in |
6086 |
the text actually transmitted should be left unaltered when |
6087 |
computing the digest. |
6088 |
|
6089 |
|
6090 |
14.17 Content-Range |
6091 |
|
6092 |
When a server returns a partial response to a client, it must describe |
6093 |
both the extent of the range covered by the response, and the length of |
6094 |
the entire entity-body. |
6095 |
|
6096 |
content-range-spec = byte-content-range-spec |
6097 |
|
6098 |
byte-content-range-spec = bytes-unit SP first-byte-pos "-" |
6099 |
last-byte-pos "/" entity-length |
6100 |
|
6101 |
entity-length = 1*DIGIT |
6102 |
|
6103 |
Unlike byte-ranges-specifier values, a byte-content-range-spec may only |
6104 |
specify one range, and must contain absolute byte positions for both the |
6105 |
first and last byte of the range. |
6106 |
|
6107 |
A byte-content-range-spec whose last-byte-pos value is less than its |
6108 |
first-byte-pos value, or whose entity-length value is less than or equal |
6109 |
to its last-byte-pos value, is invalid. The recipient of an invalid |
6110 |
byte-content-range-spec MUST ignore it and any content transferred along |
6111 |
with it. |
6112 |
|
6113 |
|
6114 |
|
6115 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 103] |
6116 |
|
6117 |
|
6118 |
|
6119 |
|
6120 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6121 |
|
6122 |
|
6123 |
Examples of byte-content-range-spec values, assuming that the entity |
6124 |
contains a total of 1234 bytes: |
6125 |
|
6126 |
. The first 500 bytes: |
6127 |
bytes 0-499/1234 |
6128 |
|
6129 |
. The second 500 bytes: |
6130 |
bytes 500-999/1234 |
6131 |
|
6132 |
. All except for the first 500 bytes: |
6133 |
bytes 500-1233/1234 |
6134 |
|
6135 |
. The last 500 bytes: |
6136 |
bytes 734-1233/1234 |
6137 |
|
6138 |
The Content-Range header is sent with a partial entity-body to specify |
6139 |
where in the full entity-body the partial body should be inserted. It |
6140 |
also indicates the total size of the full entity-body. |
6141 |
|
6142 |
Content-Range = "Content-Range" ":" content-range-spec |
6143 |
|
6144 |
When an HTTP message includes the content of a single range (for |
6145 |
example, a response to a request for a single range, or to a request for |
6146 |
a set of ranges that overlap without any holes), this content is |
6147 |
transmitted with a Content-Range header, and a Content-Length header |
6148 |
showing the number of bytes actually transferred. For example, |
6149 |
|
6150 |
HTTP/1.1 206 Partial content |
6151 |
Date: Wed, 15 Nov 1995 06:25:24 GMT |
6152 |
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT |
6153 |
Content-Range: 21010-47021/47022 |
6154 |
Content-Length: 26012 |
6155 |
Content-Type: image/gif |
6156 |
|
6157 |
When an HTTP message includes the content of multiple ranges (for |
6158 |
example, a response to a request for multiple non-overlapping ranges), |
6159 |
these are transmitted as a multipart MIME message. The multipart MIME |
6160 |
content-type used for this purpose is defined in this specification to |
6161 |
be "multipart/byteranges". See appendix 19.2 for its definition. |
6162 |
|
6163 |
A client that cannot decode a MIME multipart/byteranges message should |
6164 |
not ask for multiple byte-ranges in a single request. |
6165 |
|
6166 |
When a client requests multiple byte-ranges in one request, the server |
6167 |
SHOULD return them in the order that they appeared in the request. |
6168 |
|
6169 |
If the server ignores a byte-range-spec because it is invalid, the |
6170 |
server should treat the request as if the invalid Range header field did |
6171 |
not exist. (Normally, this means return a 200 response containing the |
6172 |
full entity). The reason is that the only time a client will make such |
6173 |
|
6174 |
|
6175 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 104] |
6176 |
|
6177 |
|
6178 |
|
6179 |
|
6180 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6181 |
|
6182 |
|
6183 |
an invalid request is when the entity is smaller than the entity |
6184 |
retrieved by a prior request. |
6185 |
|
6186 |
|
6187 |
14.18 Content-Type |
6188 |
|
6189 |
The Content-Type entity-header field indicates the media type of the |
6190 |
entity-body sent to the recipient or, in the case of the HEAD method, |
6191 |
the media type that would have been sent had the request been a GET. |
6192 |
|
6193 |
Content-Type = "Content-Type" ":" media-type |
6194 |
|
6195 |
Media types are defined in section 3.7. An example of the field is |
6196 |
|
6197 |
Content-Type: text/html; charset=ISO-8859-4 |
6198 |
|
6199 |
Further discussion of methods for identifying the media type of an |
6200 |
entity is provided in section 7.2.1. |
6201 |
|
6202 |
|
6203 |
14.19 Date |
6204 |
|
6205 |
The Date general-header field represents the date and time at which the |
6206 |
message was originated, having the same semantics as orig-date in RFC |
6207 |
822. The field value is an HTTP-date, as described in section 3.3.1. |
6208 |
|
6209 |
Date = "Date" ":" HTTP-date |
6210 |
|
6211 |
An example is |
6212 |
|
6213 |
Date: Tue, 15 Nov 1994 08:12:31 GMT |
6214 |
|
6215 |
If a message is received via direct connection with the user agent (in |
6216 |
the case of requests) or the origin server (in the case of responses), |
6217 |
then the date can be assumed to be the current date at the receiving |
6218 |
end. However, since the date--as it is believed by the origin--is |
6219 |
important for evaluating cached responses, origin servers MUST always |
6220 |
include a Date header field in all responses. Clients SHOULD only send a |
6221 |
Date header field in messages that include an entity-body, as in the |
6222 |
case of the PUT and POST requests, and even then it is optional. A |
6223 |
received message which does not have a Date header field SHOULD be |
6224 |
assigned one by the recipient if the message will be cached by that |
6225 |
recipient or gatewayed via a protocol which requires a Date. |
6226 |
|
6227 |
In theory, the date SHOULD represent the moment just before the entity |
6228 |
is generated. In practice, the date can be generated at any time during |
6229 |
the message origination without affecting its semantic value. |
6230 |
|
6231 |
Although origin servers MUST send a Date field in every response, if a |
6232 |
cache receives a response without a Date field, it SHOULD attach one |
6233 |
|
6234 |
|
6235 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 105] |
6236 |
|
6237 |
|
6238 |
|
6239 |
|
6240 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6241 |
|
6242 |
|
6243 |
with the cache's best estimate of the time at which the response was |
6244 |
originally sent. |
6245 |
|
6246 |
The format of the Date is an absolute date and time as defined by HTTP- |
6247 |
date in section 3.3; it MUST be sent in RFC1123 [8]-date format. |
6248 |
|
6249 |
|
6250 |
14.20 ETag |
6251 |
|
6252 |
The ETag entity-header field defines the entity tag for the associated |
6253 |
entity. The headers used with entity tags are described in sections |
6254 |
14.20, 14.25, 14.26 and 14.43. The entity tag may be used for comparison |
6255 |
with other entities from the same resource (see section 13.3.2). |
6256 |
|
6257 |
ETag = "ETag" ":" entity-tag |
6258 |
|
6259 |
Examples: |
6260 |
|
6261 |
ETag: "xyzzy" |
6262 |
ETag: W/"xyzzy" |
6263 |
ETag: "" |
6264 |
|
6265 |
|
6266 |
14.21 Expires |
6267 |
|
6268 |
The Expires entity-header field gives the date/time after which the |
6269 |
response should be considered stale. A stale cache entry may not |
6270 |
normally be returned by a cache (either a proxy cache or an end-user |
6271 |
cache) unless it is first validated with the origin server (or with an |
6272 |
intermediate cache that has a fresh copy of the entity). See section |
6273 |
13.2 for further discussion of the expiration model. |
6274 |
|
6275 |
The presence of an Expires field does not imply that the original |
6276 |
resource will change or cease to exist at, before, or after that time. |
6277 |
|
6278 |
The format is an absolute date and time as defined by HTTP-date in |
6279 |
section 3.3; it MUST be in RFC1123-date format: |
6280 |
|
6281 |
Expires = "Expires" ":" HTTP-date |
6282 |
|
6283 |
An example of its use is |
6284 |
|
6285 |
Expires: Thu, 01 Dec 1994 16:00:00 GMT |
6286 |
|
6287 |
Note: if a response includes a Cache-Control field with the max-age |
6288 |
directive, that directive overrides the Expires field. |
6289 |
|
6290 |
HTTP/1.1 clients and caches MUST treat other invalid date formats, |
6291 |
especially including the value "0", as in the past (i.e., "already |
6292 |
expired"). |
6293 |
|
6294 |
|
6295 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 106] |
6296 |
|
6297 |
|
6298 |
|
6299 |
|
6300 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6301 |
|
6302 |
|
6303 |
To mark a response as "already expired," an origin server should use an |
6304 |
Expires date that is equal to the Date header value. (See the rules for |
6305 |
expiration calculations in section 13.2.4.) |
6306 |
|
6307 |
To mark a response as "never expires," an origin server should use an |
6308 |
Expires date approximately one year from the time the response is sent. |
6309 |
HTTP/1.1 servers should not send Expires dates more than one year in the |
6310 |
future. |
6311 |
|
6312 |
|
6313 |
14.22 From |
6314 |
|
6315 |
The From request-header field, if given, SHOULD contain an Internet e- |
6316 |
mail address for the human user who controls the requesting user agent. |
6317 |
The address SHOULD be machine-usable, as defined by mailbox in RFC 822 |
6318 |
(as updated by RFC 1123 ): |
6319 |
|
6320 |
From = "From" ":" mailbox |
6321 |
|
6322 |
An example is: |
6323 |
|
6324 |
From: webmaster@w3.org |
6325 |
|
6326 |
This header field MAY be used for logging purposes and as a means for |
6327 |
identifying the source of invalid or unwanted requests. It SHOULD NOT be |
6328 |
used as an insecure form of access protection. The interpretation of |
6329 |
this field is that the request is being performed on behalf of the |
6330 |
person given, who accepts responsibility for the method performed. In |
6331 |
particular, robot agents SHOULD include this header so that the person |
6332 |
responsible for running the robot can be contacted if problems occur on |
6333 |
the receiving end. |
6334 |
|
6335 |
The Internet e-mail address in this field MAY be separate from the |
6336 |
Internet host which issued the request. For example, when a request is |
6337 |
passed through a proxy the original issuer's address SHOULD be used. |
6338 |
|
6339 |
Note: The client SHOULD not send the From header field without the |
6340 |
user's approval, as it may conflict with the user's privacy |
6341 |
interests or their site's security policy. It is strongly |
6342 |
recommended that the user be able to disable, enable, and modify |
6343 |
the value of this field at any time prior to a request. |
6344 |
|
6345 |
|
6346 |
14.23 Host |
6347 |
|
6348 |
The Host request-header field specifies the Internet host and port |
6349 |
number of the resource being requested, as obtained from the original |
6350 |
URL given by the user or referring resource (generally an HTTP URL, as |
6351 |
described in section 3.2.2). The Host field value MUST represent the |
6352 |
network location of the origin server or gateway given by the original |
6353 |
URL. This allows the origin server or gateway to differentiate between |
6354 |
|
6355 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 107] |
6356 |
|
6357 |
|
6358 |
|
6359 |
|
6360 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6361 |
|
6362 |
|
6363 |
internally-ambiguous URLs, such as the root "/" URL of a server for |
6364 |
multiple host names on a single IP address. |
6365 |
|
6366 |
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 |
6367 |
|
6368 |
A "host" without any trailing port information implies the default port |
6369 |
for the service requested (e.g., "80" for an HTTP URL). For example, a |
6370 |
request on the origin server for <http://www.w3.org/pub/WWW/> MUST |
6371 |
include: |
6372 |
|
6373 |
GET /pub/WWW/ HTTP/1.1 |
6374 |
Host: www.w3.org |
6375 |
|
6376 |
A client MUST include a Host header field in all HTTP/1.1 request |
6377 |
messages on the Internet (i.e., on any message corresponding to a |
6378 |
request for a URL which includes an Internet host address for the |
6379 |
service being requested). If the Host field is not already present, an |
6380 |
HTTP/1.1 proxy MUST add a Host field to the request message prior to |
6381 |
forwarding it on the Internet. All Internet-based HTTP/1.1 servers MUST |
6382 |
respond with a 400 status code to any HTTP/1.1 request message which |
6383 |
lacks a Host header field. |
6384 |
|
6385 |
See sections 5.2 and 19.5.1 for other requirements relating to Host. |
6386 |
|
6387 |
|
6388 |
14.24 If-Modified-Since |
6389 |
|
6390 |
The If-Modified-Since request-header field is used with the GET method |
6391 |
to make it conditional: if the requested variant has not been modified |
6392 |
since the time specified in this field, an entity will not be returned |
6393 |
from the server; instead, a 304 (not modified) response will be returned |
6394 |
without any message-body. |
6395 |
|
6396 |
If-Modified-Since = "If-Modified-Since" ":" HTTP-date |
6397 |
|
6398 |
An example of the field is: |
6399 |
|
6400 |
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
6401 |
|
6402 |
A GET method with an If-Modified-Since header and no Range header |
6403 |
requests that the identified entity be transferred only if it has been |
6404 |
modified since the date given by the If-Modified-Since header. The |
6405 |
algorithm for determining this includes the following cases: |
6406 |
|
6407 |
|
6408 |
a)If the request would normally result in anything other than a 200 |
6409 |
(OK) status, or if the passed If-Modified-Since date is invalid, the |
6410 |
response is exactly the same as for a normal GET. A date which is |
6411 |
later than the server's current time is invalid. |
6412 |
|
6413 |
|
6414 |
|
6415 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 108] |
6416 |
|
6417 |
|
6418 |
|
6419 |
|
6420 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6421 |
|
6422 |
|
6423 |
b)If the variant has been modified since the If-Modified-Since date, |
6424 |
the response is exactly the same as for a normal GET. |
6425 |
|
6426 |
|
6427 |
c)If the variant has not been modified since a valid If-Modified-Since |
6428 |
date, the server MUST return a 304 (Not Modified) response. |
6429 |
|
6430 |
The purpose of this feature is to allow efficient updates of cached |
6431 |
information with a minimum amount of transaction overhead. |
6432 |
|
6433 |
Note that the Range request-header field modifies the meaning of |
6434 |
If-Modified-Since; see section 14.36 for full details. |
6435 |
|
6436 |
Note that If-Modified-Since times are interpreted by the server, |
6437 |
whose clock may not be synchronized with the client. |
6438 |
|
6439 |
Note that if a client uses an arbitrary date in the If-Modified-Since |
6440 |
header instead of a date taken from the Last-Modified header for the |
6441 |
same request, the client should be aware of the fact that this date is |
6442 |
interpreted in the server's understanding of time. The client should |
6443 |
consider unsynchronized clocks and rounding problems due to the |
6444 |
different encodings of time between the client and server. This includes |
6445 |
the possibility of race conditions if the document has changed between |
6446 |
the time it was first requested and the If-Modified-Since date of a |
6447 |
subsequent request, and the possibility of clock-skew-related problems |
6448 |
if the If-Modified-Date date is derived from the client's clock without |
6449 |
correction to the server's clock. Corrections for different time bases |
6450 |
between client and server are at best approximate due to network |
6451 |
latency. |
6452 |
|
6453 |
|
6454 |
14.25 If-Match |
6455 |
|
6456 |
The If-Match request-header field is used with a method to make it |
6457 |
conditional. A client that has one or more entities previously obtained |
6458 |
from the resource can verify that one of those entities is current by |
6459 |
including a list of their associated entity tags in the If-Match header |
6460 |
field. The purpose of this feature is to allow efficient updates of |
6461 |
cached information with a minimum amount of transaction overhead. It is |
6462 |
also used, on updating requests, to prevent inadvertent modification of |
6463 |
the wrong version of a resource. As a special case, the value "*" |
6464 |
matches any current entity of the resource. |
6465 |
|
6466 |
If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) |
6467 |
|
6468 |
If any of the entity tags match the entity tag of the entity that would |
6469 |
have been returned in the response to a similar GET request (without the |
6470 |
If-Match header) on that resource, or if "*" is given and any current |
6471 |
entity exists for that resource, then the server MAY perform the |
6472 |
requested method as if the If-Match header field did not exist. |
6473 |
|
6474 |
|
6475 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 109] |
6476 |
|
6477 |
|
6478 |
|
6479 |
|
6480 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6481 |
|
6482 |
|
6483 |
A server MUST use the strong comparison function (see section 3.11) to |
6484 |
compare the entity tags in If-Match. |
6485 |
|
6486 |
If none of the entity tags match, or if "*" is given and no current |
6487 |
entity exists, the server MUST NOT perform the requested method, and |
6488 |
MUST return a 412 (Precondition Failed) response. This behavior is most |
6489 |
useful when the client wants to prevent an updating method, such as PUT, |
6490 |
from modifying a resource that has changed since the client last |
6491 |
retrieved it. |
6492 |
|
6493 |
If the request would, without the If-Match header field, result in |
6494 |
anything other than a 2xx status, then the If-Match header MUST be |
6495 |
ignored. |
6496 |
|
6497 |
Note: The meaning of "If-Match: *" is that the method SHOULD be |
6498 |
performed if the representation selected by the origin server (or |
6499 |
by a cache, possibly using the Vary mechanism, see section 14.43) |
6500 |
exists, and MUST NOT be performed if the representation does not |
6501 |
exist. For example, |
6502 |
|
6503 |
PUT /foo.html HTTP/1.1 |
6504 |
Host: www.w3.org |
6505 |
If-Match: * |
6506 |
|
6507 |
may be performed only if /foo.html exists. |
6508 |
|
6509 |
An updating request (e.g., a PUT or POST) on a resource should include |
6510 |
only one entity tag, the one associated with the particular variant |
6511 |
whose value is being conditionally updated. |
6512 |
|
6513 |
Examples: |
6514 |
|
6515 |
If-Match: "xyzzy" |
6516 |
If-Match: W/"xyzzy" |
6517 |
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
6518 |
If-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
6519 |
If-Match: * |
6520 |
|
6521 |
|
6522 |
14.26 If-None-Match |
6523 |
|
6524 |
The If-None-Match request-header field is used with a method to make it |
6525 |
conditional. A client that has one or more entities previously obtained |
6526 |
from the resource can verify that none of those entities is current by |
6527 |
including a list of their associated entity tags in the If-None-Match |
6528 |
header field. The purpose of this feature is to allow efficient updates |
6529 |
of cached information with a minimum amount of transaction overhead. It |
6530 |
is also used, on updating requests, to prevent inadvertent modification |
6531 |
of a resource which was not known to exist. |
6532 |
|
6533 |
|
6534 |
|
6535 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 110] |
6536 |
|
6537 |
|
6538 |
|
6539 |
|
6540 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6541 |
|
6542 |
|
6543 |
As a special case, the value "*" matches any current entity of the |
6544 |
resource. |
6545 |
|
6546 |
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) |
6547 |
|
6548 |
If any of the entity tags match the entity tag of the entity that would |
6549 |
have been returned in the response to a similar GET request (without the |
6550 |
If-None-Match header) on that resource, or if "*" is given and any |
6551 |
current entity exists for that resource, then the server MUST NOT |
6552 |
perform the requested method. Instead, if the request method was GET or |
6553 |
HEAD, the server SHOULD respond with a 304 (Not Modified) response, |
6554 |
including the cache-related entity-header fields (particularly ETag) of |
6555 |
one of the entities that matched. For all other request methods, the |
6556 |
server MUST respond with a status of 412 (Precondition Failed). |
6557 |
|
6558 |
See section 13.3.3 for rules on how to determine if two entity tags |
6559 |
match. The weak comparison function can only be used with GET or HEAD |
6560 |
requests. |
6561 |
|
6562 |
If none of the entity tags match, or if "*" is given and no current |
6563 |
entity exists, then the server MAY perform the requested method as if |
6564 |
the If-None-Match header field did not exist. |
6565 |
|
6566 |
If the request would, without the If-None-Match header field, result in |
6567 |
anything other than a 2xx status, then the If-None-Match header MUST be |
6568 |
ignored. |
6569 |
|
6570 |
Note: The meaning of "If-None-Match: *" is that the method MUST NOT |
6571 |
be performed if the representation selected by the origin server |
6572 |
(or by a cache, possibly using the Vary mechanism, see section |
6573 |
14.43) exists, and SHOULD be performed if the representation does |
6574 |
not exist. For example, |
6575 |
|
6576 |
PUT /foo.html HTTP/1.1 |
6577 |
Host: www.w3.org |
6578 |
If-None-Match: * |
6579 |
|
6580 |
may be performed only if /foo.html does not exist. This feature may |
6581 |
be useful in preventing races between PUT operations. |
6582 |
|
6583 |
Examples: |
6584 |
|
6585 |
If-None-Match: "xyzzy" |
6586 |
If-None-Match: W/"xyzzy" |
6587 |
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
6588 |
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
6589 |
If-None-Match: * |
6590 |
|
6591 |
|
6592 |
|
6593 |
|
6594 |
|
6595 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 111] |
6596 |
|
6597 |
|
6598 |
|
6599 |
|
6600 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6601 |
|
6602 |
|
6603 |
14.27 If-Range |
6604 |
|
6605 |
If a client has a partial copy of an entity in its cache, and wishes to |
6606 |
have an up-to-date copy of the entire entity in its cache, it could use |
6607 |
the Range request-header with a conditional GET (using either or both of |
6608 |
If-Unmodified-Since and If-Match.) However, if the condition fails |
6609 |
because the entity has been modified, the client would then have to make |
6610 |
a second request to obtain the entire current entity-body. |
6611 |
|
6612 |
The If-Range header allows a client to "short-circuit" the second |
6613 |
request. Informally, its meaning is `if the entity is unchanged, send me |
6614 |
the part(s) that I am missing; otherwise, send me the entire new |
6615 |
entity.' |
6616 |
|
6617 |
If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) |
6618 |
|
6619 |
If the client has no entity tag for an entity, but does have a Last- |
6620 |
Modified date, it may use that date in a If-Range header. (The server |
6621 |
can distinguish between a valid HTTP-date and any form of entity-tag by |
6622 |
examining no more than two characters.) The If-Range header should only |
6623 |
be used together with a Range header, and must be ignored if the request |
6624 |
does not include a Range header, or if the server does not support the |
6625 |
sub-range operation. |
6626 |
|
6627 |
If the entity tag given in the If-Range header matches the current |
6628 |
entity tag for the entity, then the server should provide the specified |
6629 |
sub-range of the entity using a 206 (Partial content) response. If the |
6630 |
entity tag does not match, then the server should return the entire |
6631 |
entity using a 200 (OK) response. |
6632 |
|
6633 |
|
6634 |
14.28 If-Unmodified-Since |
6635 |
|
6636 |
The If-Unmodified-Since request-header field is used with a method to |
6637 |
make it conditional. If the requested resource has not been modified |
6638 |
since the time specified in this field, the server should perform the |
6639 |
requested operation as if the If-Unmodified-Since header were not |
6640 |
present. |
6641 |
|
6642 |
If the requested variant has been modified since the specified time, the |
6643 |
server MUST NOT perform the requested operation, and MUST return a 412 |
6644 |
(Precondition Failed). |
6645 |
|
6646 |
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date |
6647 |
|
6648 |
An example of the field is: |
6649 |
|
6650 |
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
6651 |
|
6652 |
|
6653 |
|
6654 |
|
6655 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 112] |
6656 |
|
6657 |
|
6658 |
|
6659 |
|
6660 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6661 |
|
6662 |
|
6663 |
If the request normally (i.e., without the If-Unmodified-Since header) |
6664 |
would result in anything other than a 2xx status, the If-Unmodified- |
6665 |
Since header should be ignored. |
6666 |
|
6667 |
If the specified date is invalid, the header is ignored. |
6668 |
|
6669 |
|
6670 |
14.29 Last-Modified |
6671 |
|
6672 |
The Last-Modified entity-header field indicates the date and time at |
6673 |
which the origin server believes the variant was last modified. . |
6674 |
|
6675 |
Last-Modified = "Last-Modified" ":" HTTP-date |
6676 |
|
6677 |
An example of its use is |
6678 |
|
6679 |
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
6680 |
|
6681 |
The exact meaning of this header field depends on the implementation of |
6682 |
the origin server and the nature of the original resource. For files, it |
6683 |
may be just the file system last-modified time. For entities with |
6684 |
dynamically included parts, it may be the most recent of the set of |
6685 |
last-modify times for its component parts. For database gateways, it may |
6686 |
be the last-update time stamp of the record. For virtual objects, it may |
6687 |
be the last time the internal state changed. |
6688 |
|
6689 |
An origin server MUST NOT send a Last-Modified date which is later than |
6690 |
the server's time of message origination. In such cases, where the |
6691 |
resource's last modification would indicate some time in the future, the |
6692 |
server MUST replace that date with the message origination date. |
6693 |
|
6694 |
An origin server should obtain the Last-Modified value of the entity as |
6695 |
close as possible to the time that it generates the Date value of its |
6696 |
response. This allows a recipient to make an accurate assessment of the |
6697 |
entity's modification time, especially if the entity changes near the |
6698 |
time that the response is generated. |
6699 |
|
6700 |
To preserve compatibility with HTTP/1.0 clients and caches, and because |
6701 |
the Last-Modified date may be useful for purposes other than cache |
6702 |
validation, HTTP/1.1 servers SHOULD send Last-Modified whenever |
6703 |
feasible. |
6704 |
|
6705 |
|
6706 |
14.30 Location |
6707 |
|
6708 |
The Location response-header field is used to redirect the recipient to |
6709 |
a location other than the Request-URI for completion of the request or |
6710 |
identification of a new resource. For 201 (Created) responses, the |
6711 |
Location is that of the new resource which was created by the request. |
6712 |
For 3xx responses, the location SHOULD indicate the server's preferred |
6713 |
|
6714 |
|
6715 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 113] |
6716 |
|
6717 |
|
6718 |
|
6719 |
|
6720 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6721 |
|
6722 |
|
6723 |
URL for automatic redirection to the resource. The field value consists |
6724 |
of a single absolute URL. |
6725 |
|
6726 |
Location = "Location" ":" absoluteURI |
6727 |
|
6728 |
An example is |
6729 |
|
6730 |
Location: http://www.w3.org/pub/WWW/People.html |
6731 |
|
6732 |
Note: The Content-Location header field (section 14.15) differs |
6733 |
from Location in that the Content-Location identifies the original |
6734 |
location of the entity enclosed in the request. It is therefore |
6735 |
possible for a response to contain header fields for both Location |
6736 |
and Content-Location. Also see section 13.8 for cache requirements |
6737 |
of some methods. |
6738 |
|
6739 |
|
6740 |
14.31 Max-Forwards |
6741 |
|
6742 |
The Max-Forwards general-header field may be used with the TRACE method |
6743 |
(section 14.31) to limit the number of proxies or gateways that can |
6744 |
forward the request to the next inbound server. This can be useful when |
6745 |
the client is attempting to trace a request chain which appears to be |
6746 |
failing or looping in mid-chain. |
6747 |
|
6748 |
Max-Forwards = "Max-Forwards" ":" 1*DIGIT |
6749 |
|
6750 |
The Max-Forwards value is a decimal integer indicating the remaining |
6751 |
number of times this request message may be forwarded. |
6752 |
|
6753 |
Each proxy or gateway recipient of a TRACE request containing a Max- |
6754 |
Forwards header field SHOULD check and update its value prior to |
6755 |
forwarding the request. If the received value is zero (0), the recipient |
6756 |
SHOULD NOT forward the request; instead, it SHOULD respond as the final |
6757 |
recipient with a 200 (OK) response containing the received request |
6758 |
message as the response entity-body (as described in section 9.8). If |
6759 |
the received Max-Forwards value is greater than zero, then the forwarded |
6760 |
message SHOULD contain an updated Max-Forwards field with a value |
6761 |
decremented by one (1). |
6762 |
|
6763 |
The Max-Forwards header field SHOULD be ignored for all other methods |
6764 |
defined by this specification and for any extension methods for which it |
6765 |
is not explicitly referred to as part of that method definition. |
6766 |
|
6767 |
|
6768 |
14.32 Pragma |
6769 |
|
6770 |
The Pragma general-header field is used to include implementation- |
6771 |
specific directives that may apply to any recipient along the |
6772 |
request/response chain. All pragma directives specify optional behavior |
6773 |
|
6774 |
|
6775 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 114] |
6776 |
|
6777 |
|
6778 |
|
6779 |
|
6780 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6781 |
|
6782 |
|
6783 |
from the viewpoint of the protocol; however, some systems MAY require |
6784 |
that behavior be consistent with the directives. |
6785 |
|
6786 |
Pragma = "Pragma" ":" 1#pragma-directive |
6787 |
|
6788 |
pragma-directive = "no-cache" | extension-pragma |
6789 |
extension-pragma = token [ "=" ( token | quoted-string ) ] |
6790 |
|
6791 |
When the no-cache directive is present in a request message, an |
6792 |
application SHOULD forward the request toward the origin server even if |
6793 |
it has a cached copy of what is being requested. This pragma directive |
6794 |
has the same semantics as the no-cache cache-directive (see section |
6795 |
14.9) and is defined here for backwards compatibility with HTTP/1.0. |
6796 |
Clients SHOULD include both header fields when a no-cache request is |
6797 |
sent to a server not known to be HTTP/1.1 compliant. |
6798 |
|
6799 |
Pragma directives MUST be passed through by a proxy or gateway |
6800 |
application, regardless of their significance to that application, since |
6801 |
the directives may be applicable to all recipients along the |
6802 |
request/response chain. It is not possible to specify a pragma for a |
6803 |
specific recipient; however, any pragma directive not relevant to a |
6804 |
recipient SHOULD be ignored by that recipient. |
6805 |
|
6806 |
HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1 |
6807 |
caches SHOULD treat "Pragma: no-cache" as if the client had sent "Cache- |
6808 |
Control: no-cache". No new Pragma directives will be defined in HTTP. |
6809 |
|
6810 |
|
6811 |
14.33 Proxy-Authenticate |
6812 |
|
6813 |
The Proxy-Authenticate response-header field MUST be included as part of |
6814 |
a 407 (Proxy Authentication Required) response. The field value consists |
6815 |
of a challenge that indicates the authentication scheme and parameters |
6816 |
applicable to the proxy for this Request-URI. |
6817 |
|
6818 |
Proxy-Authentication = "Proxy-Authentication" ":" challenge |
6819 |
|
6820 |
The HTTP access authentication process is described in section 11. |
6821 |
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |
6822 |
only to the current connection and SHOULD NOT be passed on to downstream |
6823 |
clients. However, an intermediate proxy may need to obtain its own |
6824 |
credentials by requesting them from the downstream client, which in some |
6825 |
circumstances will appear as if the proxy is forwarding the Proxy- |
6826 |
Authenticate header field. |
6827 |
|
6828 |
|
6829 |
14.34 Proxy-Authorization |
6830 |
|
6831 |
The Proxy-Authorization request-header field allows the client to |
6832 |
identify itself (or its user) to a proxy which requires authentication. |
6833 |
The Proxy-Authorization field value consists of credentials containing |
6834 |
|
6835 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 115] |
6836 |
|
6837 |
|
6838 |
|
6839 |
|
6840 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6841 |
|
6842 |
|
6843 |
the authentication information of the user agent for the proxy and/or |
6844 |
realm of the resource being requested. |
6845 |
|
6846 |
Proxy-Authorization = "Proxy-Authorization" ":" credentials |
6847 |
|
6848 |
The HTTP access authentication process is described in section 11. |
6849 |
Unlike Authorization, the Proxy-Authorization header field applies only |
6850 |
to the next outbound proxy that demanded authentication using the Proxy- |
6851 |
Authenticate field. When multiple proxies are used in a chain, the |
6852 |
Proxy-Authorization header field is consumed by the first outbound proxy |
6853 |
that was expecting to receive credentials. A proxy MAY relay the |
6854 |
credentials from the client request to the next proxy if that is the |
6855 |
mechanism by which the proxies cooperatively authenticate a given |
6856 |
request. |
6857 |
|
6858 |
|
6859 |
14.35 Public |
6860 |
|
6861 |
The Public response-header field lists the set of methods supported by |
6862 |
the server. The purpose of this field is strictly to inform the |
6863 |
recipient of the capabilities of the server regarding unusual methods. |
6864 |
The methods listed may or may not be applicable to the Request-URI; the |
6865 |
Allow header field (section 14.7) MAY be used to indicate methods |
6866 |
allowed for a particular URI. |
6867 |
|
6868 |
Public = "Public" ":" 1#method |
6869 |
|
6870 |
Example of use: |
6871 |
|
6872 |
Public: OPTIONS, MGET, MHEAD, GET, HEAD |
6873 |
|
6874 |
This header field applies only to the server directly connected to the |
6875 |
client (i.e., the nearest neighbor in a chain of connections). If the |
6876 |
response passes through a proxy, the proxy MUST either remove the Public |
6877 |
header field or replace it with one applicable to its own capabilities. |
6878 |
|
6879 |
|
6880 |
14.36 Range |
6881 |
|
6882 |
|
6883 |
14.36.1 Byte Ranges |
6884 |
|
6885 |
Since all HTTP entities are represented in HTTP messages as sequences of |
6886 |
bytes, the concept of a byte range is meaningful for any HTTP entity. |
6887 |
(However, not all clients and servers need to support byte-range |
6888 |
operations.) |
6889 |
|
6890 |
Byte range specifications in HTTP apply to the sequence of bytes in the |
6891 |
entity-body (not necessarily the same as the message-body). |
6892 |
|
6893 |
|
6894 |
|
6895 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 116] |
6896 |
|
6897 |
|
6898 |
|
6899 |
|
6900 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6901 |
|
6902 |
|
6903 |
A byte range operation may specify a single range of bytes, or a set of |
6904 |
ranges within a single entity. |
6905 |
|
6906 |
ranges-specifier = byte-ranges-specifier |
6907 |
|
6908 |
byte-ranges-specifier = bytes-unit "=" byte-range-set |
6909 |
|
6910 |
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) |
6911 |
|
6912 |
byte-range-spec = first-byte-pos "-" [last-byte-pos] |
6913 |
|
6914 |
first-byte-pos = 1*DIGIT |
6915 |
|
6916 |
last-byte-pos = 1*DIGIT |
6917 |
|
6918 |
The first-byte-pos value in a byte-range-spec gives the byte-offset of |
6919 |
the first byte in a range. The last-byte-pos value gives the byte-offset |
6920 |
of the last byte in the range; that is, the byte positions specified are |
6921 |
inclusive. Byte offsets start at zero. |
6922 |
|
6923 |
If the last-byte-pos value is present, it must be greater than or equal |
6924 |
to the first-byte-pos in that byte-range-spec, or the byte-range-spec is |
6925 |
invalid. The recipient of an invalid byte-range-spec must ignore it. |
6926 |
|
6927 |
If the last-byte-pos value is absent, it is assumed to be equal to the |
6928 |
current length of the entity-body in bytes. |
6929 |
|
6930 |
If the last-byte-pos value is larger than the current length of the |
6931 |
entity-body, it is assumed to be equal to the current length of the |
6932 |
entity-body. This allows, for example, a client to attempt to limit the |
6933 |
number of bytes retrieved without knowing the size of the entity. |
6934 |
|
6935 |
suffix-byte-range-spec = "-" suffix-length |
6936 |
|
6937 |
suffix-length = 1*DIGIT |
6938 |
|
6939 |
A suffix-byte-range-spec is used to specify the suffix of the entity- |
6940 |
body, of a length given by the suffix-length value. (That is, this form |
6941 |
specifies the last N bytes of an entity-body.) If the entity is shorter |
6942 |
than the specified suffix-length, the entire entity-body is used. |
6943 |
|
6944 |
Examples of byte-ranges-specifier values (assuming an entity-body of |
6945 |
length 10000): |
6946 |
|
6947 |
. The first 500 bytes (byte offsets 0-499, inclusive): |
6948 |
bytes=0-499 |
6949 |
|
6950 |
. The second 500 bytes (byte offsets 500-999, inclusive): |
6951 |
bytes=500-999 |
6952 |
|
6953 |
. The final 500 bytes (byte offsets 9500-9999, inclusive): |
6954 |
|
6955 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 117] |
6956 |
|
6957 |
|
6958 |
|
6959 |
|
6960 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
6961 |
|
6962 |
|
6963 |
bytes=-500 |
6964 |
|
6965 |
. Or |
6966 |
bytes=9500- |
6967 |
|
6968 |
. The first and last bytes only (bytes 0 and 9999): |
6969 |
bytes=0-0,-1 |
6970 |
|
6971 |
. Several legal but not canonical specifications of the second 500 |
6972 |
bytes (byte offsets 500-999, inclusive): |
6973 |
bytes=500-600,601-999 |
6974 |
|
6975 |
bytes=500-700,601-999 |
6976 |
|
6977 |
|
6978 |
14.36.2 Range Retrieval Requests |
6979 |
|
6980 |
HTTP retrieval requests using conditional or unconditional GET methods |
6981 |
may request one or more sub-ranges of the entity, instead of the entire |
6982 |
entity, using the Range request header, which applies to the entity |
6983 |
returned as the result of the request: |
6984 |
|
6985 |
Range = "Range" ":" ranges-specifier |
6986 |
|
6987 |
A server MAY ignore the Range header. However, HTTP/1.1 origin servers |
6988 |
and intermediate caches SHOULD support byte ranges when possible, since |
6989 |
Range supports efficient recovery from partially failed transfers, and |
6990 |
supports efficient partial retrieval of large entities. |
6991 |
|
6992 |
If the server supports the Range header and the specified range or |
6993 |
ranges are appropriate for the entity: |
6994 |
|
6995 |
. The presence of a Range header in an unconditional GET modifies |
6996 |
what is returned if the GET is otherwise successful. In other |
6997 |
words, the response carries a status code of 206 (Partial Content) |
6998 |
instead of 200 (OK). |
6999 |
. The presence of a Range header in a conditional GET (a request |
7000 |
using one or both of If-Modified-Since and If-None-Match, or one or |
7001 |
both of If-Unmodified-Since and If-Match) modifies what is returned |
7002 |
if the GET is otherwise successful and the condition is true. It |
7003 |
does not affect the 304 (Not Modified) response returned if the |
7004 |
conditional is false. |
7005 |
In some cases, it may be more appropriate to use the If-Range header |
7006 |
(see section 14.27) in addition to the Range header. |
7007 |
|
7008 |
If a proxy that supports byte ranges receives a Range request, forwards |
7009 |
the request to an inbound server, and receives an entire entity in |
7010 |
reply, it SHOULD only return the requested range to its client. It |
7011 |
SHOULD store the entire received response in its cache, if that is |
7012 |
consistent with its cache allocation policies. |
7013 |
|
7014 |
|
7015 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 118] |
7016 |
|
7017 |
|
7018 |
|
7019 |
|
7020 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7021 |
|
7022 |
|
7023 |
14.37 Referer |
7024 |
|
7025 |
The Referer[sic] request-header field allows the client to specify, for |
7026 |
the server's benefit, the address (URI) of the resource from which the |
7027 |
Request-URI was obtained (the "referrer", although the header field is |
7028 |
misspelled.) The Referer request-header allows a server to generate |
7029 |
lists of back-links to resources for interest, logging, optimized |
7030 |
caching, etc. It also allows obsolete or mistyped links to be traced for |
7031 |
maintenance. The Referer field MUST NOT be sent if the Request-URI was |
7032 |
obtained from a source that does not have its own URI, such as input |
7033 |
from the user keyboard. |
7034 |
|
7035 |
Referer = "Referer" ":" ( absoluteURI | relativeURI ) |
7036 |
|
7037 |
Example: |
7038 |
|
7039 |
Referer: http://www.w3.org/hypertext/DataSources/Overview.html |
7040 |
|
7041 |
If the field value is a partial URI, it SHOULD be interpreted relative |
7042 |
to the Request-URI. The URI MUST NOT include a fragment. |
7043 |
|
7044 |
Note: Because the source of a link may be private information or |
7045 |
may reveal an otherwise private information source, it is strongly |
7046 |
recommended that the user be able to select whether or not the |
7047 |
Referer field is sent. For example, a browser client could have a |
7048 |
toggle switch for browsing openly/anonymously, which would |
7049 |
respectively enable/disable the sending of Referer and From |
7050 |
information. |
7051 |
|
7052 |
|
7053 |
14.38 Retry-After |
7054 |
|
7055 |
The Retry-After response-header field can be used with a 503 (Service |
7056 |
Unavailable) response to indicate how long the service is expected to be |
7057 |
unavailable to the requesting client. The value of this field can be |
7058 |
either an HTTP-date or an integer number of seconds (in decimal) after |
7059 |
the time of the response. |
7060 |
|
7061 |
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |
7062 |
|
7063 |
Two examples of its use are |
7064 |
|
7065 |
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
7066 |
Retry-After: 120 |
7067 |
|
7068 |
In the latter example, the delay is 2 minutes. |
7069 |
|
7070 |
|
7071 |
|
7072 |
|
7073 |
|
7074 |
|
7075 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 119] |
7076 |
|
7077 |
|
7078 |
|
7079 |
|
7080 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7081 |
|
7082 |
|
7083 |
14.39 Server |
7084 |
|
7085 |
The Server response-header field contains information about the software |
7086 |
used by the origin server to handle the request. The field can contain |
7087 |
multiple product tokens (section 3.8) and comments identifying the |
7088 |
server and any significant subproducts. The product tokens are listed in |
7089 |
order of their significance for identifying the application. |
7090 |
|
7091 |
Server = "Server" ":" 1*( product | comment ) |
7092 |
|
7093 |
Example: |
7094 |
|
7095 |
Server: CERN/3.0 libwww/2.17 |
7096 |
|
7097 |
If the response is being forwarded through a proxy, the proxy |
7098 |
application MUST NOT modify the Server response-header. Instead, it |
7099 |
SHOULD include a Via field (as described in section 14.44). |
7100 |
|
7101 |
Note: Revealing the specific software version of the server may |
7102 |
allow the server machine to become more vulnerable to attacks |
7103 |
against software that is known to contain security holes. Server |
7104 |
implementers are encouraged to make this field a configurable |
7105 |
option. |
7106 |
|
7107 |
|
7108 |
14.40 Transfer Encoding |
7109 |
|
7110 |
The Transfer-Encoding general-header field indicates what (if any) type |
7111 |
of transformation has been applied to the message body in order to |
7112 |
safely transfer it between the sender and the recipient. This differs |
7113 |
from the Content-Encoding in that the transfer coding is a property of |
7114 |
the message, not of the entity. |
7115 |
|
7116 |
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer- |
7117 |
coding |
7118 |
|
7119 |
Transfer codings are defined in section 3.6. An example is: |
7120 |
|
7121 |
Transfer-Encoding: chunked |
7122 |
|
7123 |
Many older HTTP/1.0 applications do not understand the Transfer-Encoding |
7124 |
header. |
7125 |
|
7126 |
|
7127 |
14.41 Upgrade |
7128 |
|
7129 |
The Upgrade general-header allows the client to specify what additional |
7130 |
communication protocols it supports and would like to use if the server |
7131 |
finds it appropriate to switch protocols. The server MUST use the |
7132 |
Upgrade header field within a 101 (Switching Protocols) response to |
7133 |
indicate which protocol(s) are being switched. |
7134 |
|
7135 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 120] |
7136 |
|
7137 |
|
7138 |
|
7139 |
|
7140 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7141 |
|
7142 |
|
7143 |
Upgrade = "Upgrade" ":" 1#product |
7144 |
|
7145 |
For example, |
7146 |
|
7147 |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
7148 |
|
7149 |
The Upgrade header field is intended to provide a simple mechanism for |
7150 |
transition from HTTP/1.1 to some other, incompatible protocol. It does |
7151 |
so by allowing the client to advertise its desire to use another |
7152 |
protocol, such as a later version of HTTP with a higher major version |
7153 |
number, even though the current request has been made using HTTP/1.1. |
7154 |
This eases the difficult transition between incompatible protocols by |
7155 |
allowing the client to initiate a request in the more commonly supported |
7156 |
protocol while indicating to the server that it would like to use a |
7157 |
"better" protocol if available (where "better" is determined by the |
7158 |
server, possibly according to the nature of the method and/or resource |
7159 |
being requested). |
7160 |
|
7161 |
The Upgrade header field only applies to switching application-layer |
7162 |
protocols upon the existing transport-layer connection. Upgrade cannot |
7163 |
be used to insist on a protocol change; its acceptance and use by the |
7164 |
server is optional. The capabilities and nature of the application-layer |
7165 |
communication after the protocol change is entirely dependent upon the |
7166 |
new protocol chosen, although the first action after changing the |
7167 |
protocol MUST be a response to the initial HTTP request containing the |
7168 |
Upgrade header field. |
7169 |
|
7170 |
The Upgrade header field only applies to the immediate connection. |
7171 |
Therefore, the upgrade keyword MUST be supplied within a Connection |
7172 |
header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 |
7173 |
message. |
7174 |
|
7175 |
The Upgrade header field cannot be used to indicate a switch to a |
7176 |
protocol on a different connection. For that purpose, it is more |
7177 |
appropriate to use a 301, 302, 303, or 305 redirection response. |
7178 |
|
7179 |
This specification only defines the protocol name "HTTP" for use by the |
7180 |
family of Hypertext Transfer Protocols, as defined by the HTTP version |
7181 |
rules of section 3.1 and future updates to this specification. Any token |
7182 |
can be used as a protocol name; however, it will only be useful if both |
7183 |
the client and server associate the name with the same protocol. |
7184 |
|
7185 |
|
7186 |
14.42 User-Agent |
7187 |
|
7188 |
The User-Agent request-header field contains information about the user |
7189 |
agent originating the request. This is for statistical purposes, the |
7190 |
tracing of protocol violations, and automated recognition of user agents |
7191 |
for the sake of tailoring responses to avoid particular user agent |
7192 |
limitations. User agents SHOULD include this field with requests. The |
7193 |
field can contain multiple product tokens (section 3.8) and comments |
7194 |
|
7195 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 121] |
7196 |
|
7197 |
|
7198 |
|
7199 |
|
7200 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7201 |
|
7202 |
|
7203 |
identifying the agent and any subproducts which form a significant part |
7204 |
of the user agent. By convention, the product tokens are listed in order |
7205 |
of their significance for identifying the application. |
7206 |
|
7207 |
User-Agent = "User-Agent" ":" 1*( product | comment ) |
7208 |
|
7209 |
Example: |
7210 |
|
7211 |
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
7212 |
|
7213 |
|
7214 |
14.43 Vary |
7215 |
|
7216 |
The Vary response-header field is used by a server to signal that the |
7217 |
response entity was selected from the available representations of the |
7218 |
response using server-driven negotiation (section 12). The Vary field |
7219 |
value indicates either that the given set of header fields encompass the |
7220 |
dimensions over which the representation might vary, or that the |
7221 |
dimensions of variance are unspecified ("*") and thus may vary over any |
7222 |
aspect of future requests. |
7223 |
|
7224 |
Vary = "Vary" ":" ( "*" | 1#field-name ) |
7225 |
|
7226 |
An HTTP/1.1 server MUST include an appropriate Vary header field with |
7227 |
any cachable response that is subject to server-driven negotiation. |
7228 |
Doing so allows a cache to properly interpret future requests on that |
7229 |
resource and informs the user agent about the presence of negotiation on |
7230 |
that resource. A server SHOULD include an appropriate Vary header field |
7231 |
with a non-cachable response that is subject to server-driven |
7232 |
negotiation, since this might provide the user-agent with useful |
7233 |
information about the dimensions over which the response might vary. |
7234 |
|
7235 |
The header fields named by the Vary field value is known as the |
7236 |
"selecting" request-headers. |
7237 |
|
7238 |
When the cache receives a subsequent request whose Request-URI specifies |
7239 |
one or more cache entries including a Vary header, the cache MUST NOT |
7240 |
use such a cache entry to construct a response to the new request unless |
7241 |
all of the headers named in the cached Vary header are present in the |
7242 |
new request, and all of the stored selecting request-headers from the |
7243 |
previous request match the corresponding headers in the new request. |
7244 |
|
7245 |
The selecting request-headers from two requests are defined to match if |
7246 |
and only if the selecting request-headers in the first request can be |
7247 |
transformed to the selecting request-headers in the second request by |
7248 |
adding or removing linear whitespace (LWS) at places where this is |
7249 |
allowed by the corresponding BNF, and/or combining multiple message- |
7250 |
header fields with the same field name following the rules about message |
7251 |
headers in section 4.2. |
7252 |
|
7253 |
|
7254 |
|
7255 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 122] |
7256 |
|
7257 |
|
7258 |
|
7259 |
|
7260 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7261 |
|
7262 |
|
7263 |
A Vary field value of "*" signals that unspecified parameters, possibly |
7264 |
other than the contents of request-header fields (e.g., the network |
7265 |
address of the client), play a role in the selection of the response |
7266 |
representation. Subsequent requests on that resource can only be |
7267 |
properly interpreted by the origin server, and thus a cache MUST forward |
7268 |
a (possibly conditional) request even when it has a fresh response |
7269 |
cached for the resource. See section 13.5 for use of the Vary header by |
7270 |
caches. |
7271 |
|
7272 |
A Vary field value consisting of a list of field-names signals that the |
7273 |
representation selected for the response is based on a selection |
7274 |
algorithm which considers ONLY the listed request-header field values in |
7275 |
selecting the most appropriate representation. A cache MAY assume that |
7276 |
the same selection will be made for future requests with the same values |
7277 |
for the listed field names, for the duration of time in which the |
7278 |
response is fresh. |
7279 |
|
7280 |
The field-names given are not limited to the set of standard request- |
7281 |
header fields defined by this specification. Field names are case- |
7282 |
insensitive. |
7283 |
|
7284 |
|
7285 |
14.44 Via |
7286 |
|
7287 |
The Via general-header field MUST be used by gateways and proxies to |
7288 |
indicate the intermediate protocols and recipients between the user |
7289 |
agent and the server on requests, and between the origin server and the |
7290 |
client on responses. It is analogous to the "Received" field of RFC 822 |
7291 |
and is intended to be used for tracking message forwards, avoiding |
7292 |
request loops, and identifying the protocol capabilities of all senders |
7293 |
along the request/response chain. |
7294 |
|
7295 |
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) |
7296 |
|
7297 |
received-protocol = [ protocol-name "/" ] protocol-version |
7298 |
protocol-name = token |
7299 |
protocol-version = token |
7300 |
received-by = ( host [ ":" port ] ) | pseudonym |
7301 |
pseudonym = token |
7302 |
|
7303 |
The received-protocol indicates the protocol version of the message |
7304 |
received by the server or client along each segment of the |
7305 |
request/response chain. The received-protocol version is appended to the |
7306 |
Via field value when the message is forwarded so that information about |
7307 |
the protocol capabilities of upstream applications remains visible to |
7308 |
all recipients. |
7309 |
|
7310 |
The protocol-name is optional if and only if it would be "HTTP". The |
7311 |
received-by field is normally the host and optional port number of a |
7312 |
recipient server or client that subsequently forwarded the message. |
7313 |
However, if the real host is considered to be sensitive information, it |
7314 |
|
7315 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 123] |
7316 |
|
7317 |
|
7318 |
|
7319 |
|
7320 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7321 |
|
7322 |
|
7323 |
MAY be replaced by a pseudonym. If the port is not given, it MAY be |
7324 |
assumed to be the default port of the received-protocol. |
7325 |
|
7326 |
Multiple Via field values represent each proxy or gateway that has |
7327 |
forwarded the message. Each recipient MUST append its information such |
7328 |
that the end result is ordered according to the sequence of forwarding |
7329 |
applications. |
7330 |
|
7331 |
Comments MAY be used in the Via header field to identify the software of |
7332 |
the recipient proxy or gateway, analogous to the User-Agent and Server |
7333 |
header fields. However, all comments in the Via field are optional and |
7334 |
MAY be removed by any recipient prior to forwarding the message. |
7335 |
|
7336 |
For example, a request message could be sent from an HTTP/1.0 user agent |
7337 |
to an internal proxy code-named "fred", which uses HTTP/1.1 to forward |
7338 |
the request to a public proxy at nowhere.com, which completes the |
7339 |
request by forwarding it to the origin server at www.ics.uci.edu. The |
7340 |
request received by www.ics.uci.edu would then have the following Via |
7341 |
header field: |
7342 |
|
7343 |
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
7344 |
|
7345 |
Proxies and gateways used as a portal through a network firewall SHOULD |
7346 |
NOT, by default, forward the names and ports of hosts within the |
7347 |
firewall region. This information SHOULD only be propagated if |
7348 |
explicitly enabled. If not enabled, the received-by host of any host |
7349 |
behind the firewall SHOULD be replaced by an appropriate pseudonym for |
7350 |
that host. |
7351 |
|
7352 |
For organizations that have strong privacy requirements for hiding |
7353 |
internal structures, a proxy MAY combine an ordered subsequence of Via |
7354 |
header field entries with identical received-protocol values into a |
7355 |
single such entry. For example, |
7356 |
|
7357 |
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
7358 |
|
7359 |
could be collapsed to |
7360 |
|
7361 |
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
7362 |
|
7363 |
Applications SHOULD NOT combine multiple entries unless they are all |
7364 |
under the same organizational control and the hosts have already been |
7365 |
replaced by pseudonyms. Applications MUST NOT combine entries which have |
7366 |
different received-protocol values. |
7367 |
|
7368 |
|
7369 |
14.45 Warning |
7370 |
|
7371 |
Warning headers are sent with responses using: |
7372 |
|
7373 |
|
7374 |
|
7375 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 124] |
7376 |
|
7377 |
|
7378 |
|
7379 |
|
7380 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7381 |
|
7382 |
|
7383 |
Warning = "Warning" ":" warn-code SP warn-agent SP warn-text |
7384 |
warn-code = 2DIGIT |
7385 |
warn-agent = ( host [ ":" port ] ) | pseudonym |
7386 |
; the name or pseudonym of the server adding |
7387 |
; the Warning header, for use in debugging |
7388 |
warn-text = quoted-string |
7389 |
|
7390 |
A response may carry more than one Warning header. |
7391 |
|
7392 |
The warn-text should be in a natural language and character set that is |
7393 |
most likely to be intelligible to the human user receiving the response. |
7394 |
This decision may be based on any available knowledge, such as the |
7395 |
location of the cache or user, the Accept-Language field in a request, |
7396 |
the Content-Language field in a response, etc. The default language is |
7397 |
English and the default character set is ISO-8599-1. |
7398 |
|
7399 |
If a character set other than ISO-8599-1 is used, it MUST be encoded in |
7400 |
the warn-text using the method described in RFC 1522 [14]. |
7401 |
|
7402 |
Any server or cache may add Warning headers to a response. New Warning |
7403 |
headers should be added after any existing Warning headers. A cache MUST |
7404 |
NOT delete any Warning header that it received with a response. However, |
7405 |
if a cache successfully validates a cache entry, it SHOULD remove any |
7406 |
Warning headers previously attached to that entry. It MUST then add any |
7407 |
Warning headers received in the validating response. In other words, |
7408 |
Warning headers are those that would be attached to the most recent |
7409 |
relevant response. |
7410 |
|
7411 |
When multiple Warning headers are attached to a response, the user agent |
7412 |
SHOULD display as many of them as possible, in the order that they |
7413 |
appear in the response. If it is not possible to display all of the |
7414 |
warnings, the user agent should follow these heuristics: |
7415 |
|
7416 |
. Warnings that appear early in the response take priority over those |
7417 |
appearing later in the response. |
7418 |
. Warnings in the user's preferred character set take priority over |
7419 |
warnings in other character sets but with identical warn-codes and |
7420 |
warn-agents. |
7421 |
Systems that generate multiple Warning headers should order them with |
7422 |
this user-agent behavior in mind. |
7423 |
|
7424 |
This is a list of the currently-defined warn-codes, each with a |
7425 |
recommended warn-text in English, and a description of its meaning. |
7426 |
|
7427 |
10 Response is stale |
7428 |
MUST be included whenever the returned response is stale. A cache may |
7429 |
add this warning to any response, but may never remove it until the |
7430 |
response is known to be fresh. |
7431 |
|
7432 |
11 Revalidation failed |
7433 |
MUST be included if a cache returns a stale response because an |
7434 |
|
7435 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 125] |
7436 |
|
7437 |
|
7438 |
|
7439 |
|
7440 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7441 |
|
7442 |
|
7443 |
attempt to revalidate the response failed, due to an inability to |
7444 |
reach the server. A cache may add this warning to any response, but |
7445 |
may never remove it until the response is successfully revalidated. |
7446 |
|
7447 |
12 Disconnected operation |
7448 |
SHOULD be included if the cache is intentionally disconnected from |
7449 |
the rest of the network for a period of time. |
7450 |
|
7451 |
13 Heuristic expiration |
7452 |
MUST be included if the cache heuristically chose a freshness |
7453 |
lifetime greater than 24 hours and the response's age is greater than |
7454 |
24 hours. |
7455 |
|
7456 |
99 Miscellaneous warning |
7457 |
The warning text may include arbitrary information to be presented to |
7458 |
a human user, or logged. A system receiving this warning MUST NOT |
7459 |
take any automated action. |
7460 |
|
7461 |
|
7462 |
14.46 WWW-Authenticate |
7463 |
|
7464 |
The WWW-Authenticate response-header field MUST be included in 401 |
7465 |
(Unauthorized) response messages. The field value consists of at least |
7466 |
one challenge that indicates the authentication scheme(s) and parameters |
7467 |
applicable to the Request-URI. |
7468 |
|
7469 |
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge |
7470 |
|
7471 |
The HTTP access authentication process is described in section 11. User |
7472 |
agents MUST take special care in parsing the WWW-Authenticate field |
7473 |
value if it contains more than one challenge, or if more than one WWW- |
7474 |
Authenticate header field is provided, since the contents of a challenge |
7475 |
may itself contain a comma-separated list of authentication parameters. |
7476 |
|
7477 |
|
7478 |
15 Security Considerations |
7479 |
|
7480 |
This section is meant to inform application developers, information |
7481 |
providers, and users of the security limitations in HTTP/1.1 as |
7482 |
described by this document. The discussion does not include definitive |
7483 |
solutions to the problems revealed, though it does make some suggestions |
7484 |
for reducing security risks. |
7485 |
|
7486 |
|
7487 |
15.1 Authentication of Clients |
7488 |
|
7489 |
The Basic authentication scheme is not a secure method of user |
7490 |
authentication, nor does it in any way protect the entity, which is |
7491 |
transmitted in clear text across the physical network used as the |
7492 |
carrier. HTTP does not prevent additional authentication schemes and |
7493 |
encryption mechanisms from being employed to increase security or the |
7494 |
|
7495 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 126] |
7496 |
|
7497 |
|
7498 |
|
7499 |
|
7500 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7501 |
|
7502 |
|
7503 |
addition of enhancements (such as schemes to use one-time passwords) to |
7504 |
Basic authentication. |
7505 |
|
7506 |
The most serious flaw in Basic authentication is that it results in the |
7507 |
essentially clear text transmission of the user's password over the |
7508 |
physical network. It is this problem which Digest Authentication |
7509 |
attempts to address. |
7510 |
|
7511 |
Because Basic authentication involves the clear text transmission of |
7512 |
passwords it SHOULD never be used (without enhancements) to protect |
7513 |
sensitive or valuable information. |
7514 |
|
7515 |
A common use of Basic authentication is for identification purposes -- |
7516 |
requiring the user to provide a user name and password as a means of |
7517 |
identification, for example, for purposes of gathering accurate usage |
7518 |
statistics on a server. When used in this way it is tempting to think |
7519 |
that there is no danger in its use if illicit access to the protected |
7520 |
documents is not a major concern. This is only correct if the server |
7521 |
issues both user name and password to the users and in particular does |
7522 |
not allow the user to choose his or her own password. The danger arises |
7523 |
because naive users frequently reuse a single password to avoid the task |
7524 |
of maintaining multiple passwords. |
7525 |
|
7526 |
If a server permits users to select their own passwords, then the threat |
7527 |
is not only illicit access to documents on the server but also illicit |
7528 |
access to the accounts of all users who have chosen to use their account |
7529 |
password. If users are allowed to choose their own password that also |
7530 |
means the server must maintain files containing the (presumably |
7531 |
encrypted) passwords. Many of these may be the account passwords of |
7532 |
users perhaps at distant sites. The owner or administrator of such a |
7533 |
system could conceivably incur liability if this information is not |
7534 |
maintained in a secure fashion. |
7535 |
|
7536 |
Basic Authentication is also vulnerable to spoofing by counterfeit |
7537 |
servers. If a user can be led to believe that he is connecting to a host |
7538 |
containing information protected by basic authentication when in fact he |
7539 |
is connecting to a hostile server or gateway then the attacker can |
7540 |
request a password, store it for later use, and feign an error. This |
7541 |
type of attack is not possible with Digest Authentication [32]. Server |
7542 |
implementers SHOULD guard against the possibility of this sort of |
7543 |
counterfeiting by gateways or CGI scripts. In particular it is very |
7544 |
dangerous for a server to simply turn over a connection to a gateway |
7545 |
since that gateway can then use the persistent connection mechanism to |
7546 |
engage in multiple transactions with the client while impersonating the |
7547 |
original server in a way that is not detectable by the client. |
7548 |
|
7549 |
|
7550 |
15.2 Offering a Choice of Authentication Schemes |
7551 |
|
7552 |
An HTTP/1.1 server may return multiple challenges with a 401 |
7553 |
(Authenticate) response, and each challenge may use a different scheme. |
7554 |
|
7555 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 127] |
7556 |
|
7557 |
|
7558 |
|
7559 |
|
7560 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7561 |
|
7562 |
|
7563 |
The order of the challenges returned to the user agent is in the order |
7564 |
that the server would prefer they be chosen. The server should order its |
7565 |
challenges with the "most secure" authentication scheme first. A user |
7566 |
agent should choose as the challenge to be made to the user the first |
7567 |
one that the user agent understands. |
7568 |
|
7569 |
When the server offers choices of authentication schemes using the WWW- |
7570 |
Authenticate header, the "security" of the authentication is only as |
7571 |
good as the security of the weakest of the authentication schemes. A |
7572 |
malicious user could capture the set of challenges and try to |
7573 |
authenticate him/herself using the weakest of the authentication |
7574 |
schemes. Thus, the ordering serves more to protect the user's |
7575 |
credentials than the server's information. |
7576 |
|
7577 |
A possible man-in-the-middle (MITM) attack would be to add a weak |
7578 |
authentication scheme to the set of choices, hoping that the client will |
7579 |
use one that exposes the user's credentials (e.g. password). For this |
7580 |
reason, the client should always use the strongest scheme that it |
7581 |
understands from the choices accepted. |
7582 |
|
7583 |
An even better MITM attack would be to remove all offered choices, and |
7584 |
to insert a challenge that requests Basic authentication. For this |
7585 |
reason, user agents that are concerned about this kind of attack could |
7586 |
remember the strongest authentication scheme ever requested by a server |
7587 |
and produce a warning message that requires user confirmation before |
7588 |
using a weaker one. A particularly insidious way to mount such a MITM |
7589 |
attack would be to offer a "free" proxy caching service to gullible |
7590 |
users. |
7591 |
|
7592 |
|
7593 |
15.3 Abuse of Server Log Information |
7594 |
|
7595 |
A server is in the position to save personal data about a user's |
7596 |
requests which may identify their reading patterns or subjects of |
7597 |
interest. This information is clearly confidential in nature and its |
7598 |
handling may be constrained by law in certain countries. People using |
7599 |
the HTTP protocol to provide data are responsible for ensuring that such |
7600 |
material is not distributed without the permission of any individuals |
7601 |
that are identifiable by the published results. |
7602 |
|
7603 |
|
7604 |
15.4 Transfer of Sensitive Information |
7605 |
|
7606 |
Like any generic data transfer protocol, HTTP cannot regulate the |
7607 |
content of the data that is transferred, nor is there any a priori |
7608 |
method of determining the sensitivity of any particular piece of |
7609 |
information within the context of any given request. Therefore, |
7610 |
applications SHOULD supply as much control over this information as |
7611 |
possible to the provider of that information. Four header fields are |
7612 |
worth special mention in this context: Server, Via, Referer and From. |
7613 |
|
7614 |
|
7615 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 128] |
7616 |
|
7617 |
|
7618 |
|
7619 |
|
7620 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7621 |
|
7622 |
|
7623 |
Revealing the specific software version of the server may allow the |
7624 |
server machine to become more vulnerable to attacks against software |
7625 |
that is known to contain security holes. Implementers SHOULD make the |
7626 |
Server header field a configurable option. |
7627 |
|
7628 |
Proxies which serve as a portal through a network firewall SHOULD take |
7629 |
special precautions regarding the transfer of header information that |
7630 |
identifies the hosts behind the firewall. In particular, they SHOULD |
7631 |
remove, or replace with sanitized versions, any Via fields generated |
7632 |
behind the firewall. |
7633 |
|
7634 |
The Referer field allows reading patterns to be studied and reverse |
7635 |
links drawn. Although it can be very useful, its power can be abused if |
7636 |
user details are not separated from the information contained in the |
7637 |
Referer. Even when the personal information has been removed, the |
7638 |
Referer field may indicate a private document's URI whose publication |
7639 |
would be inappropriate. |
7640 |
|
7641 |
The information sent in the From field might conflict with the user's |
7642 |
privacy interests or their site's security policy, and hence it SHOULD |
7643 |
NOT be transmitted without the user being able to disable, enable, and |
7644 |
modify the contents of the field. The user MUST be able to set the |
7645 |
contents of this field within a user preference or application defaults |
7646 |
configuration. |
7647 |
|
7648 |
We suggest, though do not require, that a convenient toggle interface be |
7649 |
provided for the user to enable or disable the sending of From and |
7650 |
Referer information. |
7651 |
|
7652 |
|
7653 |
15.5 Attacks Based On File and Path Names |
7654 |
|
7655 |
Implementations of HTTP origin servers SHOULD be careful to restrict the |
7656 |
documents returned by HTTP requests to be only those that were intended |
7657 |
by the server administrators. If an HTTP server translates HTTP URIs |
7658 |
directly into file system calls, the server MUST take special care not |
7659 |
to serve files that were not intended to be delivered to HTTP clients. |
7660 |
For example, UNIX, Microsoft Windows, and other operating systems use |
7661 |
".." as a path component to indicate a directory level above the current |
7662 |
one. On such a system, an HTTP server MUST disallow any such construct |
7663 |
in the Request-URI if it would otherwise allow access to a resource |
7664 |
outside those intended to be accessible via the HTTP server. Similarly, |
7665 |
files intended for reference only internally to the server (such as |
7666 |
access control files, configuration files, and script code) MUST be |
7667 |
protected from inappropriate retrieval, since they might contain |
7668 |
sensitive information. Experience has shown that minor bugs in such HTTP |
7669 |
server implementations have turned into security risks. |
7670 |
|
7671 |
|
7672 |
|
7673 |
|
7674 |
|
7675 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 129] |
7676 |
|
7677 |
|
7678 |
|
7679 |
|
7680 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7681 |
|
7682 |
|
7683 |
15.6 Personal Information |
7684 |
|
7685 |
HTTP clients are often privy to large amounts of personal information |
7686 |
(e.g. the user's name, location, mail address, passwords, encryption |
7687 |
keys, etc.), and SHOULD be very careful to prevent unintentional leakage |
7688 |
of this information via the HTTP protocol to other sources. We very |
7689 |
strongly recommend that a convenient interface be provided for the user |
7690 |
to control dissemination of such information, and that designers and |
7691 |
implementers be particularly careful in this area. History shows that |
7692 |
errors in this area are often both serious security and/or privacy |
7693 |
problems, and often generate highly adverse publicity for the |
7694 |
implementer's company. |
7695 |
|
7696 |
|
7697 |
15.7 Privacy Issues Connected to Accept Headers |
7698 |
|
7699 |
Accept request-headers can reveal information about the user to all |
7700 |
servers which are accessed. The Accept-Language header in particular can |
7701 |
reveal information the user would consider to be of a private nature, |
7702 |
because the understanding of particular languages is often strongly |
7703 |
correlated to the membership of a particular ethnic group. User agents |
7704 |
which offer the option to configure the contents of an Accept-Language |
7705 |
header to be sent in every request are strongly encouraged to let the |
7706 |
configuration process include a message which makes the user aware of |
7707 |
the loss of privacy involved. |
7708 |
|
7709 |
An approach that limits the loss of privacy would be for a user agent to |
7710 |
omit the sending of Accept-Language headers by default, and to ask the |
7711 |
user whether it should start sending Accept-Language headers to a server |
7712 |
if it detects, by looking for any Vary response-header fields generated |
7713 |
by the server, that such sending could improve the quality of service. |
7714 |
|
7715 |
Elaborate user-customized accept header fields sent in every request, in |
7716 |
particular if these include quality values, can be used by servers as |
7717 |
relatively reliable and long-lived user identifiers. Such user |
7718 |
identifiers would allow content providers to do click-trail tracking, |
7719 |
and would allow collaborating content providers to match cross-server |
7720 |
click-trails or form submissions of individual users. Note that for many |
7721 |
users not behind a proxy, the network address of the host running the |
7722 |
user agent will also serve as a long-lived user identifier. In |
7723 |
environments where proxies are used to enhance privacy, user agents |
7724 |
should be conservative in offering accept header configuration options |
7725 |
to end users. As an extreme privacy measure, proxies could filter the |
7726 |
accept headers in relayed requests. General purpose user agents which |
7727 |
provide a high degree of header configurability should warn users about |
7728 |
the loss of privacy which can be involved. |
7729 |
|
7730 |
|
7731 |
|
7732 |
|
7733 |
|
7734 |
|
7735 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 130] |
7736 |
|
7737 |
|
7738 |
|
7739 |
|
7740 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7741 |
|
7742 |
|
7743 |
15.8 DNS Spoofing |
7744 |
|
7745 |
Clients using HTTP rely heavily on the Domain Name Service, and are thus |
7746 |
generally prone to security attacks based on the deliberate mis- |
7747 |
association of IP addresses and DNS names. The deployment of DNSSEC |
7748 |
should help this situation. In advance of this deployment, however, |
7749 |
clients need to be cautious in assuming the continuing validity of an IP |
7750 |
number/DNS name association. |
7751 |
|
7752 |
In particular, HTTP clients SHOULD rely on their name resolver for |
7753 |
confirmation of an IP number/DNS name association, rather than caching |
7754 |
the result of previous host name lookups. Many platforms already can |
7755 |
cache host name lookups locally when appropriate, and they SHOULD be |
7756 |
configured to do so. These lookups should be cached, however, only when |
7757 |
the TTL (Time To Live) information reported by the name server makes it |
7758 |
likely that the cached information will remain useful. |
7759 |
|
7760 |
If HTTP clients cache the results of host name lookups in order to |
7761 |
achieve a performance improvement, they MUST observe the TTL information |
7762 |
reported by DNS. |
7763 |
|
7764 |
If HTTP clients do not observe this rule, they could be spoofed when a |
7765 |
previously-accessed server's IP address changes. As network renumbering |
7766 |
is expected to become increasingly common, the possibility of this form |
7767 |
of attack will grow. Observing this requirement thus reduces this |
7768 |
potential security vulnerability. |
7769 |
|
7770 |
This requirement also improves the load-balancing behavior of clients |
7771 |
for replicated servers using the same DNS name and reduces the |
7772 |
likelihood of a user's experiencing failure in accessing sites which use |
7773 |
that strategy. |
7774 |
|
7775 |
|
7776 |
15.9 Location Headers and Spoofing |
7777 |
|
7778 |
If a single server supports multiple organizations that do not trust one |
7779 |
another, then it must check the values of Location and Content-Location |
7780 |
headers in responses that are generated under control of said |
7781 |
organizations to make sure that they do not attempt to invalidate |
7782 |
resources over which they have no authority. |
7783 |
|
7784 |
|
7785 |
16 Acknowledgments |
7786 |
|
7787 |
This specification makes heavy use of the augmented BNF and generic |
7788 |
constructs defined by David H. Crocker for RFC 822 . Similarly, it |
7789 |
reuses many of the definitions provided by Nathaniel Borenstein and Ned |
7790 |
Freed for MIME . We hope that their inclusion in this specification will |
7791 |
help reduce past confusion over the relationship between HTTP and |
7792 |
Internet mail message formats. |
7793 |
|
7794 |
|
7795 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 131] |
7796 |
|
7797 |
|
7798 |
|
7799 |
|
7800 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7801 |
|
7802 |
|
7803 |
The HTTP protocol has evolved considerably over the past four years. It |
7804 |
has benefited from a large and active developer community--the many |
7805 |
people who have participated on the www-talk mailing list--and it is |
7806 |
that community which has been most responsible for the success of HTTP |
7807 |
and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, |
7808 |
Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip |
7809 |
M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, |
7810 |
Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |
7811 |
recognition for their efforts in defining early aspects of the protocol. |
7812 |
|
7813 |
This document has benefited greatly from the comments of all those |
7814 |
participating in the HTTP-WG. In addition to those already mentioned, |
7815 |
the following individuals have contributed to this specification: |
7816 |
|
7817 |
Gary Adams Jean-Philippe Martin-Flatin |
7818 |
Harald Tveit Alvestrand Larry Masinter |
7819 |
Keith Ball Mitra |
7820 |
Brian Behlendorf David Morris |
7821 |
Paul Burchard Gavin Nicol |
7822 |
Maurizio Codogno Bill Perry |
7823 |
Mike Cowlishaw Jeffrey Perry |
7824 |
Roman Czyborra Scott Powers |
7825 |
Michael A. Dolan Owen Rees |
7826 |
Alan Freier Luigi Rizzo |
7827 |
Marc Hedlund David Robinson |
7828 |
Greg Herlihy Marc Salomon |
7829 |
Koen Holtman Rich Salz |
7830 |
Alex Hopmann Allan M. Schiffman |
7831 |
Bob Jernigan Jim Seidman |
7832 |
Shel Kaphan Chuck Shotton |
7833 |
Rohit Khare Eric W. Sink |
7834 |
Martijn Koster Simon E. Spero |
7835 |
Alexei Kosut Richard N. Taylor |
7836 |
David M. Kristol Robert S. Thau |
7837 |
Daniel LaLiberte Bill (BearHeart) Weinman |
7838 |
Paul J. Leach Francois Yergeau |
7839 |
Albert Lunde Mary Ellen Zurko |
7840 |
John C. Mallery John Klensin |
7841 |
|
7842 |
Much of the content and presentation of the caching design is due to |
7843 |
suggestions and comments from individuals including: Shel Kaphan, Paul |
7844 |
Leach, Koen Holtman, David Morris, and Larry Masinter. |
7845 |
|
7846 |
Most of the specification of ranges is based on work originally done by |
7847 |
Ari Luotonen and John Franks, with additional input from Steve Zilles |
7848 |
and Roy Fielding. |
7849 |
|
7850 |
Thanks to the "cave men" of Palo Alto. You know who you are. |
7851 |
|
7852 |
Jim Gettys (the current editor of this document) wishes particularly to |
7853 |
thank Roy Fielding, the previous editor of this document, along with |
7854 |
|
7855 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 132] |
7856 |
|
7857 |
|
7858 |
|
7859 |
|
7860 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7861 |
|
7862 |
|
7863 |
John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John |
7864 |
Franks, and Larry Masinter for their help. |
7865 |
|
7866 |
|
7867 |
17 References |
7868 |
|
7869 |
|
7870 |
[1] H. Alvestrand. "Tags for the identification of languages." RFC |
7871 |
|
7872 |
1766, UNINETT, March 1995. |
7873 |
|
7874 |
|
7875 |
[2] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, |
7876 |
B. Alberti. "The Internet Gopher Protocol: (a distributed document |
7877 |
|
7878 |
search and retrieval protocol)", RFC 1436, University of Minnesota, |
7879 |
March 1993. |
7880 |
|
7881 |
|
7882 |
[3] T. Berners-Lee. "Universal Resource Identifiers in WWW." A |
7883 |
|
7884 |
Unifying Syntax for the Expression of Names and Addresses of Objects |
7885 |
on the Network as used in the World-Wide Web." RFC 1630, CERN, June |
7886 |
1994. |
7887 |
|
7888 |
|
7889 |
[4] T. Berners-Lee, L. Masinter, M. McCahill. |
7890 |
"Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, |
7891 |
|
7892 |
University of Minnesota, December 1994. |
7893 |
|
7894 |
|
7895 |
[5] T. Berners-Lee, D. Connolly. |
7896 |
"HyperText Markup Language Specification - 2.0." RFC 1866, MIT/LCS, |
7897 |
|
7898 |
November 1995. |
7899 |
|
7900 |
|
7901 |
[6] T. Berners-Lee, R. Fielding, H. Frystyk. |
7902 |
"Hypertext Transfer Protocol -- HTTP/1.0." RFC 1945." MIT/LCS, UC |
7903 |
|
7904 |
Irvine, May 1996. |
7905 |
|
7906 |
|
7907 |
[7] N. Borenstein, N. Freed. |
7908 |
"MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms |
7909 |
|
7910 |
for Specifying and Describing the Format of Internet Message Bodies." |
7911 |
RFC 1521, Bellcore, Innosoft, September 1993. |
7912 |
|
7913 |
|
7914 |
|
7915 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 133] |
7916 |
|
7917 |
|
7918 |
|
7919 |
|
7920 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7921 |
|
7922 |
|
7923 |
[8] R. Braden. |
7924 |
"Requirements for Internet hosts - application and support." STD 3, |
7925 |
|
7926 |
RFC 1123, IETF, October 1989. |
7927 |
|
7928 |
|
7929 |
[9] D. H. Crocker. |
7930 |
"Standard for the Format of ARPA Internet Text Messages." STD 11, RFC |
7931 |
|
7932 |
822, UDEL, August 1982. |
7933 |
|
7934 |
|
7935 |
[10] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. |
7936 |
Sui, M. Grinbaum. "WAIS Interface Protocol Prototype Functional |
7937 |
Specification." (v1.5), Thinking Machines Corporation, April 1990. |
7938 |
|
7939 |
|
7940 |
[11] R. Fielding. "Relative Uniform Resource Locators." RFC 1808, UC |
7941 |
|
7942 |
Irvine, June 1995. |
7943 |
|
7944 |
|
7945 |
[12] M. Horton, R. Adams. |
7946 |
"Standard for interchange of USENET messages." RFC 1036 (Obsoletes |
7947 |
|
7948 |
RFC 850), AT&T Bell Laboratories, Center for Seismic Studies, |
7949 |
December 1987. |
7950 |
|
7951 |
|
7952 |
[13] B. Kantor, P. Lapsley. "Network News Transfer Protocol." A |
7953 |
|
7954 |
Proposed Standard for the Stream-Based Transmission of News." RFC |
7955 |
977, UC San Diego, UC Berkeley, February 1986. |
7956 |
|
7957 |
|
7958 |
[14] K. Moore. "MIME (Multipurpose Internet Mail Extensions) Part Two |
7959 |
|
7960 |
: Message Header Extensions for Non-ASCII Text." RFC 1522, University |
7961 |
of Tennessee, September 1993. |
7962 |
|
7963 |
|
7964 |
[15] E. Nebel, L. Masinter. "Form-based File Upload in HTML." RFC |
7965 |
|
7966 |
1867, Xerox Corporation, November 1995. |
7967 |
|
7968 |
|
7969 |
[16] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821, |
7970 |
|
7971 |
USC/ISI, August 1982. |
7972 |
|
7973 |
|
7974 |
|
7975 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 134] |
7976 |
|
7977 |
|
7978 |
|
7979 |
|
7980 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
7981 |
|
7982 |
|
7983 |
[17] J. Postel. "Media Type Registration Procedure." RFC 1590, |
7984 |
|
7985 |
USC/ISI, March 1994. |
7986 |
|
7987 |
|
7988 |
[18] J. Postel, J. K. Reynolds. "File Transfer Protocol (FTP)." STD |
7989 |
|
7990 |
9, RFC 959, USC/ISI, October 1985. |
7991 |
|
7992 |
|
7993 |
[19] J. Reynolds, J. Postel. "Assigned Numbers." STD 2, RFC 1700, |
7994 |
|
7995 |
USC/ISI, October 1994. |
7996 |
|
7997 |
|
7998 |
[20] K. Sollins, L. Masinter. |
7999 |
"Functional Requirements for Uniform Resource Names." RFC 1737, |
8000 |
|
8001 |
MIT/LCS, Xerox Corporation, December 1994. |
8002 |
|
8003 |
|
8004 |
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for |
8005 |
Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. |
8006 |
|
8007 |
|
8008 |
[22] ISO-8859. International Standard -- Information Processing -- |
8009 |
8-bit Single-Byte Coded Graphic Character Sets -- |
8010 |
Part 1: Latin alphabet No. 1, ISO 8859-1:1987. |
8011 |
Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. |
8012 |
Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. |
8013 |
Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. |
8014 |
Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. |
8015 |
Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. |
8016 |
Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. |
8017 |
Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. |
8018 |
Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. |
8019 |
|
8020 |
|
8021 |
[23] Meyers, M. Rose "The Content-MD5 Header Field." RFC 1864, |
8022 |
|
8023 |
Carnegie Mellon, Dover Beach Consulting, October, 1995. |
8024 |
|
8025 |
|
8026 |
[24] B. Carpenter, Y. Rekhter, "Renumbering Needs Work." RFC 1900, |
8027 |
|
8028 |
IAB, February 1996. |
8029 |
|
8030 |
|
8031 |
[25] P. Deutsch, "GZIP file format specification version 4.3." RFC |
8032 |
|
8033 |
1952, Aladdin Enterprises, May, 1996. |
8034 |
|
8035 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 135] |
8036 |
|
8037 |
|
8038 |
|
8039 |
|
8040 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8041 |
|
8042 |
|
8043 |
[26] Jeffrey C. Mogul. "The Case for Persistent-Connection HTTP". In |
8044 |
Proc. SIGCOMM '95 Symposium on Communications Architectures and |
8045 |
Protocols, pages 299-313. Cambridge, MA, August, 1995. A longer, more |
8046 |
comprehensive version of this paper is available on line at |
8047 |
<URL |
8048 |
:http://www.research.digital.com/wrl/techreports/abstracts/95.4.html |
8049 |
|
8050 |
>, Digital Equipment Corporation Western Research Laboratory Research |
8051 |
Report 95/4, May, 1995., |
8052 |
|
8053 |
|
8054 |
[27] Work in progress on content negotiation of the HTTP working |
8055 |
group. |
8056 |
|
8057 |
|
8058 |
[28] Mills, D, "Network Time Protocol, Version 3.", Specification, |
8059 |
|
8060 |
Implementation and Analysis RFC 1305, University of Delaware, March, |
8061 |
1992. |
8062 |
|
8063 |
|
8064 |
[29] P. Deutsch, |
8065 |
"DEFLATE Compressed Data Format Specification version 1.3." RFC 1951, |
8066 |
|
8067 |
Aladdin Enterprises, May 1996. |
8068 |
|
8069 |
|
8070 |
[30] S. Spero. "Analysis of HTTP Performance Problems" |
8071 |
<URL:http://sunsite.unc.edu/mdma-release/http-prob.html> |
8072 |
|
8073 |
|
8074 |
[31] P. Deutsch, J-L. Gailly, |
8075 |
"ZLIB Compressed Data Format Specification version 3.3." RFC 1950, |
8076 |
|
8077 |
Aladdin Enterprises, Info-ZIP, May 1996. |
8078 |
|
8079 |
|
8080 |
[32] Work In Progress for Digest authentication of the IETF HTTP |
8081 |
working group. |
8082 |
|
8083 |
|
8084 |
18 Authors' Addresses |
8085 |
|
8086 |
Roy T. Fielding |
8087 |
|
8088 |
Department of Information and Computer Science |
8089 |
University of California |
8090 |
Irvine, CA 92717-3425, USA |
8091 |
Fax: +1 (714) 824-4056 |
8092 |
Email: fielding@ics.uci.edu |
8093 |
|
8094 |
|
8095 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 136] |
8096 |
|
8097 |
|
8098 |
|
8099 |
|
8100 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8101 |
|
8102 |
|
8103 |
Henrik Frystyk Nielsen |
8104 |
|
8105 |
W3 Consortium |
8106 |
MIT Laboratory for Computer Science |
8107 |
545 Technology Square |
8108 |
Cambridge, MA 02139, USA |
8109 |
Fax: +1 (617) 258 8682 |
8110 |
Email: frystyk@w3.org |
8111 |
|
8112 |
Tim Berners-Lee |
8113 |
|
8114 |
Director, W3 Consortium |
8115 |
MIT Laboratory for Computer Science |
8116 |
545 Technology Square |
8117 |
Cambridge, MA 02139, USA |
8118 |
Fax: +1 (617) 258 8682 |
8119 |
Email: timbl@w3.org |
8120 |
|
8121 |
Jim Gettys |
8122 |
|
8123 |
MIT Laboratory for Computer Science |
8124 |
545 Technology Square |
8125 |
Cambridge, MA 02139, USA |
8126 |
Fax: +1 (617) 258 8682 |
8127 |
Email: jg@w3.org |
8128 |
|
8129 |
Jeffrey C. Mogul |
8130 |
|
8131 |
Western Research Laboratory |
8132 |
Digital Equipment Corporation |
8133 |
250 University Avenue |
8134 |
Palo Alto, California, 94305, USA |
8135 |
Email: mogul@wrl.dec.com |
8136 |
|
8137 |
|
8138 |
19 Appendices |
8139 |
|
8140 |
|
8141 |
19.1 Internet Media Type message/http |
8142 |
|
8143 |
In addition to defining the HTTP/1.1 protocol, this document serves as |
8144 |
the specification for the Internet media type "message/http". The |
8145 |
following is to be registered with IANA . |
8146 |
|
8147 |
Media Type name: message |
8148 |
Media subtype name: http |
8149 |
Required parameters: none |
8150 |
Optional parameters: version, msgtype |
8151 |
|
8152 |
|
8153 |
|
8154 |
|
8155 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 137] |
8156 |
|
8157 |
|
8158 |
|
8159 |
|
8160 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8161 |
|
8162 |
|
8163 |
version: The HTTP-Version number of the enclosed message |
8164 |
(e.g., "1.1"). If not present, the version can be |
8165 |
determined from the first line of the body. |
8166 |
|
8167 |
msgtype: The message type -- "request" or "response". If not |
8168 |
present, the type can be determined from the first |
8169 |
line of the body. |
8170 |
|
8171 |
Encoding considerations: only "7bit", "8bit", or "binary" are |
8172 |
permitted |
8173 |
|
8174 |
Security considerations: none |
8175 |
|
8176 |
|
8177 |
19.2 Internet Media Type multipart/byteranges |
8178 |
|
8179 |
When an HTTP message includes the content of multiple ranges (for |
8180 |
example, a response to a request for multiple non-overlapping ranges), |
8181 |
these are transmitted as a multipart MIME message. The multipart media |
8182 |
type for this purpose is called "multipart/byteranges". |
8183 |
|
8184 |
The multipart/byteranges media type includes two or more parts, each |
8185 |
with its own Content-Type and Content-Range fields. The parts are |
8186 |
separated using a MIME boundary parameter. |
8187 |
|
8188 |
Media Type name: multipart |
8189 |
Media subtype name: byteranges |
8190 |
Required parameters: none |
8191 |
Optional parameters: version, msgtype |
8192 |
|
8193 |
version: The HTTP-Version number of the enclosed message |
8194 |
(e.g., "1.1"). If not present, the version can be |
8195 |
determined from the first line of the body. |
8196 |
|
8197 |
msgtype: The message type -- "request" or "response". If not |
8198 |
present, the type can be determined from the first |
8199 |
line of the body. |
8200 |
|
8201 |
Encoding considerations: only "7bit", "8bit", or "binary" are |
8202 |
permitted |
8203 |
|
8204 |
Security considerations: none |
8205 |
|
8206 |
For example: |
8207 |
|
8208 |
HTTP/1.1 206 Partial content |
8209 |
Date: Wed, 15 Nov 1995 06:25:24 GMT |
8210 |
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT |
8211 |
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
8212 |
|
8213 |
|
8214 |
|
8215 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 138] |
8216 |
|
8217 |
|
8218 |
|
8219 |
|
8220 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8221 |
|
8222 |
|
8223 |
--THIS_STRING_SEPARATES |
8224 |
Content-type: application/pdf |
8225 |
Content-range: bytes 500-999/8000 |
8226 |
|
8227 |
...the first range... |
8228 |
--THIS_STRING_SEPARATES |
8229 |
Content-type: application/pdf |
8230 |
Content-range: bytes 7000-7999/8000 |
8231 |
|
8232 |
...the second range |
8233 |
--THIS_STRING_SEPARATES-- |
8234 |
|
8235 |
|
8236 |
19.3 Tolerant Applications |
8237 |
|
8238 |
Although this document specifies the requirements for the generation of |
8239 |
HTTP/1.1 messages, not all applications will be correct in their |
8240 |
implementation. We therefore recommend that operational applications be |
8241 |
tolerant of deviations whenever those deviations can be interpreted |
8242 |
unambiguously. |
8243 |
|
8244 |
Clients SHOULD be tolerant in parsing the Status-Line and servers |
8245 |
tolerant when parsing the Request-Line. In particular, they SHOULD |
8246 |
accept any amount of SP or HT characters between fields, even though |
8247 |
only a single SP is required. |
8248 |
|
8249 |
The line terminator for message-header fields is the sequence CRLF. |
8250 |
However, we recommend that applications, when parsing such headers, |
8251 |
recognize a single LF as a line terminator and ignore the leading CR. |
8252 |
|
8253 |
The character set of an entity-body should be labeled as the lowest |
8254 |
common denominator of the character codes used within that body, with |
8255 |
the exception that no label is preferred over the labels US-ASCII or |
8256 |
ISO-8859-1. |
8257 |
|
8258 |
Additional rules for requirements on parsing and encoding of dates and |
8259 |
other potential problems with date encodings include: |
8260 |
|
8261 |
. HTTP/1.1 clients and caches should assume that an RFC-850 date |
8262 |
which appears to be more than 50 years in the future is in fact in |
8263 |
the past (this helps solve the "year 2000" problem). |
8264 |
. An HTTP/1.1 implementation may internally represent a parsed |
8265 |
Expires date as earlier than the proper value, but MUST NOT |
8266 |
internally represent a parsed Expires date as later than the proper |
8267 |
value. |
8268 |
. All expiration-related calculations must be done in GMT. The local |
8269 |
time zone MUST NOT influence the calculation or comparison of an |
8270 |
age or expiration time. |
8271 |
. If an HTTP header incorrectly carries a date value with a time zone |
8272 |
other than GMT, it must be converted into GMT using the most |
8273 |
conservative possible conversion. |
8274 |
|
8275 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 139] |
8276 |
|
8277 |
|
8278 |
|
8279 |
|
8280 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8281 |
|
8282 |
|
8283 |
19.4 Differences Between HTTP Entities and RFC 1521 Entities |
8284 |
|
8285 |
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 |
8286 |
) and the Multipurpose Internet Mail Extensions (MIME ) to allow |
8287 |
entities to be transmitted in an open variety of representations and |
8288 |
with extensible mechanisms. However, RFC 1521 discusses mail, and HTTP |
8289 |
has a few features that are different from those described in RFC 1521. |
8290 |
These differences were carefully chosen to optimize performance over |
8291 |
binary connections, to allow greater freedom in the use of new media |
8292 |
types, to make date comparisons easier, and to acknowledge the practice |
8293 |
of some early HTTP servers and clients. |
8294 |
|
8295 |
At the time of this writing, it is expected that RFC 1521 will be |
8296 |
revised. The revisions may include some of the practices found in |
8297 |
HTTP/1.1 but not in RFC 1521. |
8298 |
|
8299 |
This appendix describes specific areas where HTTP differs from RFC 1521. |
8300 |
Proxies and gateways to strict MIME environments SHOULD be aware of |
8301 |
these differences and provide the appropriate conversions where |
8302 |
necessary. Proxies and gateways from MIME environments to HTTP also need |
8303 |
to be aware of the differences because some conversions may be required. |
8304 |
|
8305 |
|
8306 |
19.4.1 Conversion to Canonical Form |
8307 |
|
8308 |
RFC 1521 requires that an Internet mail entity be converted to canonical |
8309 |
form prior to being transferred, as described in Appendix G of RFC 1521 |
8310 |
. Section 3.7.1 of this document describes the forms allowed for |
8311 |
subtypes of the "text" media type when transmitted over HTTP. RFC 1521 |
8312 |
requires that content with a type of "text" represent line breaks as |
8313 |
CRLF and forbids the use of CR or LF outside of line break sequences. |
8314 |
HTTP allows CRLF, bare CR, and bare LF to indicate a line break within |
8315 |
text content when a message is transmitted over HTTP. |
8316 |
|
8317 |
Where it is possible, a proxy or gateway from HTTP to a strict RFC 1521 |
8318 |
environment SHOULD translate all line breaks within the text media types |
8319 |
described in section 3.7.1 of this document to the RFC 1521 canonical |
8320 |
form of CRLF. Note, however, that this may be complicated by the |
8321 |
presence of a Content-Encoding and by the fact that HTTP allows the use |
8322 |
of some character sets which do not use octets 13 and 10 to represent CR |
8323 |
and LF, as is the case for some multi-byte character sets. |
8324 |
|
8325 |
|
8326 |
19.4.2 Conversion of Date Formats |
8327 |
|
8328 |
HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to |
8329 |
simplify the process of date comparison. Proxies and gateways from other |
8330 |
protocols SHOULD ensure that any Date header field present in a message |
8331 |
conforms to one of the HTTP/1.1 formats and rewrite the date if |
8332 |
necessary. |
8333 |
|
8334 |
|
8335 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 140] |
8336 |
|
8337 |
|
8338 |
|
8339 |
|
8340 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8341 |
|
8342 |
|
8343 |
19.4.3 Introduction of Content-Encoding |
8344 |
|
8345 |
RFC 1521 does not include any concept equivalent to HTTP/1.1's Content- |
8346 |
Encoding header field. Since this acts as a modifier on the media type, |
8347 |
proxies and gateways from HTTP to MIME-compliant protocols MUST either |
8348 |
change the value of the Content-Type header field or decode the entity- |
8349 |
body before forwarding the message. (Some experimental applications of |
8350 |
Content-Type for Internet mail have used a media-type parameter of |
8351 |
";conversions=<content-coding>" to perform an equivalent function as |
8352 |
Content-Encoding. However, this parameter is not part of RFC 1521.) |
8353 |
|
8354 |
|
8355 |
19.4.4 No Content-Transfer-Encoding |
8356 |
|
8357 |
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 1521. |
8358 |
Proxies and gateways from MIME-compliant protocols to HTTP MUST remove |
8359 |
any non-identity CTE ("quoted-printable" or "base64") encoding prior to |
8360 |
delivering the response message to an HTTP client. |
8361 |
|
8362 |
Proxies and gateways from HTTP to MIME-compliant protocols are |
8363 |
responsible for ensuring that the message is in the correct format and |
8364 |
encoding for safe transport on that protocol, where "safe transport" is |
8365 |
defined by the limitations of the protocol being used. Such a proxy or |
8366 |
gateway SHOULD label the data with an appropriate Content-Transfer- |
8367 |
Encoding if doing so will improve the likelihood of safe transport over |
8368 |
the destination protocol. |
8369 |
|
8370 |
|
8371 |
19.4.5 HTTP Header Fields in Multipart Body-Parts |
8372 |
|
8373 |
In RFC 1521, most header fields in multipart body-parts are generally |
8374 |
ignored unless the field name begins with "Content-". In HTTP/1.1, |
8375 |
multipart body-parts may contain any HTTP header fields which are |
8376 |
significant to the meaning of that part. |
8377 |
|
8378 |
|
8379 |
19.4.6 Introduction of Transfer-Encoding |
8380 |
|
8381 |
HTTP/1.1 introduces the Transfer-Encoding header field (section 14.40). |
8382 |
Proxies/gateways MUST remove any transfer coding prior to forwarding a |
8383 |
message via a MIME-compliant protocol. |
8384 |
|
8385 |
A process for decoding the "chunked" transfer coding (section 3.6) can |
8386 |
be represented in pseudo-code as: |
8387 |
|
8388 |
length := 0 |
8389 |
read chunk-size, chunk-ext (if any) and CRLF |
8390 |
while (chunk-size > 0) { |
8391 |
read chunk-data and CRLF |
8392 |
append chunk-data to entity-body |
8393 |
length := length + chunk-size |
8394 |
|
8395 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 141] |
8396 |
|
8397 |
|
8398 |
|
8399 |
|
8400 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8401 |
|
8402 |
|
8403 |
read chunk-size and CRLF |
8404 |
} |
8405 |
read entity-header |
8406 |
while (entity-header not empty) { |
8407 |
append entity-header to existing header fields |
8408 |
read entity-header |
8409 |
} |
8410 |
Content-Length := length |
8411 |
Remove "chunked" from Transfer-Encoding |
8412 |
|
8413 |
|
8414 |
19.4.7 MIME-Version |
8415 |
|
8416 |
HTTP is not a MIME-compliant protocol (see appendix 19.4). However, |
8417 |
HTTP/1.1 messages may include a single MIME-Version general-header field |
8418 |
to indicate what version of the MIME protocol was used to construct the |
8419 |
message. Use of the MIME-Version header field indicates that the message |
8420 |
is in full compliance with the MIME protocol (as defined in RFC 1521). |
8421 |
Proxies/gateways are responsible for ensuring full compliance (where |
8422 |
possible) when exporting HTTP messages to strict MIME environments. |
8423 |
|
8424 |
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT |
8425 |
|
8426 |
MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 |
8427 |
message parsing and semantics are defined by this document and not the |
8428 |
MIME specification. |
8429 |
|
8430 |
|
8431 |
19.5 Changes from HTTP/1.0 |
8432 |
|
8433 |
This section summarizes major differences between versions HTTP/1.0 and |
8434 |
HTTP/1.1. |
8435 |
|
8436 |
|
8437 |
19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP |
8438 |
Addresses |
8439 |
|
8440 |
The requirements that clients and servers support the Host request- |
8441 |
header, report an error if the Host request-header (section 14.23) is |
8442 |
missing from an HTTP/1.1 request, and accept absolute URIs (section |
8443 |
5.1.2) are among the most important changes defined by this |
8444 |
specification. |
8445 |
|
8446 |
Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses |
8447 |
and servers; there was no other established mechanism for distinguishing |
8448 |
the intended server of a request than the IP address to which that |
8449 |
request was directed. The changes outlined above will allow the |
8450 |
Internet, once older HTTP clients are no longer common, to support |
8451 |
multiple Web sites from a single IP address, greatly simplifying large |
8452 |
operational Web servers, where allocation of many IP addresses to a |
8453 |
single host has created serious problems. The Internet will also be able |
8454 |
|
8455 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 142] |
8456 |
|
8457 |
|
8458 |
|
8459 |
|
8460 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8461 |
|
8462 |
|
8463 |
to recover the IP addresses that have been allocated for the sole |
8464 |
purpose of allowing special-purpose domain names to be used in root- |
8465 |
level HTTP URLs. Given the rate of growth of the Web, and the number of |
8466 |
servers already deployed, it is extremely important that all |
8467 |
implementations of HTTP (including updates to existing HTTP/1.0 |
8468 |
applications) correctly implement these requirements: |
8469 |
|
8470 |
|
8471 |
. Both clients and servers MUST support the Host request-header. |
8472 |
|
8473 |
. Host request-headers are required in HTTP/1.1 requests. |
8474 |
|
8475 |
. Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |
8476 |
request does not include a Host request-header. |
8477 |
|
8478 |
. Servers MUST accept absolute URIs. |
8479 |
|
8480 |
19.6 Additional Features |
8481 |
|
8482 |
This appendix documents protocol elements used by some existing HTTP |
8483 |
implementations, but not consistently and correctly across most HTTP/1.1 |
8484 |
applications. Implementers should be aware of these features, but cannot |
8485 |
rely upon their presence in, or interoperability with, other HTTP/1.1 |
8486 |
applications. Some of these describe proposed experimental features, and |
8487 |
some describe features that experimental deployment found lacking that |
8488 |
are now addressed in the base HTTP/1.1 specification. |
8489 |
|
8490 |
|
8491 |
19.6.1 Additional Request Methods |
8492 |
|
8493 |
|
8494 |
19.6.1.1 PATCH |
8495 |
The PATCH method is similar to PUT except that the entity contains a |
8496 |
list of differences between the original version of the resource |
8497 |
identified by the Request-URI and the desired content of the resource |
8498 |
after the PATCH action has been applied. The list of differences is in a |
8499 |
format defined by the media type of the entity (e.g., |
8500 |
"application/diff") and MUST include sufficient information to allow the |
8501 |
server to recreate the changes necessary to convert the original version |
8502 |
of the resource to the desired version. |
8503 |
|
8504 |
If the request passes through a cache and the Request-URI identifies a |
8505 |
currently cached entity, that entity MUST be removed from the cache. |
8506 |
Responses to this method are not cachable. |
8507 |
|
8508 |
The actual method for determining how the patched resource is placed, |
8509 |
and what happens to its predecessor, is defined entirely by the origin |
8510 |
server. If the original version of the resource being patched included a |
8511 |
Content-Version header field, the request entity MUST include a Derived- |
8512 |
From header field corresponding to the value of the original Content- |
8513 |
Version header field. Applications are encouraged to use these fields |
8514 |
|
8515 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 143] |
8516 |
|
8517 |
|
8518 |
|
8519 |
|
8520 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8521 |
|
8522 |
|
8523 |
for constructing versioning relationships and resolving version |
8524 |
conflicts. |
8525 |
|
8526 |
PATCH requests must obey the message transmission requirements set out |
8527 |
in section 8.2. |
8528 |
|
8529 |
Caches that implement PATCH should invalidate cached responses as |
8530 |
defined in section 13.8 for PUT. |
8531 |
|
8532 |
|
8533 |
19.6.1.2 LINK |
8534 |
The LINK method establishes one or more Link relationships between the |
8535 |
existing resource identified by the Request-URI and other existing |
8536 |
resources. The difference between LINK and other methods allowing links |
8537 |
to be established between resources is that the LINK method does not |
8538 |
allow any message-body to be sent in the request and does not directly |
8539 |
result in the creation of new resources. |
8540 |
|
8541 |
If the request passes through a cache and the Request-URI identifies a |
8542 |
currently cached entity, that entity MUST be removed from the cache. |
8543 |
Responses to this method are not cachable. |
8544 |
|
8545 |
Caches that implement LINK should invalidate cached responses as defined |
8546 |
in section 13.8 for PUT. |
8547 |
|
8548 |
|
8549 |
19.6.1.3 UNLINK |
8550 |
The UNLINK method removes one or more Link relationships from the |
8551 |
existing resource identified by the Request-URI. These relationships may |
8552 |
have been established using the LINK method or by any other method |
8553 |
supporting the Link header. The removal of a link to a resource does not |
8554 |
imply that the resource ceases to exist or becomes inaccessible for |
8555 |
future references. |
8556 |
|
8557 |
If the request passes through a cache and the Request-URI identifies a |
8558 |
currently cached entity, that entity MUST be removed from the cache. |
8559 |
Responses to this method are not cachable. |
8560 |
|
8561 |
Caches that implement UNLINK should invalidate cached responses as |
8562 |
defined in section 13.8 for PUT. |
8563 |
|
8564 |
|
8565 |
19.6.2 Additional Header Field Definitions |
8566 |
|
8567 |
|
8568 |
19.6.2.1 Alternates |
8569 |
The Alternates response-header field has been proposed as a means for |
8570 |
the origin server to inform the client about other available |
8571 |
representations of the requested resource (variants), along with their |
8572 |
distinguishing attributes, and thus providing a more reliable means for |
8573 |
a user agent to perform subsequent selection of another representation |
8574 |
|
8575 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 144] |
8576 |
|
8577 |
|
8578 |
|
8579 |
|
8580 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8581 |
|
8582 |
|
8583 |
which better fits the desires of its user (described as agent-driven |
8584 |
negotiation in section 12). |
8585 |
|
8586 |
The Alternates header field is orthogonal to the Vary header field in |
8587 |
that both may coexist in a message without affecting the interpretation |
8588 |
of the response or the available representations. It is expected that |
8589 |
Alternates will provide a significant improvement over the server-driven |
8590 |
negotiation provided by the Vary field for those resources that vary |
8591 |
over common dimensions like type and language. |
8592 |
|
8593 |
The Alternates header field will be defined in a future specification. |
8594 |
|
8595 |
|
8596 |
19.6.2.2 Content-Version |
8597 |
The Content-Version entity-header field defines the version tag |
8598 |
associated with a rendition of an evolving entity. Together with the |
8599 |
Derived-From field described in section 19.6.2.3, it allows a group of |
8600 |
people to work simultaneously on the creation of a work as an iterative |
8601 |
process. The field should be used to allow evolution of a particular |
8602 |
work along a single path rather than derived works or renditions in |
8603 |
different representations. |
8604 |
|
8605 |
Content-Version = "Content-Version" ":" quoted-string |
8606 |
|
8607 |
Examples of the Content-Version field include: |
8608 |
|
8609 |
Content-Version: "2.1.2" |
8610 |
Content-Version: "Fred 19950116-12:26:48" |
8611 |
Content-Version: "2.5a4-omega7" |
8612 |
|
8613 |
|
8614 |
19.6.2.3 Derived-From |
8615 |
The Derived-From entity-header field can be used to indicate the version |
8616 |
tag of the resource from which the enclosed entity was derived before |
8617 |
modifications were made by the sender. This field is used to help manage |
8618 |
the process of merging successive changes to a resource, particularly |
8619 |
when such changes are being made in parallel and from multiple sources. |
8620 |
|
8621 |
Derived-From = "Derived-From" ":" quoted-string |
8622 |
|
8623 |
An example use of the field is: |
8624 |
|
8625 |
Derived-From: "2.1.1" |
8626 |
|
8627 |
The Derived-From field is required for PUT and PATCH requests if the |
8628 |
entity being sent was previously retrieved from the same URI and a |
8629 |
Content-Version header was included with the entity when it was last |
8630 |
retrieved. |
8631 |
|
8632 |
|
8633 |
19.6.2.4 Link |
8634 |
|
8635 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 145] |
8636 |
|
8637 |
|
8638 |
|
8639 |
|
8640 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8641 |
|
8642 |
|
8643 |
The Link entity-header field provides a means for describing a |
8644 |
relationship between two resources, generally between the requested |
8645 |
resource and some other resource. An entity MAY include multiple Link |
8646 |
values. Links at the metainformation level typically indicate |
8647 |
relationships like hierarchical structure and navigation paths. The Link |
8648 |
field is semantically equivalent to the <LINK> element in HTML . |
8649 |
|
8650 |
Link = "Link" ":" #("<" URI ">" *( ";" link-param ) |
8651 |
|
8652 |
link-param = ( ( "rel" "=" relationship ) |
8653 |
| ( "rev" "=" relationship ) |
8654 |
| ( "title" "=" quoted-string ) |
8655 |
| ( "anchor" "=" <"> URI <"> ) |
8656 |
| ( link-extension ) ) |
8657 |
|
8658 |
link-extension = token [ "=" ( token | quoted-string ) ] |
8659 |
|
8660 |
relationship = sgml-name |
8661 |
| ( <"> sgml-name *( SP sgml-name) <"> ) |
8662 |
|
8663 |
sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) |
8664 |
|
8665 |
Relationship values are case-insensitive and MAY be extended within the |
8666 |
constraints of the sgml-name syntax. The title parameter MAY be used to |
8667 |
label the destination of a link such that it can be used as |
8668 |
identification within a human-readable menu. The anchor parameter MAY be |
8669 |
used to indicate a source anchor other than the entire current resource, |
8670 |
such as a fragment of this resource or a third resource. |
8671 |
|
8672 |
Examples of usage include: |
8673 |
|
8674 |
Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous" |
8675 |
|
8676 |
Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee" |
8677 |
|
8678 |
The first example indicates that chapter2 is previous to this resource |
8679 |
in a logical navigation path. The second indicates that the person |
8680 |
responsible for making the resource available is identified by the given |
8681 |
e-mail address. |
8682 |
|
8683 |
|
8684 |
19.6.2.5 URI |
8685 |
The URI header field has, in past versions of this specification, been |
8686 |
used as a combination of the existing Location, Content-Location, and |
8687 |
Vary header fields as well as the future Alternates field (above). Its |
8688 |
primary purpose has been to include a list of additional URIs for the |
8689 |
resource, including names and mirror locations. However, it has become |
8690 |
clear that the combination of many different functions within this |
8691 |
single field has been a barrier to consistently and correctly |
8692 |
implementing any of those functions. Furthermore, we believe that the |
8693 |
identification of names and mirror locations would be better performed |
8694 |
|
8695 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 146] |
8696 |
|
8697 |
|
8698 |
|
8699 |
|
8700 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8701 |
|
8702 |
|
8703 |
via the Link header field. The URI header field is therefore deprecated |
8704 |
in favor of those other fields. |
8705 |
|
8706 |
URI-header = "URI" ":" 1#( "<" URI ">" ) |
8707 |
|
8708 |
|
8709 |
19.7 Compatibility with Previous Versions |
8710 |
|
8711 |
It is beyond the scope of a protocol specification to mandate compliance |
8712 |
with previous versions. HTTP/1.1 was deliberately designed, however, to |
8713 |
make supporting previous versions easy. It is worth noting that at the |
8714 |
time of composing this specification, we would expect commercial |
8715 |
HTTP/1.1 servers to: |
8716 |
|
8717 |
|
8718 |
. recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1 |
8719 |
requests; |
8720 |
|
8721 |
. understand any valid request in the format of HTTP/0.9, 1.0, or |
8722 |
1.1; |
8723 |
|
8724 |
. respond appropriately with a message in the same major version used |
8725 |
by the client. |
8726 |
And we would expect HTTP/1.1 clients to: |
8727 |
|
8728 |
|
8729 |
. recognize the format of the Status-Line for HTTP/1.0 and 1.1 |
8730 |
responses; |
8731 |
|
8732 |
. understand any valid response in the format of HTTP/0.9, 1.0, or |
8733 |
1.1. |
8734 |
For most implementations of HTTP/1.0, each connection is established by |
8735 |
the client prior to the request and closed by the server after sending |
8736 |
the response. A few implementations implement the Keep-Alive version of |
8737 |
persistent connections described in section 19.7.1.1. |
8738 |
|
8739 |
|
8740 |
19.7.1 Compatibility with HTTP/1.0 Persistent Connections |
8741 |
|
8742 |
Some clients and servers may wish to be compatible with some previous |
8743 |
implementations of persistent connections in HTTP/1.0 clients and |
8744 |
servers. Persistent connections in HTTP/1.0 must be explicitly |
8745 |
negotiated as they are not the default behavior. HTTP/1.0 experimental |
8746 |
|
8747 |
implementations of persistent connections are faulty, and the new |
8748 |
facilities in HTTP/1.1 are designed to rectify these problems. The |
8749 |
problem was that some existing 1.0 clients may be sending Keep-Alive to |
8750 |
a proxy server that doesn't understand Connection, which would then |
8751 |
erroneously forward it to the next inbound server, which would establish |
8752 |
the Keep-Alive connection and result in a hung HTTP/1.0 proxy waiting |
8753 |
|
8754 |
|
8755 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 147] |
8756 |
|
8757 |
|
8758 |
|
8759 |
|
8760 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8761 |
|
8762 |
|
8763 |
for the close on the response. The result is that HTTP/1.0 clients must |
8764 |
be prevented from using Keep-Alive when talking to proxies. |
8765 |
|
8766 |
However, talking to proxies is the most important use of persistent |
8767 |
connections, so that prohibition is clearly unacceptable. Therefore, we |
8768 |
need some other mechanism for indicating a persistent connection is |
8769 |
desired, which is safe to use even when talking to an old proxy that |
8770 |
ignores Connection. Persistent connections are the default for HTTP/1.1 |
8771 |
messages; we introduce a new keyword (Connection: close) for declaring |
8772 |
non-persistence. |
8773 |
|
8774 |
The following describes the original HTTP/1.0 form of persistent |
8775 |
connections. |
8776 |
|
8777 |
When it connects to an origin server, an HTTP client MAY send the Keep- |
8778 |
Alive connection-token in addition to the Persist connection-token: |
8779 |
|
8780 |
Connection: Keep-Alive |
8781 |
|
8782 |
An HTTP/1.0 server would then respond with the Keep-Alive connection |
8783 |
token and the client may proceed with an HTTP/1.0 (or Keep-Alive) |
8784 |
persistent connection. |
8785 |
|
8786 |
An HTTP/1.1 server may also establish persistent connections with |
8787 |
HTTP/1.0 clients upon receipt of a Keep-Alive connection token. |
8788 |
However, a persistent connection with an HTTP/1.0 client cannot make use |
8789 |
of the chunked transfer-coding, and therefore MUST use a Content-Length |
8790 |
for marking the ending boundary of each message. |
8791 |
|
8792 |
A client MUST NOT send the Keep-Alive connection token to a proxy server |
8793 |
as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1 for parsing |
8794 |
the Connection header field. |
8795 |
|
8796 |
|
8797 |
19.7.1.1 The Keep-Alive Header |
8798 |
When the Keep-Alive connection-token has been transmitted with a request |
8799 |
or a response, a Keep-Alive header field MAY also be included. The Keep- |
8800 |
Alive header field takes the following form: |
8801 |
|
8802 |
Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param |
8803 |
|
8804 |
keepalive-param = param-name "=" value |
8805 |
|
8806 |
The Keep-Alive header itself is optional, and is used only if a |
8807 |
parameter is being sent. HTTP/1.1 does not define any parameters. |
8808 |
|
8809 |
If the Keep-Alive header is sent, the corresponding connection token |
8810 |
MUST be transmitted. The Keep-Alive header MUST be ignored if received |
8811 |
without the connection token. |
8812 |
|
8813 |
|
8814 |
|
8815 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 148] |
8816 |
|
8817 |
|
8818 |
|
8819 |
|
8820 |
INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996 |
8821 |
|
8822 |
|
8823 |
19.8 Notes to RFC Editor and IANA |
8824 |
|
8825 |
This section of the document should be DELETED! It calls for the RFC |
8826 |
editor and IANA to take some actions before the draft becomes a Proposed |
8827 |
Standard. After those actions are taken, please delete this section of |
8828 |
the specification. |
8829 |
|
8830 |
|
8831 |
19.8.1 Charset Registry |
8832 |
|
8833 |
The following names should be added to the IANA character set registry |
8834 |
under the category "Preferred MIME name" and this section deleted. |
8835 |
|
8836 |
"US-ASCII" |
8837 |
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" |
8838 |
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" |
8839 |
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" |
8840 |
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" |
8841 |
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" |
8842 |
| "UNICODE-1-1-UTF-8" |
8843 |
|
8844 |
|
8845 |
19.8.2 Content-coding Values |
8846 |
|
8847 |
HTTP also defines a new class of registry for its content-coding values. |
8848 |
The initial set of values defined in this document are deflate, gzip and |
8849 |
compress. IANA should create a registry with those entries. The registry |
8850 |
should note that "x-gzip" and "x-compress" are used as content-codings |
8851 |
in HTTP but that their use is deprecated. The registry should note that |
8852 |
"specifications of the content coding algorithms needed to implement a |
8853 |
new value should be publicly available and adequate for independent |
8854 |
implementation, and conform to the purpose of content coding defined RFC |
8855 |
XXX." where RFC XXX is the number assigned to this document. |
8856 |
|
8857 |
|
8858 |
19.8.3 New Media Types Registered |
8859 |
|
8860 |
This document defines two new media types which should be registered. |
8861 |
Specifically appendix 19.1 defines the Internet media type message/http |
8862 |
and appendix 19.2 defines multipart/byteranges. |
8863 |
|
8864 |
|
8865 |
19.8.4 Possible Merge With Digest Authentication Draft |
8866 |
|
8867 |
Note that the working group draft for Digest Authentication may be |
8868 |
processed by the IESG at the same time as this document; we leave it to |
8869 |
the RFC editor to decide whether to issue a single RFC containing both |
8870 |
drafts (see section 11.2 for where it would be put); in any case, the |
8871 |
reference in the reference list will need to be either deleted, or made |
8872 |
to the appropriate RFC (and section 11.2 deleted). |
8873 |
|
8874 |
|
8875 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 149] |