On 17 May 2013, at 14:52, Nicholas Weaver wrote: > > On May 17, 2013, at 6:49 AM, Wendy Roome <[email protected]> wrote: > >> I assume you're referring to {13.2} of RFC 2616. That section strikes me as >> "a royal kludge." (Privately I'd apply a much stronger adjective, but I'm >> too much of a lady to use such language in public.) >> >> The problem is that HTTP defines multiple ways to declare expiration times >> -- Expires header, cache directives, etc. Those mechanisms have evolved over >> time, and not all servers use them consistently. So I think {13.2} is mostly >> about how to cope with legacy HTTP servers and missing or inconsistent >> information. >> >> Since we're starting fresh, why not just say that if an ALTO server wants to >> indicate a polling interval, it SHOULD set the Expires and the Date headers, >> and the client SHOULD use the difference as the approximate polling interval? > > My suggestion: Give up on cache headers. > > Rather, all fetches should use a CACHE-busting NONCE (if you are behind an > in-path web cache, there is a ~50% chance the cache is busted and will > provide stale data, EVEN IF the server's headers say "don't cache this at > all"), and any signaling to the client about what rate it should poll should > be explicit in the protocol for the Alto data, not implicit using HTTP > headers.
Nice Troll! So when I want to poll at a reasonably frequent rate to catch changes relatively quickly, I have to download the whole map each time or we have to re-invent HTTP's revalidation at the ALTO layer. (I don't care about in-path web caches as my use case doesn't involve the ALTO client being in a subscribers home/PC/whatever) Ben _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
