tor 2006-09-07 klockan 15:12 -0700 skrev Mark Nottingham: > I'm guessing that's the full URL. Yes, of course it is. > It would be nice if there were an > option to ignore the query string for this purpose; > > E.g., if Squid sees > http://example.com/search?q=foo > and finds it's uncacheable, it would then stop collapsing other > requests with the same base, e.g., > http://example.com/search?q=bar A bit hard as it requires keeping a cache of uncacheable content, and to make multiple cache lookups before knowing what to do with the request. Normally query requests is set uncachable by default in squid.conf by the cache directive, making the collapsed_forwarding directive a noop on those requests as it only applies on requests which may be cached to begin with. In accelerator setups which this is primarily targeted for I don't think it's that hard to add some rules telling which query URLs are cachable and which are not if you want to collapse requests for some query URLs. > Even better, a response cache-control extension could control this... Personally I think that only complicates matters. If doing this speculation abour URL relationships then I suspect results is sufficiently good deducing it automatically. Adding a new response directive to hint about this is only relevant in cases where the same base URL sometimes is cachable sometimes not, and having it automatically toggle based on what was last seen is probably optimal as it may be a bit hard for the server to guess what the next request pattern will look like.. Note: Same reasoning can be made about file extensions, directories etc. Question is how far to go into this guessing of likelyhood that the response will be cachable. Currently we don't speculate at all and collapsed_forwarding always assumes responses will be cachable until proven otherwise. Regards Henrik
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
