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

Re: EDITS for Section 10.16 (Content-Location)

From: Larry Masinter <masinter@parc.xerox.com>
Date: Tue, 30 Apr 1996 16:07:08 PDT
To: koen@win.tue.nl
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, koen@win.tue.nl
Message-Id: <96Apr30.160712pdt.2733@golden.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/398
> |  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:11:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC