1 |
|
2 |
|
3 |
HTTP Working Group J. Mogul, DECWRL, |
4 |
Internet-Draft J. Cohen, Netscape, |
5 |
Expires: 30 January 1997 S. Lawrence, Agranat Systems |
6 |
28 July 1997 |
7 |
|
8 |
Specification of HTTP/1.1 OPTIONS messages |
9 |
|
10 |
draft-ietf-http-options-00.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 28 July 1997 13:43 |
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 5 |
71 |
3.4 The Compliance header 6 |
72 |
3.5 The Non-Compliance header 7 |
73 |
3.6 Changes to sections 14.7 and 14.35, Allow and Public 8 |
74 |
3.6.1 Alternative A: proxies MUST NOT modify Allow/Public 9 |
75 |
3.6.2 Alternative B: proxies MUST modify Allow/Public 9 |
76 |
3.7 Examples 10 |
77 |
4 Security Considerations 10 |
78 |
5 Acknowledgements 11 |
79 |
6 References 11 |
80 |
7 Authors' addresses 11 |
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 28 July 1997 13:43 |
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 |
- The Compliance header allows several namespaces for |
131 |
options; the set of namespaces is under IANA control. One |
132 |
namespace is that of IETF-issued RFCs; this allows a more |
133 |
specific definition of compliance than is available using |
134 |
protocol version numbers. While various interpretations |
135 |
can and do exist about the specific meaning of a protocol |
136 |
version number (such as "HTTP/1.1"), the meaning of an RFC |
137 |
is both well-defined and (more important) immutable. |
138 |
|
139 |
- A (new) Non-Compliance header is proposed, allowing a proxy |
140 |
processing an OPTIONS response to indicate its |
141 |
non-compliance with one or more options, and without |
142 |
requiring the proxy to edit the rest of the response (which |
143 |
would result in loss of information). |
144 |
|
145 |
|
146 |
3 Proposed solution |
147 |
|
148 |
Here we propose specific changes to RFC2068. |
149 |
|
150 |
3.1 Changes to section 5.1.2, Request-URI |
151 |
Remove this: |
152 |
|
153 |
If a proxy receives a request without any path in the Request-URI |
154 |
and the method specified is capable of supporting the asterisk form |
155 |
of request, then the last proxy on the request chain MUST forward |
156 |
the request with "*" as the final Request-URI. For example, the |
157 |
request |
158 |
|
159 |
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 |
160 |
|
161 |
would be forwarded by the proxy as |
162 |
|
163 |
OPTIONS * HTTP/1.1 |
164 |
Host: www.ics.uci.edu:8001 |
165 |
|
166 |
after connecting to port 8001 of host "www.ics.uci.edu". |
167 |
|
168 |
|
169 |
|
170 |
|
171 |
|
172 |
Mogul, Cohen, Lawrence [Page 3] |
173 |
|
174 |
Internet-Draft HTTP OPTIONS messages 28 July 1997 13:43 |
175 |
|
176 |
|
177 |
3.2 Changes to section 9.2, OPTIONS |
178 |
Replace: |
179 |
|
180 |
Unless the server's response is an error, the response MUST NOT |
181 |
include entity information other than what can be considered as |
182 |
communication options (e.g., Allow is appropriate, but Content-Type |
183 |
is not). Responses to this method are not cachable. |
184 |
|
185 |
with: |
186 |
|
187 |
An OPTIONS request MAY include Compliance headers (see section |
188 |
14.ZZZ) that indicate the set of options the sender wants |
189 |
information about. |
190 |
|
191 |
Responses to OPTIONS are not cachable, unless caching is explicitly |
192 |
allowed by the originating sender (see section 13.4). |
193 |
|
194 |
Replace: |
195 |
|
196 |
If the Request-URI is an asterisk ("*"), the OPTIONS request is |
197 |
intended to apply to the server as a whole. A 200 response SHOULD |
198 |
include any header fields which indicate optional features |
199 |
implemented by the server (e.g., Public), including any extensions |
200 |
not defined by this specification, in addition to any applicable |
201 |
general or response-header fields. As described in section 5.1.2, an |
202 |
"OPTIONS *" request can be applied through a proxy by specifying the |
203 |
destination server in the Request-URI without any path information. |
204 |
|
205 |
with: |
206 |
|
207 |
If the Request-URI is an asterisk ("*"), the OPTIONS request is |
208 |
intended to apply to the server as a whole. A 200 response SHOULD |
209 |
include a Public header field (see section 14.35). If the request |
210 |
includes a Compliance header field, a 200 response SHOULD include a |
211 |
Compliance header field, indicating the subset of the requested |
212 |
Compliance options supported by the server as a whole. The response |
213 |
SHOULD include any other applicable general or response-header |
214 |
fields. |
215 |
|
216 |
If an OPTIONS request includes a Host header (see section 14.23), |
217 |
this is the intended destination of the OPTIONS method. |
218 |
Proxy servers MUST forward such a message until it reaches |
219 |
the specified host. If the specified host has more than |
220 |
one `virtual server', the OPTIONS request applies to the |
221 |
specified virtual server. |
222 |
|
223 |
Note: An OPTIONS request may also include a Max-Forwards header, |
224 |
as described in section 14.31. This allows the sender to select |
225 |
the Nth proxy on a path, without knowing its hostname. |
226 |
|
227 |
|
228 |
|
229 |
Mogul, Cohen, Lawrence [Page 4] |
230 |
|
231 |
Internet-Draft HTTP OPTIONS messages 28 July 1997 13:43 |
232 |
|
233 |
|
234 |
Replace: |
235 |
|
236 |
If the Request-URI is not an asterisk, the OPTIONS request applies |
237 |
only to the options that are available when communicating with that |
238 |
resource. A 200 response SHOULD include any header fields which |
239 |
indicate optional features implemented by the server and applicable |
240 |
to that resource (e.g., Allow), including any extensions not defined |
241 |
by this specification, in addition to any applicable general or |
242 |
response-header fields. If the OPTIONS request passes through a |
243 |
proxy, the proxy MUST edit the response to exclude those options |
244 |
which apply to a proxy's capabilities and which are known to be |
245 |
unavailable through that proxy. |
246 |
|
247 |
with: |
248 |
|
249 |
If the Request-URI is not an asterisk, the OPTIONS request applies |
250 |
only to the options that are available when communicating with that |
251 |
resource. A 200 response SHOULD include an Allow header field (see |
252 |
section 14.7). If the request includes a Compliance header field, a |
253 |
200 response SHOULD include a Compliance header field, indicating |
254 |
the subset of the requested Compliance options supported by the |
255 |
server as a whole. If the subset is empty, the response SHOULD |
256 |
include a Compliance header with an empty field-value. The response |
257 |
SHOULD include any other applicable general or response-header |
258 |
fields. |
259 |
|
260 |
Note: if an OPTION request contains a Compliance header, and the |
261 |
response does not, the response may have been generated by |
262 |
RFC2068-compliant implementation, which would not support |
263 |
Compliance. In this case, it is not possible to infer that the |
264 |
sender fails to support all of the options listed in the |
265 |
Compliance header of the request. |
266 |
|
267 |
If the OPTIONS request passes through a |
268 |
proxy, the proxy SHOULD add a Non-Compliance header field (see |
269 |
section 14.QQQ) to the response, to list those options that apply to |
270 |
a proxy's capabilities and that are known to be unavailable through |
271 |
that proxy. |
272 |
|
273 |
3.3 Changes to section 14.31, Max-Forwards |
274 |
Replace: |
275 |
|
276 |
Each proxy or gateway recipient of a TRACE request containing a Max- |
277 |
Forwards header field SHOULD check and update its value prior to |
278 |
forwarding the request. |
279 |
|
280 |
with: |
281 |
|
282 |
Each proxy or gateway recipient of a TRACE or OPTIONS request |
283 |
containing a Max-Forwards header field SHOULD check and update its |
284 |
value prior to forwarding the request. |
285 |
|
286 |
Mogul, Cohen, Lawrence [Page 5] |
287 |
|
288 |
Internet-Draft HTTP OPTIONS messages 28 July 1997 13:43 |
289 |
|
290 |
|
291 |
3.4 The Compliance header |
292 |
Insert in section 14, as a new subsection titled ``14.ZZZ |
293 |
Compliance'' |
294 |
|
295 |
The Compliance general header field lists a set of options |
296 |
that may or may not be supported by a server. In a request |
297 |
message, this header lists the set of options that a client |
298 |
wishes to know about. In a response message, this header |
299 |
lists the set of options that the server complies with. |
300 |
|
301 |
A compliance header MAY appear on any message, but is |
302 |
normally used with the OPTIONS request (see section 9.2). |
303 |
|
304 |
Compliance = "Compliance" ":" ("*" | *(compliance-option)) |
305 |
|
306 |
compliance-option = compliance-namespace "=" |
307 |
option-item [ option-params ] |
308 |
|
309 |
compliance-namespace = token |
310 |
|
311 |
option-item = token | quoted-string |
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 |
The compliance-namespace is used to select from one of several |
323 |
namespaces for compliance options. The option-item is used |
324 |
to specify one or more options within a namespace. |
325 |
|
326 |
|
327 |
|
328 |
|
329 |
|
330 |
|
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 28 July 1997 13:43 |
346 |
|
347 |
|
348 |
The Internet Assigned Numbers Authority (IANA) acts as a registry |
349 |
for compliance-namespace tokens. Initially, the registry contains |
350 |
the following tokens: |
351 |
|
352 |
"RFC" Compliance is with an RFC, specified by an RFC number. |
353 |
For example, "rfc=1945". |
354 |
|
355 |
"HDR" Compliance is with a named HTTP header. For example, |
356 |
"HDR=Authorization". There is no IANA registry for |
357 |
HTTP header names, but to avoid potential namespace |
358 |
confusion, only those HTTP headers listed in an |
359 |
IETF standards-track document should be used in |
360 |
this namespace. |
361 |
|
362 |
"PEP" Compliance is with a PEP-specified extension, identified |
363 |
using a quoted-string containing the PEP extension |
364 |
declaration. |
365 |
|
366 |
The option-param is used to provide additional parameters. |
367 |
Unconditional compliance with a compliance-option is indicated |
368 |
using the "uncond" option-param; for example, "rfc=1945;uncond". |
369 |
Conditional compliance is indicated using the "cond" option-param; |
370 |
for example, "HDR=Authorization;uncond". Additional option-param |
371 |
values might be defined as part of another specification. |
372 |
|
373 |
Examples: |
374 |
|
375 |
Compliance: rfc=2068;uncond |
376 |
Compliance: rfc=1945;uncond, rfc=2068;cond |
377 |
Compliance: rfc=2068, hdr=PEP, hdr=SetCookie2 |
378 |
Compliance: rfc=9999999;uncond;"onlyOn=Tuesdays" |
379 |
|
380 |
3.5 The Non-Compliance header |
381 |
Insert in section 14, as a new subsection titled ``14.QQQ |
382 |
Non-Compliance'' |
383 |
|
384 |
A proxy server SHOULD add this response-header to a response |
385 |
containing a Compliance header if the proxy does not implement one |
386 |
or more of the options described in the Compliance header. |
387 |
|
388 |
Non-Compliance = "Non-Compliance" ":" 1#non-compliance-option |
389 |
|
390 |
proxy-host = host [ ":" port ] |
391 |
|
392 |
non-compliance-option = compliance-option "@" proxy-host |
393 |
|
394 |
|
395 |
|
396 |
|
397 |
|
398 |
|
399 |
|
400 |
Mogul, Cohen, Lawrence [Page 7] |
401 |
|
402 |
Internet-Draft HTTP OPTIONS messages 28 July 1997 13:43 |
403 |
|
404 |
|
405 |
A non-compliance-option listed in a Non-Compliance response-header |
406 |
field indicates that the proxy server named by the proxy-host value |
407 |
does not support the listed compliance-option. The set of |
408 |
non-compliance options SHOULD be a subset of the compliance-options |
409 |
listed in a Compliance header field of the forwarded message. |
410 |
|
411 |
Note: because the proxy-host value is not authenticated, |
412 |
this is only for advisory purposes (e.g., for debugging). |
413 |
|
414 |
A proxy MUST NOT delete a Non-Compliance header that it has |
415 |
received from another server. |
416 |
|
417 |
3.6 Changes to sections 14.7 and 14.35, Allow and Public |
418 |
The problem we address here is that RFC2068's specifications for the |
419 |
Allow and Public headers are inconsistent as to whether a proxy |
420 |
"MUST" or "MUST NOT" edit them. We believe that they should be |
421 |
consistent. Given that, there are arguments for either alternative: |
422 |
|
423 |
- Requiring proxies to edit these headers provides the |
424 |
ultimate client with a simple way to determine if a method |
425 |
is allowed along the entire path to the origin server. |
426 |
|
427 |
- However, requiring proxies not to edit these headers allows |
428 |
a client to find out about the capabilities of the origin |
429 |
server, since (as RFC2068 says about the Allow header) "the |
430 |
user agent may have other means of communicating with the |
431 |
origin server." |
432 |
|
433 |
The second alternative seems more robust. Although we do not |
434 |
currently have an efficient mechanism for finding out if a method is |
435 |
supported along the entire path, presumbly any request using an |
436 |
unsupported method would immediately be rejected. However, we list |
437 |
both alternatives in the hope that further discussion will lead to a |
438 |
more satisfying solution. |
439 |
|
440 |
Note: one possibility, not yet explored in detail, is that the |
441 |
compliance-namespace could be extended to include a "METH" |
442 |
token, allowing the Compliance header (and hence the |
443 |
Non-Compliance header) to completely replace the Allow and |
444 |
Public headers. E.g., the client could send |
445 |
|
446 |
Compliance: METH=* |
447 |
|
448 |
to which the origin server might respond |
449 |
|
450 |
Compliance: METH=GET,METH=PUT,METH=HEAD |
451 |
|
452 |
If this passes through a proxy that bans (e.g.) PUT, the proxy |
453 |
could forward the response as |
454 |
|
455 |
Compliance: METH=GET,METH=PUT,METH=HEAD |
456 |
Non-Compliance: METH=PUT@roproxy.net |
457 |
Mogul, Cohen, Lawrence [Page 8] |
458 |
|
459 |
Internet-Draft HTTP OPTIONS messages 28 July 1997 13:43 |
460 |
|
461 |
|
462 |
3.6.1 Alternative A: proxies MUST NOT modify Allow/Public |
463 |
In section 14.35 (Public), replace |
464 |
|
465 |
This header field applies only to the server directly connected to |
466 |
the client (i.e., the nearest neighbor in a chain of connections). |
467 |
If the response passes through a proxy, the proxy MUST either remove |
468 |
the Public header field or replace it with one applicable to its own |
469 |
capabilities. |
470 |
|
471 |
with: |
472 |
|
473 |
A proxy MUST NOT modify the Public header field even if it does not |
474 |
understand all the methods specified, since the user agent might |
475 |
have other means of communicating with the origin server. |
476 |
|
477 |
Also, in section 14.7 (Allow), replace |
478 |
|
479 |
A proxy MUST NOT modify the Allow header field even if it does not |
480 |
understand all the methods specified, since the user agent MAY have |
481 |
other means of communicating with the origin server. |
482 |
|
483 |
with: |
484 |
|
485 |
A proxy MUST NOT modify the Allow header field even if it does not |
486 |
understand all the methods specified, since the user agent might |
487 |
have other means of communicating with the origin server. |
488 |
|
489 |
(removes an incorrect use of the term "MAY"). |
490 |
|
491 |
3.6.2 Alternative B: proxies MUST modify Allow/Public |
492 |
In section 14.7 (Allow), replace |
493 |
|
494 |
A proxy MUST NOT modify the Allow header field even if it does not |
495 |
understand all the methods specified, since the user agent MAY have |
496 |
other means of communicating with the origin server. |
497 |
|
498 |
with: |
499 |
|
500 |
A proxy MUST remove methods from an Allow header field if it |
501 |
does not support the use of those methods for the resource |
502 |
identified by the Request-URI. |
503 |
|
504 |
and in section 14.35 (Public), replace this paragraph: |
505 |
|
506 |
This header field applies only to the server directly connected to |
507 |
the client (i.e., the nearest neighbor in a chain of connections). |
508 |
If the response passes through a proxy, the proxy MUST either remove |
509 |
the Public header field or replace it with one applicable to its own |
510 |
capabilities. |
511 |
|
512 |
with: |
513 |
|
514 |
Mogul, Cohen, Lawrence [Page 9] |
515 |
|
516 |
Internet-Draft HTTP OPTIONS messages 28 July 1997 13:43 |
517 |
|
518 |
|
519 |
A proxy MUST remove methods from a Public header field if it |
520 |
does not support the use of those methods. |
521 |
|
522 |
3.7 Examples |
523 |
|
524 |
To list all extensions supported by proxy "proxy4.microscape.com" |
525 |
|
526 |
Client sends: |
527 |
OPTIONS * HTTP/1.1 |
528 |
Host: proxy4.microscape.com |
529 |
Compliance: * |
530 |
|
531 |
proxy4.microscape.com responds: |
532 |
HTTP/1.1 200 OK |
533 |
Date: Tue, 22 Jul 1997 20:21:51 GMT |
534 |
Server: SuperProxy/1.0 |
535 |
Public: OPTIONS, GET, HEAD, PUT, POST, TRACE |
536 |
Compliance: rfc=1543, rfc=2068, hdr=set-proxy |
537 |
Compliance: hdr=wonder-bar-http-widget-set |
538 |
Compliance: PEP="http://foobar.pep.org/pepmeister/" |
539 |
Content-Length: 0 |
540 |
|
541 |
[Editorial note: check syntax of PEP extensions] |
542 |
|
543 |
Probing for a feature which is not supported by |
544 |
"proxy4.microscape.com" |
545 |
|
546 |
Client sends: |
547 |
OPTIONS * HTTP/1.1 |
548 |
Host: proxy4.microscape.com |
549 |
Compliance: PEP="http://foobar.pep.org/evil-not-implemented" |
550 |
|
551 |
proxy4.microscape.com responds: |
552 |
HTTP/1.1 200 OK |
553 |
Date: Tue, 22 Jul 1997 20:21:52 GMT |
554 |
Server: SuperProxy/1.0 |
555 |
Public: OPTIONS, GET, HEAD, PUT, POST, TRACE |
556 |
Compliance: |
557 |
Content-Length: 0 |
558 |
|
559 |
|
560 |
4 Security Considerations |
561 |
|
562 |
Because the proxy-host value in a Non-Compliance header is not |
563 |
authenticated, in theory, a malicious proxy along the path could |
564 |
insert a Non-Compliance header with the name of some other proxy, |
565 |
perhaps one not even involved in the response. However, because the |
566 |
proxy-host value is used only for advisory purposes (e.g., for |
567 |
debugging), there does not appear to be a serious security problem |
568 |
with this lack of authentication. |
569 |
|
570 |
|
571 |
Mogul, Cohen, Lawrence [Page 10] |
572 |
|
573 |
Internet-Draft HTTP OPTIONS messages 28 July 1997 13:43 |
574 |
|
575 |
|
576 |
Besides, any proxy along the request/response path for an HTTP |
577 |
interaction is able to perform far more disruptive (and far less |
578 |
easily detected) modifications of the messages it forwards; this |
579 |
proposal does not change that. |
580 |
|
581 |
|
582 |
5 Acknowledgements |
583 |
|
584 |
We would like to thank Roy Fielding, Jim Gettys, Paul Leach, and |
585 |
Larry Masinter for help in constructing this proposal. |
586 |
|
587 |
|
588 |
6 References |
589 |
|
590 |
1. D. Connolly, R. Khare, H. Frystyk Nielsen. PEP - an Extension |
591 |
Mechanism for HTTP. Internet Draft draft-ietf-http-pep-04, HTTP |
592 |
Working Group, July, 1997. This is a work in progress. |
593 |
|
594 |
2. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk |
595 |
Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol -- |
596 |
HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997. |
597 |
|
598 |
|
599 |
7 Authors' addresses |
600 |
|
601 |
Jeffrey C. Mogul |
602 |
Western Research Laboratory |
603 |
Digital Equipment Corporation |
604 |
250 University Avenue |
605 |
Palo Alto, California, 94305, USA |
606 |
Email: mogul@wrl.dec.com |
607 |
|
608 |
Josh Cohen |
609 |
Netscape Communications Corporation |
610 |
501 E. Middlefield Rd |
611 |
Mountain View, CA 94043 |
612 |
Phone (415) 937-4157 |
613 |
EMail: josh@netscape.com |
614 |
|
615 |
Scott Lawrence |
616 |
Agranat Systems, Inc. |
617 |
1345 Main St. |
618 |
Waltham, MA 02154 |
619 |
Phone: +1-617-893-7868 |
620 |
Fax: +1-617-893-5740 |
621 |
Email: lawrence@agranat.com |
622 |
|
623 |
|
624 |
|
625 |
|
626 |
|
627 |
|
628 |
Mogul, Cohen, Lawrence [Page 11] |