So lets say you have an origin server that is smart enough to redirect to the correct URL always.
For example, identical pages: 1. mydomain.com/blah?a=b&c=d 2. mydomain.com/blah?a=b&c=d&button.x=10 3. mydomain.com/blah?c=d&a=b Are all the same page, but the "correct" URL is 1. The origin server redirects URLs 2 and 3 to URL 1 using HTTP 301 response. Then it should be fairly safe to use the entire URL with the query string as a cache key. When users access URL 2 a few times, then quid can go to the origin server only once, and afterwards return 301 response from cache. Is this a good assumption? Do I need to add Expires header and max-age to the 301 response to make this work? E -----Original Message----- From: Amos Jeffries [mailto:squ...@treenet.co.nz] Sent: Sunday, February 01, 2009 4:58 PM To: Maoz Cc: Amos Jeffries; squid-users Subject: Re: [squid-users] ignore question mark in url > been there, done that..... didn't find any relevant information there. > > > On Sun, 2009-02-01 at 23:31 +1300, Amos Jeffries wrote: >> Maoz wrote: >> > hello, >> > how can I ignore the question mark in url >> > I'll explain: >> > Treat the url until the question mark as object. >> > >> > www.domain.com/index.jsp?aaa=1 >> > >> > will be the same object as: >> > >> > www.domain.com/index.jsp?aaa=10 >> > >> > and >> > >> > www.domain.com/index.jsp?aaa=2&ggg=3 >> > >> > thanks >> > >> >> http://wiki.squid-cache.org/ConfigExamples/DynamicContent >> >> Amos > Ah, sorry, now that I've woken up and re-read your request I see you were asking something different to what I though. You want the experimental storeurl controls from Squid-2.7. http://www.squid-cache.org/Versions/v2/2.7/cfgman/storeurl_rewrite_program.h tml Note that duplicating dynamic URLs like that is very dangerous procedure: - for web providers it drops them into the nasty bandwidth wasting hole youtube is currently in. - for cache operators it drops you into the liability of getting it right and forever having to check its still right. Big issues when it goes even slightly wrong. Amos
