- From: Shel Kaphan <sjk@amazon.com>
- Date: Sat, 17 Jun 1995 13:05:46 -0700
- To: Jim Seidman <jim@spyglass.com>
- Cc: Shel Kaphan <sjk@amazon.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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: <TheProject.ps>;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 TheProject.ps 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 sjk@amazon.com
Received on Saturday, 17 June 1995 13:10:46 UTC