URI fields in response headers

Jim Seidman writes:
 > Section 7.1.13 of the spec gives examples an example in which a request
 > generates a response with two URIs:
 > 
 > URI: <TheProject.ps>;vary="encoding,version",
 >      <TheProject.html>;vary="user-agent,charset,version"
 > 
 > The document doesn't make clear under what situations it is desirable (or
 > valid) to return multiple URIs.  Since one of the URIs must not be what the
 > client explicitly requested, it seems that this information is useless for
 > cache management, since the recipient can't know which URI goes with the
 > other metainformation (content-type, etc.) that was in the header.
 > 
 > Can someone give an example of when and why you would return multiple URIs?
 > 
 > --
 > Jim Seidman, Senior Software Engineer
 > Spyglass Inc., 1230 E. Diehl Road, Naperville IL 60563
 > 

This set of issues has been discussed recently by some people from www-talk.

I cannot speak to the intent of the writers of the spec, however I can
suggest future uses for this information for cache management.

It is presently possible to access a single resource under multiple
URIs in some cases.  It may, for instance, be possible to submit a
POST request with a given request-URI, and after some action is
performed by the server, to have the same resource be returned as
would be returned by some (idempotent) GET request with a different
request-URI.  This might be for a number of reasons.  The request-URIs
might have different information embedded in them, for instance the
POST request-URI might be .../add-to-list/item=012345, and the
request-URI for the corresponding GET might be .../show-list.  After
performing different actions, the server might return the same
resource to display the same list in either case.  (And note that this
kind of resource might have an Expires header as well, which further
increases the need for cache coherency).

At the very least, this shows that the URI header in the returned resource
might profitably be used to control caching, even without considering
the functionality added by the 'vary' option.  If the 'same' resource
were returned in response to different request-URIs, the URI header
could be used to control caching in the client, by using it to
identify a single cache slot which should be re-used when new copies
of the resource are received. This could be controlled by always returning a
single "canonical" URI whenever a certain resource is transmitted, or
it could work by listing all the possible request-URIs under which the
resource might be transmitted, or some combination.

If multiple URIs are returned in this header, that suggests (to me,
anyway) that any resources cached with those URIs as keys (with
suitably matching 'vary' options, etc.) should occupy the same cache slot
in the client.  (there are security issues associated with this...)

I realize this may not be the intent of the spec writers, however some
mechanism *is* needed to allow for identical resources transmitted in
response to differing request-URIs to occupy the same client-side
cache slot.  Without some appropriate mechanism (this or another) it
will be necessary for content writers to make sure that whenever a
changing resource needs to be returned in multiple circumstances, that
the request-URIs are identical in order to force the client cache to
behave.  This is a somewhat uncomfortable restriction.

In any case, to the best of my knowledge no popular browsers currently use
this header information.

--Shel Kaphan
  sjk@amazon.com

Received on Wednesday, 14 June 1995 17:17:00 UTC