- From: Paul Prescod <paul@prescod.net>
- Date: Thu, 20 Mar 2003 22:37:41 -0800
- To: Silvia.Pfeiffer@csiro.au
- CC: asgilman@iamdigex.net, uri@w3.org, Conrad.Parker@csiro.au, ozone@algorithm.com.au
Silvia.Pfeiffer@csiro.au wrote: > > ... > > 1) With the temporal offsets we are not querying any databases nor are > we composing a previously non-existent Web resource. All we are doing is > addressing a subpart of a Web resource. The subpart is a resource. You want the client to address it and the server to return a representation of it. To me, this is the definition of a resource. > ... It is my understanding that that > was the original intention of creating the fragment component and > therefore we should make use of it. The fragment component is something interpreted entirely on the client. That's why it doesn't generate a "new resource" the way the fragment identifier is perceived to. > 2) Query results cannot be cached in network proxies, though Web > resources can. Query results can be cached in network proxies. I believe this is a variant of the myth here: http://www.w3.org/2001/tag/doc/get7#myths The query result _does_ address a Web resource: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2 The HTTP 1.1 spec. is clear that query-retrieved entities CAN be cached, but you might have to trigger that explcitly: We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. See section 9.1.1 for related information. http://www.ietf.org/rfc/rfc2616.txt If you look through the rest of that document you will see that query strings are accorded no special status except > ... The use of fragments, which specify subparts of Web > resources, can enable the network to cache and reuse these subparts, > which provides scalability to the use of time-continuous data on the > Internet. Caches will treat a fragment identifier on the wire as a bug, as they should. They will probably discard it. > ... > While this usage prescriptions may be appropriate for html pages, it is > not good for Web resources that consist of large volume data, of which > the user is only interested in receiving a small subpart. I believe your "large volume of data" is equivalent to what the specs mean when they talk about "database". Paul Prescod
Received on Friday, 21 March 2003 01:38:10 UTC