Re: URI fields in response headers

Jim Seidman writes:
 > >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: <>;vary="encoding,version",
 > >      <TheProject.html>;vary="user-agent,charset,version"
 > Shel Kaphan writes:
 > >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...)
 > My problem with the example in the spec is that the two URIs have different
 > 'vary' dimensions, and obviously the two of them differ in type.  But while
 > we know that is application/postscript and TheProject.html is
 > text/html, how can a client or proxy know this from the header information?
 > I think that this section on the URI response, as well as section 6.2.3
 > which requires a 406 response to include the metainformation on a resource
 > without specifying how to deal with varying dimensions, needs to be much
 > better explained in the spec.
 > --
 > Jim Seidman, Senior Software Engineer
 > Spyglass Inc., 1230 E. Diehl Road, Naperville IL 60563

I see your point.  There seem to be quite a few problems in this area.
It is becoming clearer to me that the URI header is intended to
describe where you might find a resource, not to identify the resource
being returned (since it is required in those instances when the
resource is *not* enclosed in the message (though optional when it is
enclosed, hence the ambiguity)).  The point you raise is a good one --
how is the client to know which of the URIs named in the header has
the type, encoding, or other attribute desired by the client.  The
mere fact that resources returned in response to a request for a
particular URI might *vary* along a particular dimension isn't really
sufficient -- you also need to know the possible values along that
dimension to decide which one to request.

There is a further point that concerns me about this, as I mentioned
before.  Apparently the URI header isn't well suited to identifying the
resource enclosed in the response.  But since there is a possible
many-to-one mapping of request-URIs to a given returned resource, cache
integrity requires that there be some mechanism by which the actual
resource being transmitted can be identified in the transmission.
Is there some way in the current spec to accomplish this, or does it
require a new header?  

Is this issue being addressed?  Or is it the feeling of the keepers of
the spec that the potential many-to-one-ness of this is not an
important enough issue to warrant consideration?  I personally think
that as services provided on the WWW become more and more complex and
dynamic, as they certainly will do, that the need for cache integrity
will be increasing, and the likelihood of such many-to-one mappings
will be also be increasing (as will the dependency by content
providers on caches paying attention to Expires, etc. (AOL, Prodigy --
are you listening?))

--Shel Kaphan

Received on Saturday, 17 June 1995 13:10:46 UTC