Re: Space Varying URIs in Summary: Section 2: What does a URI identify?

Well, the resource isn't space-varying, but representations of it may be 
(to use a bit of REST-speak).

HTTP is reasonably explicit about the guarantees of its caching model; 
there aren't many ;) Caches are free to break the rules in a variety of 
situations, and to use an arbitrary heuristic in the absence of explicit 
cacheability directives.

To look at it another way, all that's really happening is that different 
time-varied representations of the resource are cached at different 
places, possibly in different ways. Potentially, this has serious 
consequences; if your requests are routed through two different 
intermediaries, for example, you might get two different ideas of 
freshness, and the origin server may see different combinations of 
request streams at different times. In practice, however, this doesn't 
seem to be much of an issue, but should be noted (e.g., don't count on 
two request/responses from the same user-agent to the same origin server 
following the same path, or being ordered as they were sent).

The Web was, to the best of my knowledge, architected with these 
constraints in mind. This is one reason that I get nervous when I see 
protocols being built on top of HTTP, like HTTPR.

DNS has much of the same issues, except for a much more rigid 
cacheability guarantee. One common problem is that most browsers ignore 
the cache directives in DNS (usually they cite API limitations in the 
OS), instead caching names for the lifetime of the browser "session." 
Generally, I'd classify mirror synchronisation problems, etc. to be out 
of scope here; that's an issue in how the content is provided, not the 
architecture itself.


On Tuesday, March 19, 2002, at 09:24  AM, Elliotte Rusty Harold wrote:

> I notice that this draft makes explicit the idea that a resource is 
> time-varying because what's at the end of the URI.
>
> Are resources also space-varying? Consider the impact of proxy servers 
> (especially infrequently updated ones like AOL's), local caches, and 
> even DNS servers that don't always agree with each other. You may not 
> get the same resource I get when resolving the URI 
> http://www.cafeconleche.org/ even if we resolve it at the same moment 
> in time. You may have an older copy in your cache. My DNS may deliver a 
> different mirror site that hasn't been updated yet, etc.
>
> Does this need to be discussed? Either to confirm it as proper behavior 
> or to deprecate it as indicative of broken software and systems?
> --
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
> |             http://www.cafeconleche.org/books/bible2/              |
> |   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
> |  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
> +----------------------------------+---------------------------------+
>
>
--
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 19 March 2002 19:18:45 UTC