I see, thanks for explaining.

It's true I initially needed httpcache for public pages that requires no
special headers. I understand it can be an issue in a context where these
are required.

I wonder if groupcache could be used only in a way where you can tell peers
to ignore the "load" part.
You would put values in the cache, the group would cache them, spread
values around but no more.
If it doesn't have it, then cache miss and the original requester has to
fetch and fill the cache.
But maybe that's not what groupcache was intended for. I have to read more
on that :)


On Sun, Jan 26, 2014 at 11:33 PM, Dvir Volk <notifications@github.com>wrote:

> In memory.go:
>
> > @@ -2,26 +2,46 @@ package httpcache
> >
> >  import (
> >  	"errors"
> > +	//"fmt"
> > +	"github.com/golang/groupcache/lru"
>
> The logic of groupcache is more or less this:
> given that there are N peers in a network and each is responsible for
> holding and fetching 1/N of the keys. And your instance of the program is
> one of those peers. So it needs a cached key, and does:
> 1. do I have it in my "hot cache" (an LRU for super popular keys,
> regardless of the owner)? if so return it.
> 2. Am I the "owner" of it? If so return it if it's in cache, else load it,
> cache it and return it.
> 3. If not, then find the responsible peer, and ask him for it. They should
> load it or fetch it and give it to us, and we store it on the "hot cache".
> 4. If fetching from the peer failed, just load it ourselves and store in
> hot cache. this doesn't make us responsible for it, and we don't tell
> anyone about it.
>
> Now, as you can see, this assumes functional symmetry between all peers:
> given a key, any peer should be able to know how to load and store it.
>
> If we're talking about caching http requests, this means any hashing must
> be symmetric - if I ask a peer for a key and they don't have it hot, they
> need to load it, i.e make the request on our behalf. So a one way hash is
> no good. And given for example http auth headers, just the url isn't enough
> too.
>
> So it feels kinda wrong I guess. But if you ignore custom headers and
> allow only the URL to be the key, then we can certainly make use of it.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/StalkR/httpcache/pull/2/files#r9177938>
> .
>