Cache-control extension,

Here a mail for discussing an extenstion to the Cache-Control header, that
is backward compatible with HTTP/1.1 (RFC2616). Also for discussion of the
current implementation of the Cache-Control header.

I thought we were discussing it, and supposing Cache-Control had parameters,
BUT Cache-Control does NOT have any parameters. I lost a lot of e-mails
(also regarding this cache-control issue; after 19-apr-00) after doing
something really stupid before reinstalling my computer (removing my e-mail
messages accidentilly).
However, someone introduced the Cache-Control header-value:

	no-cache, community="UCI", max-age=30

This can be really simply interpeted (and possibly correct):
* no-cache: The response is not cacheable (or may not be retreived from
* community="UCI": AND cachable for the UCI community...

* max-age=30: Another aspect, the response it's maximum age may be 30


Look at this one from RFC2616 (latest HTTP/1.1 spec):
	private, community="UCI"

* private: The response may be cached by private caches
* community="UCI": The UCI community may cache the response (including UCI's
shared caches!).


Now a nice one:
	no-cache, private, community="UCI", max-age=60, s-maxage=45

* no-cache: The response is not cachable (or may not be retreived from
* private: Only private caches may cache it, this conflicts with no-cache,
so we prefer the most strict one: no-cache (hope you agree)
* community="UCI": AND cachable for the UCI community.

* max-age: maximum age is 60 seconds.
* s-maxage: however, maximum age for shared caches is 45 seconds.

Here it goes wrong! no-cache and private will conflict, and never forget:
there are no parameters. But it may be of good use if future HTTP/1.1 caches
(what will not be likely) or HTTP/1.2 caches should support these.

Another, but wrong interpetation whould be:
* no-cache: The response is not cachable
* private: Conflicts with "no-cache", so whats after it?
	* community="UCI": So suggest it may be cache by UCI's private caches.
* max-age=60: maximum age is 60 seconds.
* s-maxage=45: maximum age for shared caches is 45 seconds, but this one is
never used.

This interpetation should be considered wrong, because it suggest that
parameters are used, but they are NOT.


Suppose the new form whould be (BNF syntax) for the Cache-Control header:

Cache-Control = "Cache-Control" ":" 1#( Cache-Directive
                                    [ *( ";" Cache-Parameter ) ] )
Cache-Parameter = Cache-Directive

New cache-control directive:
Community = "Community" "=" Community-Name
Community-Name = qouted-string
The directive will indicate the directive will only apply for a specific
community. If there are no parameters with this directive, then it's
publically cachable for that community.
Support for this parameter is OPTIONAL.

Now we whould require (for HTTP/1.1 backward compatibilty) that the first
cache-directive to have NO parameters and must have the most important
directive to be used by all HTTP/1.1 caches, if they don't understand the
rest of the syntax. This is to ensure backward compatibility.
The order of the cache-directives and parameters is not restricted and may
not lead to other interpetations. Parameters will always override global
directives (hope I made my point).
One restriction that must be clear is that "no-cache", "no-store",
"private", "public" may not appear together in one directive and it's
parameters, or appear globally without parameters.
In this cache it whould be possible to make a good cache-control directive:

no-cache, private; community="UCI", max-age=60, community="2nd";
community="3rd"; s-maxage=30; max-age=30

Maybe looks complex, but it is not:
* no-cache: Reponse not cachable
* private; community="UCI" (older HTTP/1.1 caches would ignore this one)
	- private: only applies to private caches
	- community="UCI": of the UCI community.
* max-age=60: maximum age is 60 seconds (the global one)
* community="2nd"; community=3rd"; s-maxage=30; max-age=30 (older HTTP/1.1
will ignore)
	- community="2nd": applies to the 2nd community
	- community="3rd": AND to the 3rd community.
	- s-maxage=30: maximum age for shared caches is 30 seconds
	- max-age=30: maximum age for all other caches is 30 seconds.

If a cached-directive or any of its parameters are not understand, the
entire directive with parameters should be ignored.

no-cache, community="UCI"; division="HTTP WG", max-age=30

* no-cache: do not cache...
* community="UCI"; division="HTTP WG"
     - community="UCI", except for the UCI community
     - division="HTTP WG", NOT understood, ignore the entire directive...
* max-age=30: maximum age is 30 sec.

* no-cache: do not cache...
* max-age=30: maximum age is 30 sec.

The response is not cachable, except for:
* "UCI" community private caches, if the maximum age is 60 seconds (global
directive) AND
* "2nd" and "3rd" community, if the maximum age is 30 seconds, and for
shared caches 30 seconds.

And older HTTP/1.1 caches should find:
	no-cache, max-age=60.
Now hope they interpet this as uncachable.

I think this syntax is compabilible with the existing HTTP/1.1 caches. Maybe
it needs a revision, but I don't suppose it does. This is most likely the
best way for caches to indicate explicitly what they want. Maybe a
consideration for the next HTTP/1.1 RFC or extention to HTTP/1.1.


Received on Saturday, 13 May 2000 07:20:47 UTC