[squid-dev] Digest related question.

[Jack Bates]

On 15/03/15 07:03 PM, Eliezer Croitoru wrote:
> Hey Jack,
>
> Thanks for the links and the help.
> I have started working on a pesudo for a way to test\implement some of
> the ideas but it is still very far from reality.
>
> The basic code is at:
> http://www1.ngtech.co.il/paste/1292/
>
> Which means that if I do trust the source domain I will try to analyze a
> head request first before any decision.
> (there should be a way to override the request redirection or any other
> thing we would want to do with it)

Is trust an issue?
Assuming you populate the database
with digests that you compute yourself.
If an origin sends a Digest header
and you rewrite the response so a client gets a matching file,
do you need to trust the origin?

> An option would be to add the url into a DB with one to many and many to
> one relationship.
> And since the pesudo code should be the first step before StoreID helper
> run-time, StoreID in place can apply an internal address per a digest of
> choice or even multiple choices.
>
> My main concern until now is that if squid would have the cached object
> in a digest url form such as:
> http://digest.squid.internal/MD5/xyz123"
>
> Squid would in many cases try to verify against the origin server that
> the cached object has the same ETAG and MODIFICATION time.
>
> I am unsure yet on how to "resolve" this issue in an elegant way which
> would not violate the RFCs.

Good point.
When the Traffic Server plugin checks if the file is already cached,
I don't know off hand if it also checks if it's valid.
The plugin could quite possibly redirect a client
to a URL that must be revalidated with the origin.
But maybe this is still an improvement?
Maybe it's good enough, at least for a first iteration?
The plugin does check that the original URL is *not* cached
before rewriting the response.
In your pseudo code,
can you check that the original URL is *not* cached,
before querying the database with the digest?