RE: EDITS for Section 10.16 (Content-Location)

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 UTC