W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Suggestion: Add Cache-Control extensibility to Vary header

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Thu, 13 Mar 1997 17:23:12 -0500
Message-Id: <3.0.1.32.19970313172312.00a97eb0@pop.w3.org>
To: http-wg@cuckoo.hpl.hp.com

By adding the Cache-Control header extensibility mechanism (14.9.6) to the
Vary header, I believe that we make caches much more robust to extended
content (or feature) negotiation than by having the current definition of
Vary.

Let me give a specific example where this does make a difference with
regard to cacheability: In the current PEP spec and the one we are working
on, we came up with the following construction:
 
	GET /a-document HTTP/1.1
	Host: a.host
	Protocol: {http://some.org/an-extension {str "req"}

	HTTP/1.1 200 OK
	Protocol: {http://some.org/an-extension {str "req"}
	Vary: Protocol
	Content-Type: text/plain
	...

	Glad you're using an-extension!

This is a typical situation where we have applied an extension to an HTTP
transaction. In the example we use the Vary header to notify proxies that
responses to GET /a-document depend on the Protocol header fields used in
the request.

This works fine but if we instead have two extensions where one is optional
and the other required like this:

	GET /a-document HTTP/1.1
	Host: a.host
	Protocol: {http://some.org/a-required-extension {str "req"}},
		   {http://some.org/an-optional-extension {str "opt"}}

	HTTP/1.1 200 OK
	Protocol: {http://some.org/a-required-extension {str "req"}},
		   {http://some.org/an-optional-extension {str "opt"}}
	Vary: Protocol
	Content-Type: text/plain

then the cache would only be able to serve the request if both extensions
are available in the request even though the one is optional.

I believe this in many cases is too strict as it will effectively
disable caching of all optional extensions.

I therefore suggest that we define the Vary header to have the same
extension modifiers to existing header values just like the cache-control
header. This means that a PEP-aware proxy cache will be able to understand
something like this

	HTTP/1.1 200 OK
	Protocol: {http://some.org/a-required-extension {str "req"}},
		   {http://some.org/an-optional-extension {str "opt"}}
	Vary: Protocol, "http://some.org/a-required-extension"
	Content-Type: text/plain

and serve the cached entity in response to a request like this:

	GET /a-document HTTP/1.1
	Host: a.host
	Protocol: {http://some.org/a-required-extension {str "req"}

Note that this doesn't _force_ the proxy to serve the request. This is a
property of the extension itself: The proxy may not be allowed to reply as
an intermediary depending on the contractual agreement between the proxy
and the origin server.

Comments?

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-346
545 Technology Square, Cambridge MA 02139, USA
Received on Thursday, 13 March 1997 14:26:08 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:31 EDT