- From: Nathan <nathan@webr3.org>
- Date: Mon, 03 Dec 2012 12:58:17 +0000
- To: Kingsley Idehen <kidehen@openlinksw.com>
- CC: public-webid@w3.org
Kingsley Idehen wrote: > On 12/3/12 5:56 AM, Henry Story wrote: >> We still have to see what the issues are here. It seems that the >> cacheability problem pointed out by Nathan >> would affect all JavaScript applications, not just tabulator >> >> [[ >> >> RFC 2616 says: >> "The 303 response MUST NOT be cached, but the response to the second >> (redirected) request might be cacheable." >> >> HTTPBis says: >> "A 303 response SHOULD NOT be cached unless it is indicated as >> cacheable by Cache-Control or Expires header fields." >> >> Of course most tooling will not cache 303s as it's been a MUST NOT for >> 13+ years. >> ]] >> > > You cache data. > > User agents don't cache entity names. > > Using DBpedia as an example, you don't cache > <http://dbpedia.org/resource/Linked_Data>, you cache: > <http://dbpedia.org/page/Linked_Data>, assuming the HTML representation > of the entity description is what you are interested in. Same applies to > all the other representations of the description of: > <http://dbpedia.org/resource/Linked_Data> . Correct, the issue people note, is that you still have to do a GET on <http://dbpedia.org/resource/Linked_Data> in order to get the 303 URI, that second URI can then be loaded from cache, so it involves at least one HTTP GET each time, even with caching.
Received on Monday, 3 December 2012 12:59:19 UTC