Subject: [alto] Should server use "Expires" HTTP header

From: Wendy Roome <[email-masked]>
Date: Wed, 15 May 2013 09:55:26 -0400

I don't think we've addressed the issue of how frequently a client should
refresh cached data, such as the IRD, the network map, or the cost map.

How about saying something like,

"The ALTO Server SHOULD send an HTTP Expires header [RFC2616] in the
response, as well as a Date header, to indicate the expected lifetime of
the information. The client SHOULD refresh the data sometime after that.
Note that the Expires date is a guideline, not a contract; the ALTO server
may change the data at any time."

I guess that should go in Section 8, but I'm not sure which subsection.

	- Wendy Roome

---

From: Richard Alimi <[email-masked]>
Date: Wed, 15 May 2013 09:47:59 -0700

> I guess that should go in Section 8, but I'm not sure which subsection.

We used to have statements like this (guiding how to use HTTP), except we
received feedback that its better to just leave this out of the ALTO spec.

Rich

>
>         - Wendy Roome
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 May 2013 22:27:45 +0100

I don't think we should be as explicit as Wendy suggests because we're re-specifying HTTP semantics (e.g what if the response contains Cache-Control: max-age less than the Expires header, etc). 

However, it may be worth having a statement around expected polling frequency. 

E.g. That Atom spec utilises HTTP caching by layering on HTTP but doesn't contain any mechanism to explicitly state a desired polling frequency and contains no statement recommending how to handle signalling such desire. There are many questions on stackiverflow and the like asking how cliebts should behave. Best current practice is to only to poll as often as you would revalidate the content (i.e. no more frequently than the instant the content becomes stale according to RFC2616). 

We could advise something similar explicitly. There would be nothing to stop client polling more often if they needed but one would expect a server to apply an appropriate caching lifetime to it's responses according to how frequently it thinks they may change. 

Thoughts?

Ben

On 15 May 2013, at 17:47, Richard Alimi <[email-masked]> wrote:

> 
> 
> On Wed, May 15, 2013 at 6:55 AM, Wendy Roome <[email-masked]> wrote:
> We used to have statements like this (guiding how to use HTTP), except we received feedback that its better to just leave this out of the ALTO spec.
> 
> Rich
>  
>> 
>>         - Wendy Roome
>> 
>>

---

From: Wendy Roome <[email-masked]>
Date: Fri, 17 May 2013 09:49:46 -0400

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?

- Wendy Roome

From:  Ben Niven-Jenkins <[email-masked]>
Date:  Thu, May 16, 2013 17:27
Subject:  Re: [alto] Should server use "Expires" HTTP header

Best current practice is to only to poll as often as you would revalidate
the content (i.e. no more frequently than the instant the content becomes
stale according to RFC2616).

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 17 May 2013 06:52:00 -0700

On May 17, 2013, at 6:49 AM, Wendy Roome <[email-masked]> 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.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 May 2013 16:13:45 +0100

> 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…

That's basically what I was suggesting except rather than being specific about what the server must use, leave it to the client to determine based on how the client calculates freshness (as the client is likely in the best position to know what rate it might want to poll at as it know how up-to-date with any changes it might want to be).

If we're going to pick one mechnaism I;d prefer we pick Cache-Control: max-age myself rather than Date/Expires (as max-age takes priority over Expires according to RFC2616).

Ben

> Best current practice is to only to poll as often as you would revalidate the content (i.e. no more frequently than the instant the content becomes stale according to RFC2616).

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 May 2013 16:15:48 +0100

> 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 sa…

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

---

From: Richard Alimi <[email-masked]>
Date: Sat, 18 May 2013 22:30:13 -0700

On Fri, May 17, 2013 at 8:13 AM, Ben Niven-Jenkins
<[email-masked]>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?
>
> That's basically what I was suggesting except rather than being specific
> about what the server must use, leave it to the client to determine based
> on how the client calculates freshness (as the client is likely in the best
> position to know what rate it might want to poll at as it know how
> up-to-date with any changes it might want to be).
>

I'm fine with adding a statement such as the following:

An ALTO Client determines the frequency at which ALTO information is
refreshed, and MAY be determined based on freshness information made
available via HTTP.

How does that sound?

>
> If we're going to pick one mechnaism I;d prefer we pick Cache-Control:
> max-age myself rather than Date/Expires (as max-age takes priority over
> Expires according to RFC2616).
>

I don't think that ALTO is the place to recommend one or the other. If this
is desired, it seems like this should be something in httpbis (if it isn't
already), or a different draft independent of ALTO.

Rich

> > Best current practice is to only to poll as often as you would
> revalidate the content (i.e. no more frequently than the instant the
> content becomes stale according to RFC2616).
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 28 May 2013 07:28:54 +0100

Rich,

On 19 May 2013, at 06:30, Richard Alimi wrote:
> On Fri, May 17, 2013 at 8:13 AM, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> RA: I'm fine with adding a statement such as the following:
> 
> RA: An ALTO Client determines the frequency at which ALTO information is refreshed, and MAY be determined based on freshness information made available via HTTP.
> 
> RA: How does that sound?

Honestly I don't think it adds anything as this is what a client is likely to do in the absence of any text in the spec.

> RA: I don't think that ALTO is the place to recommend one or the other. If this is desired, it seems like this should be something in httpbis (if it isn't already), or a different draft independent of ALTO.

I agree we shouldn't try to pick one versus the other (hence my original suggestion was to base it on the freshness of the response rather than a particular freshness mechanism) however I do think it would be useful for the ALTO spec to say something.

Atom didn't specify anything for this case either and it caused a lot of confusion for deployers/implementors looking at the questions on stackoverflow/etc.

If we want to avoid RFC2116 type words (which would apply to this case IMO as it is a form of interop issue) then maybe something like:

An ALTO Client determines the frequency at which ALTO information is refreshed and it is suggested that ALTO clients do not refresh ALTO responses before they become stale according to RFC2616.

Ben