Re: rethinking caching

Shel Kaphan:
>
>sfwhite@incontext.ca writes:
> > 
> > what i'm wondering is why content negotiation can't just return
> > the actual URL of the negotiated resource, using the new
> > "Content-Location".

It _can_ return the actual URL.  From the 1.1 draft:

|10.27  Location
|
|   The Location response-header field defines the exact location of 
|   the resource that was identified by the Request-URI. For 2xx 
|   responses, if the Request-URI corresponds to a negotiable set of 
|   variants and the response includes one of those variants, then the 
|   response must also include a Location header field containing the 
|   exact location of the chosen variant.

[Shel gives a reason why Location cannot work this way:]
>At least one issue is the spoofing issue: If clients use the
>"Location" header as the cache key for the resource, then it is easy
>for a server to claim to be sending any old URI, and for that resource
>to get lodged in a cache under the false URI.

Eek.  I had completely forgotten the spoofing issue, thanks for
reminding me.  The solution to this spoofing issue is simple, and I
believe it has been discussed before.  Include the following rule:

  Clients (including caching proxies) should disregard Location
  headers in 2xx responses if they do not point to the same server
  that generated the response.

This restriction still leaves you with a negotiation mechanism
powerful enough to handle the French/English example.

Note that the above solution assumes that either the content providers
on the same server either trust each other not to spoof, or that the
server has some Location response header filtering mechanism that
excludes spoofing.

This spoofing issue is not addressed in the current draft 1.1 spec.
I'm in the content negotiation subgroup, I'll make sure we will
address it there.

Koen.

Received on Saturday, 16 December 1995 07:43:59 UTC