RE: EDITS for Section 10.16 (Content-Location) (2)

>----------
>From: 	Larry Masinter[SMTP:masinter@parc.xerox.com]
>Sent: 	Tuesday, April 30, 1996 4:07 PM
>
>> |  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.

But it would be very hard, since the response is saved to use to reply
to a future request. It's kind of silly to say that the cache can cache
it but not use to to reply to any request -- it's easier to say that it
can't cache it. (In general, the context for any protocol spec is such
that what "don't do X" means is that, if you do X, it can't be visible
via the protocol that you've done it...)
>
>> 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.

What good is Content-Location then? Can the client assume that if it
GETs the content-location URI returned from GETting a URI of a varying
resource, that it will get that variant? If so, then a cache is a
client.... If not, what good is Content-Location?

Paul
>
>
>
>
>

Received on Tuesday, 30 April 1996 16:46:20 UTC