On 2006/09/07, at 4:33 PM, Henrik Nordstrom wrote:
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.
Fair enough, good point.
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..
My goal was more to move configuration off the box and into the hands
of the server, which is useful for shared accelerators. Of course,
there are other ways to achieve that; having response headers for one
object affect another's handling is useful, but does add a lot of
complexity.
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.
Agreed. I was thinking more about a general mechanism using a
template; <http://www.ietf.org/internet-drafts/draft-nottingham-http-
link-header-00.txt>
Cheers,
--
Mark Nottingham
mnot@xxxxxxxxxxxxx
