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.