1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
INTERNET-DRAFT Mandatory H. Frystyk Nielsen, W3C |
9 |
draft-frystyk-http-extensions-00 P. Leach, Microsoft |
10 |
Scott Lawrence, Agranat Systems |
11 |
Expires: February 07, 1999 Friday, August 07, 1998 |
12 |
|
13 |
HTTP Extension Framework |
14 |
for |
15 |
Mandatory and Optional Extensions |
16 |
|
17 |
|
18 |
Status of this Document |
19 |
|
20 |
This document is an Internet-Draft. Internet-Drafts are working |
21 |
documents of the Internet Engineering Task Force (IETF), its areas, |
22 |
and its working groups. Note that other groups may also distribute |
23 |
working documents as Internet-Drafts. Internet-Drafts are draft |
24 |
documents valid for a maximum of six months and may be updated, |
25 |
replaced, or obsoleted by other documents at any time. It is |
26 |
inappropriate to use Internet-Drafts as reference material or to cite |
27 |
them other than as "work in progress". |
28 |
|
29 |
To learn the current status of any Internet-Draft, please check the |
30 |
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow |
31 |
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), |
32 |
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or |
33 |
ftp.isi.edu (US West Coast). |
34 |
|
35 |
Distribution of this document is unlimited. Please send comments to |
36 |
the <ietf-http-ext@w3.org> mailing list. This list is archived at |
37 |
"http://lists.w3.org/Archives/Public/ietf-http-ext/". |
38 |
|
39 |
The contribution of World Wide Web Consortium (W3C) staff is part of |
40 |
the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity"). |
41 |
|
42 |
|
43 |
Abstract |
44 |
|
45 |
HTTP is used increasingly in applications that need more facilities |
46 |
than the standard version of the protocol provides, ranging from |
47 |
distributed authoring, collaboration, and printing, to various remote |
48 |
procedure call mechanisms. This document proposes the use of a |
49 |
mandatory extension mechanism designed to address the tension between |
50 |
private agreement and public specification and to accommodate |
51 |
extension of applications such as HTTP clients, servers, and proxies. |
52 |
The proposal associates each extension with a URI[2], and use a few |
53 |
new RFC 822[1] style header fields to carry the extension identifier |
54 |
and related information between the parties involved in an extended |
55 |
transaction. |
56 |
|
57 |
|
58 |
Table of Contents |
59 |
|
60 |
1. Introduction.....................................................2 |
61 |
2. Notational Conventions...........................................3 |
62 |
|
63 |
Frystyk et al [Page 1] |
64 |
|
65 |
|
66 |
|
67 |
|
68 |
|
69 |
|
70 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
71 |
|
72 |
3. Extension Declarations...........................................3 |
73 |
3.1 Header Field Prefixes.........................................4 |
74 |
4. Extension Header Fields..........................................4 |
75 |
4.1 End-to-End Extensions.........................................5 |
76 |
4.2 Hop-by-Hop Extensions.........................................5 |
77 |
5. Mandatory HTTP Requests..........................................6 |
78 |
6. Mandatory HTTP Responses.........................................7 |
79 |
7. 102 Extended.....................................................7 |
80 |
8. 510 Not Extended.................................................8 |
81 |
9. Publishing an Extension..........................................8 |
82 |
10. Security Considerations.........................................9 |
83 |
11. References......................................................9 |
84 |
12. Acknowledgements...............................................10 |
85 |
13. Authors Addresses..............................................10 |
86 |
14. Summary of Protocol Interactions...............................11 |
87 |
15. Examples.......................................................11 |
88 |
15.1 Client Requests Server to use an Extension..................12 |
89 |
15.2 Server proposes the use of an Extension.....................12 |
90 |
|
91 |
1. Introduction |
92 |
|
93 |
The mandatory proposal is designed to accommodate dynamic extension of |
94 |
HTTP clients and servers by software components; and to address the |
95 |
tension between private agreement and public specification. The kind |
96 |
of extensions capable of being introduced range from: |
97 |
|
98 |
o extending a single HTTP message; |
99 |
o introducing new encodings; |
100 |
o initiating HTTP-derived protocols for new applications; to... |
101 |
o switching to protocols which, once initiated, run independent of |
102 |
the original protocol stack. |
103 |
|
104 |
The proposal is intended to be used as follows: |
105 |
|
106 |
o Some party designs and specifies an extension; the party assigns |
107 |
the extension an identifier, which is a URI, and makes one or |
108 |
more representations of the extension available at that address |
109 |
(see section 9). |
110 |
o An HTTP client, server, or proxy that implements the Mandatory |
111 |
extension mechanism (hereafter called an agent) declares the use |
112 |
of the extension by referencing its URI in an extension |
113 |
declaration in an HTTP message (see section 3). |
114 |
o The ultimate recipient of the extension declaration which can be |
115 |
the origin server, the user agent, or any intermediary in the |
116 |
request/response chain can based on the extension declaration |
117 |
deduce how to properly interpret the extended message. |
118 |
|
119 |
The proposal uses features in HTTP/1.1 but is compatible with both |
120 |
HTTP/1.0 and HTTP/1.1 applications in such a way that extended |
121 |
applications can coexist with existing HTTP applications. |
122 |
|
123 |
|
124 |
|
125 |
Frystyk, et al [Page 2] |
126 |
|
127 |
|
128 |
|
129 |
|
130 |
|
131 |
|
132 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
133 |
|
134 |
By providing a more robust framework for describing extensions, this |
135 |
proposal supersedes several existing extension mechanisms like the |
136 |
HTTP/1.1 Expect and Upgrade header fields as well as avoids existing |
137 |
problems with non-compliant CGI scripts handling unknown HTTP methods. |
138 |
|
139 |
|
140 |
2. Notational Conventions |
141 |
|
142 |
This specification uses the same notational conventions and basic |
143 |
parsing constructs as RFC 2068[7]. In particular the BNF constructs |
144 |
"token", "quoted-string", "field-name", and "URI" in this document are |
145 |
to be interpreted as described in RFC 2068[7]. |
146 |
|
147 |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
148 |
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
149 |
document are to be interpreted as described in RFC 2119[9]. |
150 |
|
151 |
This proposal does not rely on particular features defined in URLs [3] |
152 |
that cannot potentially be expressed using URNs (see section 9). |
153 |
Therefore, the more generic term URI[2] is used throughout the |
154 |
specification. |
155 |
|
156 |
|
157 |
3. Extension Declarations |
158 |
|
159 |
An extension declaration can be used to indicate that an extension has |
160 |
been applied to a message and possibly to reserve a part of the header |
161 |
namespace identified by a header field prefix (see 3.1). |
162 |
|
163 |
This specification does not define any ramifications of applying an |
164 |
extension to a message nor whether two extensions can or cannot |
165 |
logically coexist within the same message. It is strictly a framework |
166 |
for describing which extensions have been applied and what the |
167 |
ultimate recipient either must or may do in order to properly |
168 |
interpret any extension declarations within that message. |
169 |
|
170 |
The grammar for an extension declaration is as follows: |
171 |
|
172 |
ext-decl = <"> URI <"> ";" namespace [ ext-params ] |
173 |
ext-params = *( ext-extension ) |
174 |
|
175 |
namespace = "ns" "=" header-prefix |
176 |
header-prefix = 2*DIGIT "-" |
177 |
ext-extension = ";" token [ "=" ( token | quoted-string ) ] |
178 |
|
179 |
An extension is identified by a URI. Extension identifier URIs can be |
180 |
either relative or absolute. Relative extension identifiers MUST |
181 |
specify header-fields defined in an IETF RFC (see RFC 1808[4]). |
182 |
Examples of extension declarations are |
183 |
|
184 |
"Content-FooBar" |
185 |
"New-Registered-Header" |
186 |
"http://www.temporary.com/extension"; ns=33- |
187 |
|
188 |
Frystyk, et al [Page 3] |
189 |
|
190 |
|
191 |
|
192 |
|
193 |
|
194 |
|
195 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
196 |
|
197 |
An extension declaration can be extended through the use of one or |
198 |
more ext-extension parameters. Unrecognized ext-extension parameters |
199 |
SHOULD be ignored and MUST NOT be removed by proxies when forwarding |
200 |
the extension declaration. |
201 |
|
202 |
|
203 |
3.1 Header Field Prefixes |
204 |
|
205 |
The header-prefix are dynamically generated header field prefix |
206 |
strings that can be used to indicate that all header fields in the |
207 |
message matching the header-prefix value using string prefix-matching |
208 |
are introduced by this extension instance. This allows an extension |
209 |
instance to dynamically reserve a subspace of the header space in a |
210 |
protocol message in order to prevent header field name clashes. |
211 |
|
212 |
Linear white space (LWS) MUST NOT be used between the digits and the |
213 |
"-". The format of the prefix using a combination of digits and the |
214 |
dash "-" guarantees that no extension declaration can reserve the |
215 |
whole header field name space. |
216 |
|
217 |
Prefixes are primarily intended to avoid header field name conflicts |
218 |
and to allow multiple instances of a single extension using its own |
219 |
header fields to be applied to the same message without conflicting |
220 |
with each other. |
221 |
|
222 |
Agents SHOULD NOT reuse header-prefix values in the same message |
223 |
unless explicitly allowed by the extension (see section 4.1 for a |
224 |
discussion of the ultimate recipient of an extension declaration). |
225 |
|
226 |
Examples of header-prefix values are |
227 |
|
228 |
1234- |
229 |
546- |
230 |
234345653- |
231 |
|
232 |
Old applications may introduce header fields independent of this |
233 |
extension mechanism, potentially conflicting with header fields |
234 |
introduced by the prefix mechanism. In order to minimize this risk, |
235 |
prefixes MUST contain at least 2 digits. |
236 |
|
237 |
|
238 |
4. Extension Header Fields |
239 |
|
240 |
This proposal introduces two types of extension declaration strength: |
241 |
mandatory and optional, and two types of extension declaration scope: |
242 |
hop-by-hop and end-to-end (see section 4.1 and 4.2). |
243 |
|
244 |
A mandatory extension declaration indicates that the ultimate |
245 |
recipient MUST consult and adhere to the rules given by the extension |
246 |
when processing the message or report an error (see section 5 and 8). |
247 |
|
248 |
|
249 |
|
250 |
Frystyk, et al [Page 4] |
251 |
|
252 |
|
253 |
|
254 |
|
255 |
|
256 |
|
257 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
258 |
|
259 |
An optional extension declaration indicates that the ultimate |
260 |
recipient of the extension MAY consult and adhere to the rules given |
261 |
by the extension when processing the message, or ignore the extension |
262 |
declaration completely. An agent may not be able to distinguish |
263 |
whether the ultimate recipient does not understand an extension |
264 |
referred to by an optional extension or simply ignores the extension |
265 |
declaration. |
266 |
|
267 |
The combination of the declaration strength and scope defines a 2x2 |
268 |
matrix which is distinguished by four new general HTTP header fields: |
269 |
Man, Opt, C-Man, and C-Opt. (See section 4.1 and 4.2, and appendix 14 |
270 |
for a table of interactions with origin servers and proxies.) |
271 |
|
272 |
The header fields are general header fields as they describe which |
273 |
extensions actually are applied to an HTTP message. Optional |
274 |
declarations MAY be applied to any HTTP message without any change to |
275 |
existing HTTP semantics. Mandatory declarations MUST be applied to a |
276 |
request message as described in section 5 and to a response message as |
277 |
described in section 6. |
278 |
|
279 |
|
280 |
4.1 End-to-End Extensions |
281 |
|
282 |
End-to-end declarations MUST be transmitted to the ultimate recipient |
283 |
of the declaration. The Man and the Opt general header fields are end- |
284 |
to-end header fields and are defined as follows: |
285 |
|
286 |
mandatory = "Man" ":" 1#ext-decl |
287 |
optional = "Opt" ":" 1#ext-decl |
288 |
|
289 |
For example |
290 |
|
291 |
HTTP/1.1 200 OK |
292 |
Content-Length: 421 |
293 |
Opt: "http://www.digest.org/Digest"; ns=55- |
294 |
55-digest: "snfksjgor2tsajkt52" |
295 |
... |
296 |
|
297 |
If a proxy is the ultimate recipient of a mandatory end-to-end |
298 |
extension declaration then it MUST handle that extension declaration |
299 |
as described in section 5. The proxy SHOULD remove all parts of the |
300 |
extension declaration from the message before forwarding it. |
301 |
|
302 |
|
303 |
4.2 Hop-by-Hop Extensions |
304 |
|
305 |
Hop-by-hop extension declarations are meaningful only for a single |
306 |
transport-level connection. The C-Man and the C-Opt general header |
307 |
field are hop-by-hop header fields and MUST NOT be communicated by |
308 |
proxies over further connections. The two headers have the following |
309 |
grammar: |
310 |
|
311 |
c-mandatory = "C-Man" ":" 1#ext-decl |
312 |
c-optional = "C-Opt" ":" 1#ext-decl |
313 |
|
314 |
Frystyk, et al [Page 5] |
315 |
|
316 |
|
317 |
|
318 |
|
319 |
|
320 |
|
321 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
322 |
|
323 |
For example |
324 |
|
325 |
GET / HTTP/1.1 |
326 |
Host: some.host |
327 |
C-Man: "http://www.digest.org/ProxyAuth"; |
328 |
Credentials="g5gj262jdw@4df" |
329 |
Connection: C-Man |
330 |
|
331 |
In HTTP/1.1, the C-Man and the C-Opt header field MUST be protected by |
332 |
a Connection header. That is, the header fields are to be included as |
333 |
Connection header directives (see section [7], section 14.10). |
334 |
|
335 |
An agent MUST NOT send the C-Man or the C-Opt header field to an |
336 |
HTTP/1.0 proxy as it does not obey the HTTP/1.1 rules for parsing the |
337 |
Connection header field (see [7]). |
338 |
|
339 |
|
340 |
5. Mandatory HTTP Requests |
341 |
|
342 |
An HTTP request is called a mandatory request if it includes at least |
343 |
one mandatory extension declaration (using the Man or the C-Man header |
344 |
fields). The method name of a mandatory request MUST be prefixed by |
345 |
"M-". For example, a client might express the binding rights- |
346 |
management constraints in an HTTP PUT request as follows: |
347 |
|
348 |
M-PUT /a-resource HTTP/1.1 |
349 |
Man: "http://www.copyright.org/rights-management"; ns=43- |
350 |
43-copyright: http://www.copyright.org/COPYRIGHT.html |
351 |
43-contributions: http://www.copyright.org/PATCHES.html |
352 |
Host: www.w3.org |
353 |
Content-Length: 1203 |
354 |
Content-Type: text/html |
355 |
|
356 |
<!doctype html ... |
357 |
|
358 |
An HTTP server MUST NOT return a 2xx status-code without understanding |
359 |
and obeying all mandatory extension declaration(s) in a mandatory |
360 |
request. A mandatory HTTP request invalidates cached entries as |
361 |
described in [7], section 13.10. |
362 |
|
363 |
The ultimate recipient of a mandatory HTTP request with the "M-" |
364 |
prefix on the method name MUST process the request by performing the |
365 |
following actions in the order they are listed below: |
366 |
|
367 |
1. Identify all mandatory extension declarations (both hop-by-hop |
368 |
and end-to-end); the server MAY ignore optional declarations |
369 |
without affecting the result of the transaction; |
370 |
2. If one or more mandatory extension declarations are present and |
371 |
the following is not true then respond with a 505 (HTTP Version |
372 |
Not Supported): |
373 |
o The request MUST NOT come from a HTTP/1.0 client; and |
374 |
o The request MUST NOT have any HTTP/1.0 clients indicated by |
375 |
the HTTP/1.1 Via header field. |
376 |
|
377 |
Frystyk, et al [Page 6] |
378 |
|
379 |
|
380 |
|
381 |
|
382 |
|
383 |
|
384 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
385 |
|
386 |
3. If 2) is fulfilled then evaluate and process the extensions |
387 |
identified in 1) or if the extension declarations do not match |
388 |
the policy for accessing the resource then respond with a 510 |
389 |
(Not Extended) status-code (see section 8); |
390 |
4. If the evaluation in 3) is successful (not resulting in a 510 |
391 |
(Not Extended) status code) then strip the "M-" prefix from the |
392 |
method name and process the reminder of the request according |
393 |
to the semantics of the existing HTTP/1.1 method name as |
394 |
defined in [7]. |
395 |
5. If one or more mandatory extension declarations were present in |
396 |
the original request and the evaluation in 3) was successful |
397 |
then the server MUST reply by sending a 102 (Extended) followed |
398 |
by a HTTP/1.1 response containing the appropriate HTTP header |
399 |
fields. |
400 |
|
401 |
An "M-" aware proxy that does not act as the ultimate recipient of a |
402 |
mandatory extension declaration MUST NOT remove the declaration or the |
403 |
"M-" method name prefix when forwarding the message. |
404 |
|
405 |
An agent receiving an HTTP/1.0 (or lower-version) message that |
406 |
includes a Connection header MUST, for each connection-token in this |
407 |
field, remove and ignore any header field(s) from the message with the |
408 |
same name as the connection-token. Any "M-" method name prefix |
409 |
introduced as a result of discarded hop-by-hop extensions MUST be |
410 |
ignored and removed by a proxy when forwarding the message. |
411 |
|
412 |
HTTP proxies that do not understand the "M-" method name prefix SHOULD |
413 |
return 501 (Not Implemented) or turn themselves into a tunnel ([7]) in |
414 |
which case they do not take any part in the communication. |
415 |
|
416 |
The "M-" prefix is reserved by this proposal and MUST NOT be used by |
417 |
other HTTP extensions. |
418 |
|
419 |
|
420 |
6. Mandatory HTTP Responses |
421 |
|
422 |
A server SHOULD NOT include mandatory extension declarations in an |
423 |
HTTP response unless it is responding to a mandatory HTTP request. A |
424 |
server MAY include optional extension declarations in any HTTP |
425 |
response (see section 4). |
426 |
|
427 |
If a client receives an HTTP response which contains a Mandatory |
428 |
extension declaration which it does not understand or does not want to |
429 |
use, it SHOULD treat it as if the message was of type |
430 |
"application/octet-stream". |
431 |
|
432 |
|
433 |
7. 102 Extended |
434 |
|
435 |
The server understands and is willing to comply with the client’s |
436 |
extended request using mandatory extension declarations (section 4). |
437 |
The 102 (Extended) response is followed by a normal HTTP/1.1 style |
438 |
|
439 |
Frystyk, et al [Page 7] |
440 |
|
441 |
|
442 |
|
443 |
|
444 |
|
445 |
|
446 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
447 |
|
448 |
response indicating the final status code and parameters of the |
449 |
response. |
450 |
|
451 |
The 102 (Extended) status code prevents that existing HTTP/1.1 servers |
452 |
using non-conformant CGI scripts mistakenly give the false impression |
453 |
that the extended request was fulfilled by responding with a 200 (Ok) |
454 |
response. |
455 |
|
456 |
|
457 |
8. 510 Not Extended |
458 |
|
459 |
The policy for accessing the resource has not been met in the request. |
460 |
The server SHOULD send back all the information necessary for the |
461 |
client to issue an extended request. It is outside the scope of this |
462 |
specification to specify how the extensions inform the client. |
463 |
|
464 |
If the 510 response contains information about extensions that were |
465 |
not present in the initial request then the client MAY repeat the |
466 |
request if it has reason to believe it can fulfill the extension |
467 |
policy by modifying the request according to the information provided |
468 |
in the 510 response. Otherwise the client MAY present any entity |
469 |
included in the 510 response to the user, since that entity may |
470 |
include relevant diagnostic information. |
471 |
|
472 |
|
473 |
|
474 |
|
475 |
|
476 |
|
477 |
9. Publishing an Extension |
478 |
|
479 |
While the protocol extension definition should be published at the |
480 |
address of the extension identifier, this is not a requirement of this |
481 |
specification. The only absolute requirement is that extension |
482 |
identifiers MUST be globally unique identifiers and that distinct |
483 |
names be used for distinct semantics. For example, one way to achieve |
484 |
this is to use a mid, cid[8], or uuid[12] URI. |
485 |
|
486 |
Likewise, applications are not required to attempt resolving extension |
487 |
identifiers included in extension declarations. The only absolute |
488 |
requirement is that an application MUST NOT claim conformance with an |
489 |
extension that it does not recognize regardless of whether it has |
490 |
tried to resolve the extension identifier or not. This document does |
491 |
not provide any policy for how long or how often an application should |
492 |
attempt to resolve an extension identifier. |
493 |
|
494 |
The association between the extension identifier and the specification |
495 |
might be made by distributing a specification, which references the |
496 |
extension identifier. |
497 |
|
498 |
|
499 |
|
500 |
Frystyk, et al [Page 8] |
501 |
|
502 |
|
503 |
|
504 |
|
505 |
|
506 |
|
507 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
508 |
|
509 |
It is strongly recommended that the integrity and persistence of the |
510 |
extension identifier be maintained and kept unquestioned throughout |
511 |
the lifetime of the extension. Care should be taken not to distribute |
512 |
conflicting specifications that reference the same name. Even when an |
513 |
extension specification is made available at the address of the URI, |
514 |
care must be taken that the specification made available at that |
515 |
address does not change significantly over time. One agent may |
516 |
associate the identifier with the old semantics, and another might |
517 |
associate it with the new semantics. |
518 |
|
519 |
The extension definition may be made available in different |
520 |
representations ranging from |
521 |
|
522 |
o a human-readable specification defining the extension semantics, |
523 |
o downloadable code which implements the semantics defined by the |
524 |
extension, |
525 |
o a formal interface description provided by the extension, to |
526 |
o a machine-readable specification defining the extension |
527 |
semantics. |
528 |
|
529 |
For example, a software component that implements the specification |
530 |
may reside at the same address as a human-readable specification |
531 |
(distinguished by content negotiation). The human-readable |
532 |
representation serves to document the extension and encourage |
533 |
deployment, while the software component allows clients and servers to |
534 |
be dynamically extended. |
535 |
|
536 |
|
537 |
10. Security Considerations |
538 |
|
539 |
o Dynamic installation of extension facilities as described in the |
540 |
introduction involves software written by one party (the provider |
541 |
of the implementation) to be executed under the authority of |
542 |
another (the party operating the host software). This opens the |
543 |
host party to a variety of "Trojan horse" attacks by the |
544 |
provider, or a malicious third party that forges implementations |
545 |
under a provider's name. See, for example RFC2046[6], section |
546 |
4.5.2 for a discussion of these risks. |
547 |
|
548 |
11. References |
549 |
|
550 |
[1] D. H. Crocker. "Standard for the Format of ARPA Internet Text |
551 |
Messages", STD 11, RFC 822, UDEL, August 1982 |
552 |
[2] T. Berners-Lee, "Universal Resource Identifiers in WWW. A |
553 |
Unifying Syntax for the Expression of Names and Addresses of |
554 |
Objects on the Network as used in the World-Wide Web", RFC 1630, |
555 |
CERN, June 1994. |
556 |
[3] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource |
557 |
Locators (URL)" RFC 1738, CERN, Xerox PARC, University of |
558 |
Minnesota, December 1994. |
559 |
[4] R. Fielding, "Relative Uniform Resource Locators", RFC 1808, UC |
560 |
Irvine, June 1995. |
561 |
|
562 |
|
563 |
Frystyk, et al [Page 9] |
564 |
|
565 |
|
566 |
|
567 |
|
568 |
|
569 |
|
570 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
571 |
|
572 |
[5] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer |
573 |
Protocol -- HTTP/1.0", RFC 1945, W3C/MIT, UC Irvine, W3C/MIT, May |
574 |
1996. |
575 |
[6] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions |
576 |
(MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual, |
577 |
November 1996. |
578 |
[7] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, |
579 |
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, U.C. Irvine, |
580 |
DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997 |
581 |
[8] E. Levinson, "Content-ID and Message-ID Uniform Resource |
582 |
Locators", RFC 2111, March 1997 |
583 |
[9] S. Bradner, "Key words for use in RFCs to Indicate Requirement |
584 |
Levels", RFC 2119, Harvard University, March 1997 |
585 |
[10] Y. Y. Goland et al, "Extensions for Distributed Authoring and |
586 |
Versioning", Internet Draft, draft-jensen-webdav-ext-01, 26 March |
587 |
1997. This is work in progress. |
588 |
[11] H. F. Nielsen, D. Connolly, R. Khare, "PEP - an extension |
589 |
mechanism for HTTP", draft-http-pep-05.txt, November 21, 1997 |
590 |
[12] Charlie Kindel, "The uuid: URI scheme", draft-kindel-uuid-uri- |
591 |
00.txt, November, 24 1997. This is work in progress |
592 |
|
593 |
12. Acknowledgements |
594 |
|
595 |
Rohit Khare deserves special recognition for his efforts in commenting |
596 |
in the design phase of the protocol. Also thanks to Josh Cohen, Ross |
597 |
Patterson, Jim Gettys and all the people who have been involved in |
598 |
PEP. |
599 |
|
600 |
|
601 |
13. Authors Addresses |
602 |
|
603 |
Henrik Frystyk Nielsen |
604 |
Technical Staff, World Wide Web Consortium |
605 |
MIT Laboratory for Computer Science |
606 |
545 Technology Square |
607 |
Cambridge, MA 02139, USA |
608 |
Email: frystyk@w3.org |
609 |
|
610 |
Paul J. Leach |
611 |
Microsoft Corporation |
612 |
1 Microsoft Way |
613 |
Redmond, WA 98052, USA |
614 |
Email: paulle@microsoft.com |
615 |
|
616 |
Scott Lawrence |
617 |
Agranat Systems, Inc. |
618 |
1345 Main Street |
619 |
Waltham, MA 02154, USA |
620 |
Email: lawrence@agranat.com |
621 |
|
622 |
|
623 |
|
624 |
Frystyk, et al [Page 10] |
625 |
|
626 |
|
627 |
|
628 |
|
629 |
|
630 |
|
631 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
632 |
|
633 |
Appendices |
634 |
|
635 |
|
636 |
14. Summary of Protocol Interactions |
637 |
|
638 |
The following tables summarize the outcome of strength and scope rules |
639 |
of the mandatory proposal of compliant and non-compliant HTTP proxies |
640 |
and origin servers. The summary is intended as a guide and index to |
641 |
the text, but is necessarily cryptic and incomplete. This summary |
642 |
should never be used or referenced separately from the complete |
643 |
specification. |
644 |
|
645 |
|
646 |
Table 1: Origin Server |
647 |
|
648 |
Scope Hop-by-hop End-to-end |
649 |
|
650 |
Strength Optional Required Optional Required |
651 |
(may) (must) (may) (must) |
652 |
|
653 |
Mandatory Standard 501 (Not Standard 501 (Not |
654 |
unsupported processing Implemented)processing Implemented) |
655 |
|
656 |
Extension Standard 510 (Not Standard 510 (Not |
657 |
unsupported processing Extended) processing Extended) |
658 |
|
659 |
Extension Extended Extended Extended Extended |
660 |
supported processing processing processing processing |
661 |
|
662 |
|
663 |
Table 2: Proxy Server |
664 |
|
665 |
Scope Hop-by-hop End-to-end |
666 |
|
667 |
Strength Optional Required Optional Required |
668 |
(may) (must) (may) (must) |
669 |
|
670 |
Mandatory Strip 501 (Not Forward 501 (Not |
671 |
unsupported extension Implemented)extension Implemented) |
672 |
or tunnel or tunnel |
673 |
|
674 |
Extension Strip 510 (Not Forward Forward |
675 |
unsupported extension Extended) extension extension |
676 |
|
677 |
Extension Extended Extended Extended Extended |
678 |
supported processing processing processing, processing, |
679 |
and strip and strip may strip may strip |
680 |
|
681 |
|
682 |
15. Examples |
683 |
|
684 |
The following examples show various scenarios using mandatory in |
685 |
HTTP/1.1 requests and responses. Information not essential for |
686 |
illustrating the examples is left out (referred to as "…") |
687 |
|
688 |
|
689 |
|
690 |
|
691 |
|
692 |
Frystyk, et al [Page 11] |
693 |
|
694 |
|
695 |
|
696 |
|
697 |
|
698 |
|
699 |
INTERNET-DRAFT Mandatory Friday, August 07, 1998 |
700 |
|
701 |
15.1 Client Requests Server to use an Extension |
702 |
|
703 |
In this example, the client requires that the server supports and uses |
704 |
the extension identified by the URI " |
705 |
http://www.distributed.org/some.extension". By making the request |
706 |
mandatory (see section 5), the client forces the server to process the |
707 |
extension declaration and obey the extension or report an error. |
708 |
|
709 |
M-GET /some.url HTTP/1.1 |
710 |
Host: some.host |
711 |
Man: "http://www.distributed.org/some.extension" |
712 |
... |
713 |
|
714 |
HTTP/1.1 102 Extended |
715 |
|
716 |
HTTP/1.1 200 OK |
717 |
... |
718 |
|
719 |
The response shows that the server does understand the requested |
720 |
extension. |
721 |
|
722 |
|
723 |
15.2 Server proposes the use of an Extension |
724 |
|
725 |
By including an optional extension declaration in the response, the |
726 |
server indicates that the response has been extended but that it is OK |
727 |
if the client ignores the extension: |
728 |
|
729 |
GET /Index HTTP/1.1 |
730 |
Host: some.host |
731 |
|
732 |
HTTP/1.1 200 OK |
733 |
Opt: "http://www.cache.com/cache-index", ns=23- |
734 |
23-index: "http://some.host/index" |
735 |
... |
736 |
|
737 |
The server has no direct mechanism of knowing whether the client |
738 |
accepted and used the optional extension declaration. |
739 |
|
740 |
|
741 |
|
742 |
|
743 |
|
744 |
|
745 |
|
746 |
|
747 |
|
748 |
|
749 |
|
750 |
|
751 |
|
752 |
|
753 |
|
754 |
|
755 |
Frystyk, et al [Page 12] |