1 |
|
2 |
|
3 |
HTTP Working Group J. Mogul, DECWRL, |
4 |
Internet-Draft J. Cohen, Netscape, |
5 |
Expires: 28 February 1998 S. Lawrence, Agranat Systems |
6 |
26 August 1997 |
7 |
|
8 |
Specification of HTTP/1.1 OPTIONS messages |
9 |
|
10 |
draft-ietf-http-options-02.txt |
11 |
|
12 |
|
13 |
STATUS OF THIS MEMO |
14 |
|
15 |
This document is an Internet-Draft. Internet-Drafts are |
16 |
working documents of the Internet Engineering Task Force |
17 |
(IETF), its areas, and its working groups. Note that other |
18 |
groups may also distribute working documents as |
19 |
Internet-Drafts. |
20 |
|
21 |
Internet-Drafts are draft documents valid for a maximum of |
22 |
six months and may be updated, replaced, or obsoleted by |
23 |
other documents at any time. It is inappropriate to use |
24 |
Internet-Drafts as reference material or to cite them other |
25 |
than as "work in progress." |
26 |
|
27 |
To learn the current status of any Internet-Draft, please |
28 |
check the "1id-abstracts.txt" listing contained in the |
29 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
30 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
31 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
32 |
West Coast). |
33 |
|
34 |
Distribution of this document is unlimited. Please send |
35 |
comments to the HTTP working group at |
36 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
37 |
group are archived at |
38 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
39 |
discussions about HTTP and the applications which use HTTP |
40 |
should take place on the <www-talk@w3.org> mailing list. |
41 |
|
42 |
|
43 |
ABSTRACT |
44 |
|
45 |
RFC2068 defined a new OPTIONS method for HTTP/1.1. The |
46 |
purpose of OPTIONS is to allow a 'client to determine the |
47 |
options and/or requirements associated with a resource, or |
48 |
the capabilities of a server, without implying a resource |
49 |
action or initiating a resource retrieval.' However, |
50 |
RFC2068 did not defined a specific syntax for using OPTIONS |
51 |
to make such a determination. This proposal clarifies the |
52 |
original specification of OPTIONS, adds several new HTTP |
53 |
message headers to provide syntactic support for OPTIONS, |
54 |
and establishes new IANA registries to avoid namespace |
55 |
conflicts. |
56 |
|
57 |
|
58 |
Mogul, Cohen, Lawrence [Page 1] |
59 |
|
60 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
61 |
|
62 |
|
63 |
TABLE OF CONTENTS |
64 |
|
65 |
1 Introduction 2 |
66 |
2 Outline of proposed solution 2 |
67 |
3 Proposed solution 3 |
68 |
3.1 Changes to section 5.1.2, Request-URI 3 |
69 |
3.2 Changes to section 9.2, OPTIONS 4 |
70 |
3.3 Changes to section 14.31, Max-Forwards 6 |
71 |
3.4 The Compliance header 6 |
72 |
3.5 The Non-Compliance header 9 |
73 |
3.6 Changes to sections 14.7 and 14.35, Allow and Public 10 |
74 |
3.6.1 Alternative A: proxies MUST NOT modify Allow/Public 11 |
75 |
3.6.2 Alternative B: proxies MUST modify Allow/Public 12 |
76 |
3.7 Examples 12 |
77 |
4 Security Considerations 13 |
78 |
5 Acknowledgements 13 |
79 |
6 References 13 |
80 |
7 Authors' addresses 14 |
81 |
|
82 |
|
83 |
1 Introduction |
84 |
|
85 |
Section 9.2 of RFC2068 [2] defines an OPTIONS method, to allow a |
86 |
"client to determine the options and/or requirements associated with |
87 |
a resource, or the capabilities of a server, without implying a |
88 |
resource action or initiating a resource retrieval." For example, a |
89 |
client may wish to determine if a particular HTTP method is supported |
90 |
by a server, or for a specific resource. Or, a client may wish to |
91 |
determine if a server supports the use of a particular HTTP |
92 |
request-header. |
93 |
|
94 |
The description of OPTIONS in RFC2068 has left some implementors |
95 |
confused about what is required, and does not provide a specific |
96 |
syntax for determining support for specific options or extensions. |
97 |
While some of this might be obviated in the future by the Protocol |
98 |
Extension Protocol (PEP) [1], there exists an immediate need to |
99 |
define a simple and well-specified OPTIONS mechanism for HTTP/1.1. |
100 |
|
101 |
|
102 |
2 Outline of proposed solution |
103 |
|
104 |
- The intended recipient of an OPTIONS request may be any |
105 |
server (including proxies) along the request path. RFC2068 |
106 |
supported this by requiring a transformation of the |
107 |
request-URI for a set of methods (actually, only for |
108 |
OPTIONS); in the current proposal, one can either use the |
109 |
Host header to address a specific server or proxy, or the |
110 |
Max-Forwards header to address the Nth server on a path. |
111 |
|
112 |
- As in RFC2068, the URI '*' refers to the server, |
113 |
independent of any specific resource. Any other URI refers |
114 |
to the resource normally identified by that URI. |
115 |
Mogul, Cohen, Lawrence [Page 2] |
116 |
|
117 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
118 |
|
119 |
|
120 |
- The descriptions of the Allow and Public headers, and of |
121 |
the OPTIONS method, are made consistent in their |
122 |
requirements for proxy editing of OPTIONS responses. (In |
123 |
RFC2068, these sections were contradictory). |
124 |
|
125 |
- A (new) Compliance header is proposed, which allows a |
126 |
client to specify exactly what options it is asking about, |
127 |
and which allows a server to specify exactly what subset of |
128 |
those options are supported. |
129 |
|
130 |
Discussion question: it might make more sense to use two |
131 |
different header names, one for requests and one for |
132 |
responses, to clarify that in a request, the client |
133 |
is asking the server about its supported options, and |
134 |
in a response, the server is stating its supported |
135 |
options. |
136 |
|
137 |
- The Compliance header allows several namespaces for |
138 |
options; the set of namespaces is under IANA control. One |
139 |
namespace is that of IETF-issued RFCs; this allows a more |
140 |
specific definition of compliance than is available using |
141 |
protocol version numbers. While various interpretations |
142 |
can and do exist about the specific meaning of a protocol |
143 |
version number (such as "HTTP/1.1"), the meaning of an RFC |
144 |
is both well-defined and (more important) immutable. |
145 |
|
146 |
- A (new) Non-Compliance header is proposed, allowing a proxy |
147 |
processing an OPTIONS response to indicate its |
148 |
non-compliance with one or more options, and without |
149 |
requiring the proxy to edit the rest of the response (which |
150 |
would result in loss of information). |
151 |
|
152 |
|
153 |
3 Proposed solution |
154 |
|
155 |
Here we propose specific changes to RFC2068. |
156 |
|
157 |
3.1 Changes to section 5.1.2, Request-URI |
158 |
Remove this: |
159 |
|
160 |
|
161 |
|
162 |
|
163 |
|
164 |
|
165 |
|
166 |
|
167 |
|
168 |
|
169 |
|
170 |
|
171 |
|
172 |
Mogul, Cohen, Lawrence [Page 3] |
173 |
|
174 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
175 |
|
176 |
|
177 |
If a proxy receives a request without any path in the Request-URI |
178 |
and the method specified is capable of supporting the asterisk form |
179 |
of request, then the last proxy on the request chain MUST forward |
180 |
the request with "*" as the final Request-URI. For example, the |
181 |
request |
182 |
|
183 |
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 |
184 |
|
185 |
would be forwarded by the proxy as |
186 |
|
187 |
OPTIONS * HTTP/1.1 |
188 |
Host: www.ics.uci.edu:8001 |
189 |
|
190 |
after connecting to port 8001 of host "www.ics.uci.edu". |
191 |
|
192 |
3.2 Changes to section 9.2, OPTIONS |
193 |
Replace: |
194 |
|
195 |
Unless the server's response is an error, the response MUST NOT |
196 |
include entity information other than what can be considered as |
197 |
communication options (e.g., Allow is appropriate, but Content-Type |
198 |
is not). Responses to this method are not cachable. |
199 |
|
200 |
with: |
201 |
|
202 |
An OPTIONS request MAY include Compliance headers (see section |
203 |
14.ZZZ) that indicate the set of options the sender wants |
204 |
information about. |
205 |
|
206 |
Responses to OPTIONS are not cachable, unless caching is explicitly |
207 |
allowed by the server that first sent the OPTIONS reply (see section |
208 |
13.4). |
209 |
|
210 |
Replace: |
211 |
|
212 |
If the Request-URI is an asterisk ("*"), the OPTIONS request is |
213 |
intended to apply to the server as a whole. A 200 response SHOULD |
214 |
include any header fields which indicate optional features |
215 |
implemented by the server (e.g., Public), including any extensions |
216 |
not defined by this specification, in addition to any applicable |
217 |
general or response-header fields. As described in section 5.1.2, an |
218 |
"OPTIONS *" request can be applied through a proxy by specifying the |
219 |
destination server in the Request-URI without any path information. |
220 |
|
221 |
with: |
222 |
|
223 |
|
224 |
|
225 |
|
226 |
|
227 |
|
228 |
|
229 |
Mogul, Cohen, Lawrence [Page 4] |
230 |
|
231 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
232 |
|
233 |
|
234 |
If the Request-URI is an asterisk ("*"), the OPTIONS request is |
235 |
intended to apply to the server as a whole. A 200 response SHOULD |
236 |
include a Public header field (see section 14.35). If the request |
237 |
includes a Compliance header field, a 200 response SHOULD include a |
238 |
Compliance header field, indicating the subset of the requested |
239 |
Compliance options supported by the server as a whole. The response |
240 |
SHOULD include any other applicable general or response-header |
241 |
fields. |
242 |
|
243 |
If an OPTIONS request includes a Host header (see section 14.23), |
244 |
this is the intended destination of the OPTIONS method. |
245 |
Proxy servers MUST forward such a message until it reaches |
246 |
the specified host. If the specified host has more than |
247 |
one `virtual server', the OPTIONS request applies to the |
248 |
specified virtual server. |
249 |
|
250 |
Note: An OPTIONS request may also include a Max-Forwards header, |
251 |
as described in section 14.31. This allows the sender to select |
252 |
the Nth proxy on a path, without knowing its hostname. |
253 |
|
254 |
Replace: |
255 |
|
256 |
If the Request-URI is not an asterisk, the OPTIONS request applies |
257 |
only to the options that are available when communicating with that |
258 |
resource. A 200 response SHOULD include any header fields which |
259 |
indicate optional features implemented by the server and applicable |
260 |
to that resource (e.g., Allow), including any extensions not defined |
261 |
by this specification, in addition to any applicable general or |
262 |
response-header fields. If the OPTIONS request passes through a |
263 |
proxy, the proxy MUST edit the response to exclude those options |
264 |
which apply to a proxy's capabilities and which are known to be |
265 |
unavailable through that proxy. |
266 |
|
267 |
with: |
268 |
|
269 |
|
270 |
|
271 |
|
272 |
|
273 |
|
274 |
|
275 |
|
276 |
|
277 |
|
278 |
|
279 |
|
280 |
|
281 |
|
282 |
|
283 |
|
284 |
|
285 |
|
286 |
Mogul, Cohen, Lawrence [Page 5] |
287 |
|
288 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
289 |
|
290 |
|
291 |
If the Request-URI is not an asterisk, the OPTIONS request applies |
292 |
only to the options that are available when communicating with that |
293 |
resource. A 200 response SHOULD include an Allow header field (see |
294 |
section 14.7). If the request includes a Compliance header field, a |
295 |
200 response SHOULD include a Compliance header field, indicating |
296 |
the subset of the requested Compliance options supported by the |
297 |
server as a whole. If the subset is empty, the response SHOULD |
298 |
include a Compliance header with an empty field-value. The response |
299 |
SHOULD include any other applicable general or response-header |
300 |
fields. |
301 |
|
302 |
Note: if an OPTION request contains a Compliance header, and the |
303 |
response does not, the response may have been generated by |
304 |
RFC2068-compliant implementation, which would not support |
305 |
Compliance. In this case, it is not possible to infer that the |
306 |
sender fails to support all of the options listed in the |
307 |
Compliance header of the request. |
308 |
|
309 |
If the OPTIONS request passes through a |
310 |
proxy, the proxy SHOULD add a Non-Compliance header field (see |
311 |
section 14.QQQ) to the response, to list those options that apply to |
312 |
a proxy's capabilities and that are known to be unavailable through |
313 |
that proxy. |
314 |
|
315 |
3.3 Changes to section 14.31, Max-Forwards |
316 |
Replace: |
317 |
|
318 |
Each proxy or gateway recipient of a TRACE request containing a Max- |
319 |
Forwards header field SHOULD check and update its value prior to |
320 |
forwarding the request. |
321 |
|
322 |
with: |
323 |
|
324 |
Each proxy or gateway recipient of a TRACE or OPTIONS request |
325 |
containing a Max-Forwards header field SHOULD check and update its |
326 |
value prior to forwarding the request. |
327 |
|
328 |
3.4 The Compliance header |
329 |
Insert in section 14, as a new subsection titled ``14.ZZZ |
330 |
Compliance'' |
331 |
|
332 |
|
333 |
|
334 |
|
335 |
|
336 |
|
337 |
|
338 |
|
339 |
|
340 |
|
341 |
|
342 |
|
343 |
Mogul, Cohen, Lawrence [Page 6] |
344 |
|
345 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
346 |
|
347 |
|
348 |
The Compliance general header field lists a set of options |
349 |
that may or may not be supported by a server. In a request |
350 |
message, this header lists the set of options that a client |
351 |
wishes to know about. In a response message, this header |
352 |
lists the subset of the requested options that the server |
353 |
complies with. |
354 |
|
355 |
A compliance header MAY appear on any message, but is |
356 |
normally used with the OPTIONS request (see section 9.2). |
357 |
|
358 |
Compliance = "Compliance" ":" ("*" | #(compliance-option)) |
359 |
|
360 |
compliance-option = compliance-namespace "=" |
361 |
option-item [ option-params ] |
362 |
|
363 |
compliance-namespace = token |
364 |
|
365 |
option-item = token | quoted-string |
366 |
| rfc-option-item | hdr-option-item |
367 |
|
368 |
option-params = 1*( ";" option-param) |
369 |
|
370 |
option-param = "cond" | "uncond" | token | quoted-string |
371 |
|
372 |
A Compliance header field with the field-value of "*" MAY |
373 |
be used in a request, to ask about all options complied |
374 |
with by the recipient. This field-value MUST NOT be used |
375 |
in a response. |
376 |
|
377 |
When the Compliance header is present in a response, it takes |
378 |
priority over an Allow header or a Public header in the same |
379 |
response. |
380 |
|
381 |
Tokens used for compliance-namespace, option-item, and |
382 |
option-param values are case-insensitive. |
383 |
|
384 |
The compliance-namespace is used to select from one of several |
385 |
namespaces for compliance options. The option-item is used |
386 |
to specify one or more options within a namespace. |
387 |
|
388 |
|
389 |
|
390 |
|
391 |
|
392 |
|
393 |
|
394 |
|
395 |
|
396 |
|
397 |
|
398 |
|
399 |
|
400 |
Mogul, Cohen, Lawrence [Page 7] |
401 |
|
402 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
403 |
|
404 |
|
405 |
The Internet Assigned Numbers Authority (IANA) acts as a registry |
406 |
for compliance-namespace tokens. Initially, the registry contains |
407 |
the following tokens: |
408 |
|
409 |
"RFC" Compliance is with an RFC, specified by an RFC number. |
410 |
For example, "rfc=1945". |
411 |
|
412 |
rfc-option-item = "RFC" "=" RFC-number |
413 |
RFC-number = 1*DIGIT |
414 |
|
415 |
Leading zeroes are permitted and ignored in |
416 |
RFC-number (i.e., comparisons are numeric). |
417 |
|
418 |
"HDR" Compliance is with a named HTTP header. For example, |
419 |
"HDR=Authorization". There is no IANA registry for |
420 |
HTTP header names, but to avoid potential namespace |
421 |
confusion, only those HTTP headers listed in an |
422 |
IETF standards-track document should be used in |
423 |
this namespace. |
424 |
|
425 |
hdr-option-item = "HDR" "=" field-name |
426 |
|
427 |
An implementation SHOULD NOT send option-param values other |
428 |
than "cond" or "uncond" with an rfc-option-item or a |
429 |
hdr-option-item. |
430 |
|
431 |
The option-param is used to provide additional parameters. |
432 |
Unconditional compliance with a compliance-option is indicated |
433 |
using the "uncond" option-param; for example, "rfc=1945;uncond". |
434 |
Conditional compliance is indicated using the "cond" option-param; |
435 |
for example, "HDR=Authorization;uncond". Additional option-param |
436 |
values might be defined as part of another specification. |
437 |
|
438 |
For the purposes of this header field, an implementation that |
439 |
satisfies all the MUST and all the SHOULD requirements for its |
440 |
protocols is defined as "unconditionally compliant"; one that |
441 |
satisfies all the MUST requirements but not all the SHOULD |
442 |
requirements for its protocols is defined as "conditionally |
443 |
compliant." See also RFC2119 for a discussion of the terms MUST |
444 |
and SHOULD. |
445 |
|
446 |
Examples: |
447 |
|
448 |
Compliance: rfc=2068;uncond |
449 |
Compliance: rfc=1945;uncond, rfc=2068;cond |
450 |
Compliance: rfc=2068, hdr=SetCookie2 |
451 |
|
452 |
|
453 |
|
454 |
|
455 |
|
456 |
|
457 |
Mogul, Cohen, Lawrence [Page 8] |
458 |
|
459 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
460 |
|
461 |
|
462 |
Note: when a resource is implemented using a subprogram |
463 |
outside the control of the server itself (such as a CGI |
464 |
application), and the server cannot ensure that this |
465 |
implementation of the resource will comply with a requested |
466 |
option, the server's Compliance response-header for the |
467 |
resource ought not to assert compliance with the option. |
468 |
That is, in case of uncertainty, it is better to imply |
469 |
non-compliance when the implementation might comply, than |
470 |
to claim compliance when the implementation might not comply. |
471 |
|
472 |
3.5 The Non-Compliance header |
473 |
Insert in section 14, as a new subsection titled ``14.QQQ |
474 |
Non-Compliance'' |
475 |
|
476 |
A proxy server SHOULD add this response-header to a response |
477 |
containing a Compliance header if the proxy does not implement one |
478 |
or more of the options described in the Compliance header. |
479 |
|
480 |
Non-Compliance = "Non-Compliance" ":" 1#non-compliance-option |
481 |
|
482 |
proxy-host = host [ ":" port ] |
483 |
|
484 |
non-compliance-option = compliance-option "@" proxy-host |
485 |
|
486 |
|
487 |
|
488 |
|
489 |
|
490 |
|
491 |
|
492 |
|
493 |
|
494 |
|
495 |
|
496 |
|
497 |
|
498 |
|
499 |
|
500 |
|
501 |
|
502 |
|
503 |
|
504 |
|
505 |
|
506 |
|
507 |
|
508 |
|
509 |
|
510 |
|
511 |
|
512 |
|
513 |
|
514 |
Mogul, Cohen, Lawrence [Page 9] |
515 |
|
516 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
517 |
|
518 |
|
519 |
A non-compliance-option listed in a Non-Compliance response-header |
520 |
field indicates that the proxy server named by the proxy-host value |
521 |
does not support the listed compliance-option. The set of |
522 |
non-compliance options SHOULD be a subset of the compliance-options |
523 |
listed in a Compliance header field of the forwarded message. |
524 |
|
525 |
Note: because the proxy-host value is not authenticated, |
526 |
this is only for advisory purposes (e.g., for debugging). |
527 |
|
528 |
If the compliance-option in a non-compliance-option includes one or |
529 |
more option-param(s) (see section 14.ZZZ), then the proxy server's |
530 |
non-compliance is limited to the scope of the option-param(s). If |
531 |
the compliance-option does not include an option-param, then the |
532 |
proxy server is asserting non-compliance with the option in |
533 |
general. |
534 |
|
535 |
For example, a response with: |
536 |
|
537 |
Compliance: rfc=9999;uncond |
538 |
Non-Compliance: rfc=9999;uncond@proxy.foo.net |
539 |
|
540 |
states that proxy.foo.net is not unconditionally compliant with |
541 |
RFC9999, but does not imply that proxy.foo.net is not |
542 |
conditionally compliant with RFC9999. If the proxy is not even |
543 |
conditionally compliant with RFC9999, it should instead send |
544 |
|
545 |
Compliance: rfc=9999;uncond |
546 |
Non-Compliance: rfc=9999@proxy.foo.net |
547 |
|
548 |
when forwarding the response. |
549 |
|
550 |
A proxy MUST NOT delete a Non-Compliance header that it has |
551 |
received from another server. |
552 |
|
553 |
3.6 Changes to sections 14.7 and 14.35, Allow and Public |
554 |
The problem we address here is that RFC2068's specifications for the |
555 |
Allow and Public headers are inconsistent as to whether a proxy |
556 |
"MUST" or "MUST NOT" edit them. We believe that they should be |
557 |
consistent. Given that, there are arguments for either alternative: |
558 |
|
559 |
- Requiring proxies to edit these headers provides the |
560 |
ultimate client with a simple way to determine if a method |
561 |
is allowed along the entire path to the origin server. |
562 |
|
563 |
- However, requiring proxies not to edit these headers allows |
564 |
a client to find out about the capabilities of the origin |
565 |
server, since (as RFC2068 says about the Allow header) "the |
566 |
user agent may have other means of communicating with the |
567 |
origin server." |
568 |
|
569 |
The second alternative seems more robust. Although we do not |
570 |
|
571 |
Mogul, Cohen, Lawrence [Page 10] |
572 |
|
573 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
574 |
|
575 |
|
576 |
currently have an efficient mechanism for finding out if a method is |
577 |
supported along the entire path, presumbly any request using an |
578 |
unsupported method would immediately be rejected. However, we list |
579 |
both alternatives in the hope that further discussion will lead to a |
580 |
more satisfying solution. |
581 |
|
582 |
Note: one possibility, not yet explored in detail, is that the |
583 |
compliance-namespace could be extended to include a "METH" |
584 |
token, allowing the Compliance header (and hence the |
585 |
Non-Compliance header) to completely replace the Allow and |
586 |
Public headers. E.g., the client could send |
587 |
|
588 |
Compliance: METH=* |
589 |
|
590 |
to which the origin server might respond |
591 |
|
592 |
Compliance: METH=GET,METH=PUT,METH=HEAD |
593 |
|
594 |
If this passes through a proxy that bans (e.g.) PUT, the proxy |
595 |
could forward the response as |
596 |
|
597 |
Compliance: METH=GET,METH=PUT,METH=HEAD |
598 |
Non-Compliance: METH=PUT@roproxy.net |
599 |
|
600 |
3.6.1 Alternative A: proxies MUST NOT modify Allow/Public |
601 |
In section 14.35 (Public), replace |
602 |
|
603 |
This header field applies only to the server directly connected to |
604 |
the client (i.e., the nearest neighbor in a chain of connections). |
605 |
If the response passes through a proxy, the proxy MUST either remove |
606 |
the Public header field or replace it with one applicable to its own |
607 |
capabilities. |
608 |
|
609 |
with: |
610 |
|
611 |
A proxy MUST NOT modify the Public header field even if it does not |
612 |
understand all the methods specified, since the user agent might |
613 |
have other means of communicating with the origin server. |
614 |
|
615 |
Also, in section 14.7 (Allow), replace |
616 |
|
617 |
A proxy MUST NOT modify the Allow header field even if it does not |
618 |
understand all the methods specified, since the user agent MAY have |
619 |
other means of communicating with the origin server. |
620 |
|
621 |
with: |
622 |
|
623 |
A proxy MUST NOT modify the Allow header field even if it does not |
624 |
understand all the methods specified, since the user agent might |
625 |
have other means of communicating with the origin server. |
626 |
|
627 |
(removes an incorrect use of the term "MAY"). |
628 |
Mogul, Cohen, Lawrence [Page 11] |
629 |
|
630 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
631 |
|
632 |
|
633 |
3.6.2 Alternative B: proxies MUST modify Allow/Public |
634 |
In section 14.7 (Allow), replace |
635 |
|
636 |
A proxy MUST NOT modify the Allow header field even if it does not |
637 |
understand all the methods specified, since the user agent MAY have |
638 |
other means of communicating with the origin server. |
639 |
|
640 |
with: |
641 |
|
642 |
A proxy MUST remove methods from an Allow header field if it |
643 |
does not support the use of those methods for the resource |
644 |
identified by the Request-URI. |
645 |
|
646 |
and in section 14.35 (Public), replace this paragraph: |
647 |
|
648 |
This header field applies only to the server directly connected to |
649 |
the client (i.e., the nearest neighbor in a chain of connections). |
650 |
If the response passes through a proxy, the proxy MUST either remove |
651 |
the Public header field or replace it with one applicable to its own |
652 |
capabilities. |
653 |
|
654 |
with: |
655 |
|
656 |
A proxy MUST remove methods from a Public header field if it |
657 |
does not support the use of those methods. |
658 |
|
659 |
3.7 Examples |
660 |
|
661 |
To list all extensions supported by proxy "proxy4.example.com" |
662 |
|
663 |
Client sends: |
664 |
OPTIONS * HTTP/1.1 |
665 |
Host: proxy4.example.com |
666 |
Compliance: * |
667 |
|
668 |
proxy4.example.com responds: |
669 |
HTTP/1.1 200 OK |
670 |
Date: Tue, 22 Jul 1997 20:21:51 GMT |
671 |
Server: SuperProxy/1.0 |
672 |
Public: OPTIONS, GET, HEAD, PUT, POST, TRACE |
673 |
Compliance: rfc=1543, rfc=2068, hdr=set-proxy |
674 |
Compliance: hdr=wonder-bar-http-widget-set |
675 |
Content-Length: 0 |
676 |
|
677 |
|
678 |
|
679 |
|
680 |
|
681 |
|
682 |
|
683 |
|
684 |
|
685 |
Mogul, Cohen, Lawrence [Page 12] |
686 |
|
687 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
688 |
|
689 |
|
690 |
Probing for a feature which is not supported by |
691 |
"proxy4.example.com" |
692 |
|
693 |
Client sends: |
694 |
OPTIONS * HTTP/1.1 |
695 |
Host: proxy4.example.com |
696 |
Compliance: HDR=TimeTravel |
697 |
|
698 |
proxy4.example.com responds: |
699 |
HTTP/1.1 200 OK |
700 |
Date: Tue, 22 Jul 1997 20:21:52 GMT |
701 |
Server: SuperProxy/1.0 |
702 |
Public: OPTIONS, GET, HEAD, PUT, POST, TRACE |
703 |
Compliance: |
704 |
Content-Length: 0 |
705 |
|
706 |
|
707 |
4 Security Considerations |
708 |
|
709 |
Because the proxy-host value in a Non-Compliance header is not |
710 |
authenticated, in theory, a malicious proxy along the path could |
711 |
insert a Non-Compliance header with the name of some other proxy, |
712 |
perhaps one not even involved in the response. However, because the |
713 |
proxy-host value is used only for advisory purposes (e.g., for |
714 |
debugging), there does not appear to be a serious security problem |
715 |
with this lack of authentication. |
716 |
|
717 |
Besides, any proxy along the request/response path for an HTTP |
718 |
interaction is able to perform far more disruptive (and far less |
719 |
easily detected) modifications of the messages it forwards; this |
720 |
proposal does not change that. |
721 |
|
722 |
|
723 |
5 Acknowledgements |
724 |
|
725 |
We would like to thank Roy Fielding, Jim Gettys, Paul Leach, Larry |
726 |
Masinter, Henrik Frystyk Nielsen, Ross Patterson, and Jim Whitehead |
727 |
for help in constructing this proposal. |
728 |
|
729 |
|
730 |
6 References |
731 |
|
732 |
1. D. Connolly, R. Khare, H. Frystyk Nielsen. PEP - an Extension |
733 |
Mechanism for HTTP. Internet Draft draft-ietf-http-pep-04, HTTP |
734 |
Working Group, July, 1997. This is a work in progress. |
735 |
|
736 |
2. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk |
737 |
Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol -- |
738 |
HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997. |
739 |
|
740 |
|
741 |
|
742 |
Mogul, Cohen, Lawrence [Page 13] |
743 |
|
744 |
Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 |
745 |
|
746 |
|
747 |
7 Authors' addresses |
748 |
|
749 |
Jeffrey C. Mogul |
750 |
Western Research Laboratory |
751 |
Digital Equipment Corporation |
752 |
250 University Avenue |
753 |
Palo Alto, California, 94305, USA |
754 |
Email: mogul@wrl.dec.com |
755 |
|
756 |
Josh Cohen |
757 |
Netscape Communications Corporation |
758 |
501 E. Middlefield Rd |
759 |
Mountain View, CA 94043 |
760 |
Phone (415) 937-4157 |
761 |
EMail: josh@netscape.com |
762 |
|
763 |
Scott Lawrence |
764 |
Agranat Systems, Inc. |
765 |
1345 Main St. |
766 |
Waltham, MA 02154 |
767 |
Phone: +1-617-893-7868 |
768 |
Fax: +1-617-893-5740 |
769 |
Email: lawrence@agranat.com |
770 |
|
771 |
|
772 |
|
773 |
|
774 |
|
775 |
|
776 |
|
777 |
|
778 |
|
779 |
|
780 |
|
781 |
|
782 |
|
783 |
|
784 |
|
785 |
|
786 |
|
787 |
|
788 |
|
789 |
|
790 |
|
791 |
|
792 |
|
793 |
|
794 |
|
795 |
|
796 |
|
797 |
|
798 |
|
799 |
Mogul, Cohen, Lawrence [Page 14] |