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?
--
You received this message because you are subscribed to the Google Groups "Metalink
Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/metalink-discussion.
For more options, visit https://groups.google.com/d/optout.