"Max-age" in dictionary vs "Expiration"

[Jim Roskind]

As currently proposed, each dictionary contains a max-age metadata
field in each dictionary. This field is used to calculate an
expiration, but it is relative to the download time. As a result, it
is hard to define a dictionary that expires at a specific time.

Example: every Monday I'd like to create a new dictionary, and I'd
like to always mark dictionaries to expire at midnight of Tuesday of
the next week. Using max-age, I can't just say "expire in 8
days" (I'd spell that using seconds, as per the SDCH spec), as the
true expiration time is always relative to the download time. IF I
tried to use max-age, and a user downloaded a dictionary on Sunday
night, it would remain active until 8 days later, and I'd prefer to
use the newer dictionary starting on Tuesday :-/. My server could
ignore the old dictionary, but it is sad that the client will keep on
advertising it (and as noted, we don't yet have a way to induce a
deletion of an existing client-downloaded dictionary).

Also note that if my server changes the max-age metadata, then the
hash of the dictionary would change <oops>.

Suggestion: Consider putting in an expiration date metadata item, in
addition to the existing max-age metadata.

Thanks,

Jim

[Jon Butler]

The dictionary-cookie parallel could be extended to include the expires information by changing the format of the dictionary suggestion header. Alternatively, the protocol could rely on standard http caching headers to handling dictionary expiration.

Jonathan

[Wei-Hsin Lee]

It probably is better idea of using caching directives in HTTP header if we can move dictionary storage to browser cache. In any case, setting max-age is good idea.

Wei-Hsin

[Jim Roskind]

The SDCH spec does not appear to intimately link an URL to a single dictionary.  Specifically, based on my reading of the spec, a single URL can be used to retrieve numerous dictionaries at the same time!  Not just sequentially (replacing previous dictionaries)!!!   Please correct me if I've misread something.

As a result, cache info about an URL containing a dictionary does not seem related to whether a dictionary should be preserved (or discarded during a disk-cache eviction for the potentially reusable URL).

IMO, it would in contrast be a good idea to have a 1-1 relationship between dictionaries and URLs, and in fact naming conventions standardizing on this would probably be a positive direction.  That would put us in a better position to use the cache control directives, and deprecate this max-age field.

Jim

[Jim Roskind]

On Sat, Nov 15, 2008 at 10:19 AM, Jon Butler <butler....@gmail.com> wrote:

The dictionary-cookie parallel could be extended to include the expires information by changing the format of the dictionary suggestion header. 

Could you elaborate a little further on that?  I had been thinking along the lines of having the dictionary server specifying information about a dictionary retention, and I hadn't thought about ways that a content server (that provides some dictionary suggestions) could/would provide expiration stats.

Is there a hint that the user of the dictionary (content server) should have some say about the longevity of the global dictionary use?  Would then different content servers have different views of its longevity?

Am I misunderstanding?

I think there is a gap in the cookie-dictionary parallel, as a cookie is directly set along with content.  In contrast, a dictionary is suggested with content (by a content server), but "set" when acquired from during a completely separate URL fetch (from what I would call a "dictionary server.").

Thanks,

Jim

[Lincoln]

On Sat, Nov 15, 2008 at 1:25 PM, Jim Roskind <j...@chromium.org> wrote:
> The SDCH spec does not appear to intimately link an URL to a single
> dictionary. Specifically, based on my reading of the spec, a single URL can
> be used to retrieve numerous dictionaries at the same time! Not just

> sequentially (replacing previous dictionaries) [...] As a result, cache info

> about an URL containing a dictionary does not seem related to whether a
> dictionary should be preserved (or discarded during a disk-cache eviction
> for the potentially reusable URL).

Isn't it possible for the server to return different sets of cache-
control
headers for different dictionaries corresponding to the same URL? The
cache-control headers describe the individual response, not the URL,
or am I
mistaken?

> IMO, it would in contrast be a good idea to have a 1-1 relationship between
> dictionaries and URLs, and in fact naming conventions standardizing on this
> would probably be a positive direction. That would put us in a better
> position to use the cache control directives, and deprecate this max-age
> field.

I would prefer to have a looser restriction: that there be only one
*currently
advertised* dictionary per URL -- advertised by the server using
Get-Dictionary, and advertised by the client using Avail-Dictionary.
If a
new dictionary were advertised for the same URL, it would be
implicitly
recognized as a newer version of the same resource. The client could
then
unload the dictionary once all responses that referred to that
dictionary
had completed.

This discussion underscores the need to add a Delete-Dictionary
response
header to the SDCH specification. If a dictionary needs to be
unloaded from
the server unexpectedly, expiration headers will not suffice to inform
the
client that the dictionary is now invalid and should be removed from
memory,
disk, and Avail-Dictionary headers.

Saludos,

lincoln