Re: Store_url_rewrite for squid 3+

On 09/07/2012 09:13 PM, Amos Jeffries wrote:

> Also, any revalidation requests done later must be done on the
> original request URL. Not the stored URL nor the potentially different
> current client request URL.

This sounds like a very important point that could justify storing the
original request URL -- exactly the kind of information I was asking
for, thank you!

Why do we have to use the original request URL for revalidation instead
of the current one? We use current, not original request headers (we do
not store the original ones), right? Is it better to combine current
headers with the original URL than it is to use the current URL with
current headers?

The store URL rewriting feature essentially assumes that any request URL
that maps to URL X is equivalent and, hence, any response to any request
URL that maps to URL X is equivalent. Why not use that assumption when
revalidating? If we receive a 304, we can keep using the stored content.
If we receive new response content, should not we assume that the stored
content [under the original URL] is stale as well?

Again, I am not trying to say that using original URL for revalidation
is wrong -- I am just trying to understand what the design constraints are.

Thank you,

Alex.
P.S. The above still does not justify storing the rewritten URL(s), of
course.
Received on Sat Sep 08 2012 - 16:19:19 MDT