Re: Location, location, location

Shel Kaphan:
>
[...]
>A context in which this invalidation could be very useful is content
>negotiation.

In the content negotiation mechanism as described in my `New content
negotiation sections' document at

  http://weeble.lut.ac.uk/lists/http-caching/0241.html

the Location header is not just used for invalidation, but also for
a factor 2 optimization: 

 - a proxy can answer a direct request on a variant URI by
   re-using a preemptive negotiation response that included that
   variant.

 - a proxy can make a preemptive negotiation response that includes a
   variant by re-using a response on a direct request for that
   variant.

(Aside: I am using the word `variant' as used in the `New content
 negotiation sections' document:

 | A variant is a resource, identified by a variant URI, that provides a
 | representation of the content of a negotiable resource.

 so my `variant' does not mean `one of the possible entities served by
 a varying resource (=an un-negotiated resource that includes Vary
 headers in the responses).
)

Spoofing is avoided by requiring that

  - Clients must reject preemptive responses with Location: headers
    that do not point to a variant on the same server
  - Servers that contain content of multiple parties must implement
    security mechanisms to avoid mutual spoofing.

Basically, if you run a server with multiple non-cooperating users,
you have to either trust those people who may author scripts (CGI or
other kinds), or you have to restrict the CGI script mechanism to
either reject or restrict preemptive negotiation responses made by
scripts (including nph CGI scripts, which means that you will have to
parse the headers they generate).  Filtering out and throwing away all
preemptive responses is always safe and easy to do, but has the
disadvantage of being less efficient than a more complicated filter.

Yes, this means extra work for server authors and server maintainers.
But in my analysis, this is the option with the least disadvantages.

Other options:  
  - Require no filtering: too unsafe
  - No preemptive responses in protocol: too inefficient,
                                         always need 2 RTTs
  - No factor 2 optimization: leads to much less efficient caches

Caching is already less efficient for negotiated resources, as there
are multiple variants that all take cache memory, and must all be
transmitted at least once.  Leaving out the factor 2 optimization,
i.e. caching preemptive and reactive responses separately, would make
caching very much less efficient, because all variants would have to
be transmitted and stored twice.


For a complete description of the mechanisms involved, please read the
`New content negotiation sections' document at

  http://weeble.lut.ac.uk/lists/http-caching/0241.html

itself.  I know it is long, but it cannot be made much shorter.
(Careful editing may take out some 30%, but not much more).  There are
no magical short solutions in this area.  You can have any 4 of the
things below, but not all 5:

 1 small content negotiation definition
 2 content negotiation that always produces optimal results
 3 short accept headers 
 4 one-RTT transactions in most cases 
 5 good caching

>--Shel

Koen.

Received on Tuesday, 6 February 1996 13:24:15 UTC