Ah thanks. This helps and thanks for jogging my senile memory about the eviction scenario for objects on disk. :)
I'll look into this approach, thanks! On Wednesday, October 31, 2012, Leif Hedstrom wrote: > On 10/31/12 9:45 AM, John Allspaw wrote: > >> Hey all - >> Is there anyone doing logic in ATS to support single-use URLs? >> >> Example: I have an mp3. I want exactly one person (i.e. client download) >> to get at it, and no more. If the download doesn't complete, I'm willing to >> risk that, no more than one download. >> >> Has anyone approached this problem within ATS, or always just handled the >> logic in the origin server? Presumably the object in cache has a reference >> count associated with it that we can check if >1 than deny? >> > > But this would always be a cache miss then ? Or is the idea that the same > user can fetch it multiple times ? If it's the former, why not always go to > origin, and make it non cacheable? If the object is the same, but unique > URLs for each user, I'd take a slightly different approach: > > 1) Generate cryptographically signed URLs, personalized, such that it's > only valid from one client IP (or user cookie or whatever). > > 2) Validate the URL, if not valid for this particular user + URL combo, > deny the request > > 3) Extract the "content" portion of the URL, and use that as the cache key. > > > The cache doesn't keep any "ref count" on disk (you knew that ;), it does > have an LRU for the in memory cache. An object that only gets one hit, but > is cacheable, would get written to disk, but would not be in RAM cache. > > Cheers, > > -- Leif > >
