W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

RE: EDITS for Section 10.16 (Content-Location)

From: Paul Leach <paulle@microsoft.com>
Date: Tue, 30 Apr 1996 16:27:27 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960430232727Z-26088@tide21.microsoft.com>
To: "'koen@win.tue.nl'" <koen@win.tue.nl>, 'Larry Masinter' <masinter@parc.xerox.com>
Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'koen@win.tue.nl'" <koen@win.tue.nl>
It is inappropriate to say that I can't use the content-location URI --
in my internal corporate Web, the spoofing problem may not be an issue,
and caching efficiency might be served by using the Content-Location
URI.

There does need to be a comment in the security considerations section
about spoofing and Content-Location, but I think there already is one.

>----------
>From: 	Larry Masinter[SMTP:masinter@parc.xerox.com]
>Sent: 	Tuesday, April 30, 1996 4:07 PM
>To: 	koen@win.tue.nl
>Cc: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com; koen@win.tue.nl
>Subject: 	Re: EDITS for Section 10.16 (Content-Location)
>
>> |  Under this specification, the response to a request on one URI can
>> |  never create or update information cached for another URI.  For
>> |  security reasons, when storing the response in cache memory, caches
>> |  MUST use the resource URI indicated by the request, and MUST NOT use
>> |  the URI in the Content-Location header field.
>
>This kind of wording really doesn't belong in the HTTP specification.
>We can say what clients, servers and proxies MUST send or MUST NOT
>send, but putting requirements on implementations and implementation
>techniques just doesn't fly. I think this can be rewritten in terms of
>the meaning of the response rather than constraints on the action of
>the cache when getting a response.
>
>> Note that the Content-location information is advisory, and that
>> there is no guarantee that the URI of the Content-location actually
>> corresponds in any to the original request URI. For example, a cache
>> cannot reliably assume that the data returned as a result of the
>> request can be returned from a new request on any URI other than the
>> original request.
>
>
>
>
>
Received on Tuesday, 30 April 1996 16:41:52 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:59 EDT