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