- From: Adrian Chadd <adrian@creative.net.au>
- Date: Sat, 23 May 2009 00:45:38 +0800
- To: David Morris <dwm@xpasc.com>
- Cc: Jamie Lokier <jamie@shareable.org>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
.. Squid just caches based on the URL (with relevant rules controlling whether the URL can be cached or not.) I wrote some extensions to allow an external plugin to "normalise" a URL before caching. People use this to cache things like Youtube. 2c, Adrian On Fri, May 22, 2009, David Morris wrote: > > > On Fri, 22 May 2009, Jamie Lokier wrote: > > >Adrien de Croy wrote: > >> > >>there were discussions recently about the method being part of the cache > >>key, since the response for different methods on the same URI could > >>presumably be cacheable and different. > >> > >>What about query string? If the result to something that has a > >>querystring is marked as cachable by the origin server, then is it > >>deemed part of the URI for the cache key? I'd presume yes. > > > >Of coures, the query string is just part of the URI. > > > >>Since URIs can be arbitrarily long, yet database fields aren't good with > >>this, I'd presume it's common practise to look up based on some hash > >>value. Is this approach used? Is there any industry-standard hashing > >>method, e.g. MD5 of method+URI(normalised) + querystring ? > > > >I doubt it. Why would you do that? I don't think it's normal to use > >a URI to select an application and pass the querystring verbatim to a > >database, or at least it's not a good idea :-) > > Why not? .. this is a caching related question where the URI is part of > the cache key ... since I've not implemented such a cache, I can't speak > to what I have done, but a hash such as MD5 seems reasonable ... in > particular if followed by an exact match comparison with a value stored > in a blob, etc. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Received on Friday, 22 May 2009 16:46:19 UTC