Who are you and why are you using my name in your from: field ? Peter.
[EMAIL PROTECTED] wrote: > Hi all, > > I have a problem which I'm hoping someone can help me to sort out. I've > written a module that performs two functions: > > - Authorisation of asset retrieval based on client IP, request URI and > user token. > - Confirmation of (non-)delivery of the requested asset. > > This ties into a back-end over which I have no control. The confirmation > of delivery works by using the module's logging function to check that: > > - the request wasn't aborted (request_rec->connection->aborted) > - the total bytes sent (r->bytes_sent) is the same as the content length > (r->clength). > > This is all fine and dandy, and works like a dream... EXCEPT (you knew it > was coming!) where we have a smart-ass client who downloads byte ranges. > > Now if it were just logging that was being performed here, I wouldn't be > overly bothered about this, but the confirmation of delivery also commits a > financial transaction, and then removes the authorisation record for the > asset. Joe Q Public downloads bytes 0-299 of his 1 meg file, and gets > charged for it, even though he didn't download the whole thing and can't > download the rest of it. > > I've kicked back on this and said that there's not much we can do about it > at the Apache level. If we just don't do the confirmation of delivery on > partial responses, then anything downloaded in parts will never be charged > for. We'd struggle to reconcile what client had downloaded what parts of > what file (and therefore deduce that they had received the complete file), > especially if different child processes dealt with two parts of the same > file. Game over, yes? > > Well, maybe... but I'm wondering if there's something we could do with > shared memory, to store the state of such downloads and reconcile it that > way. Frankly I have no idea, as I've never programmed using shared memory > before. I don't want to have to write an actual file to the file system, > that's just plain messy, not to mention prone to errors (someone deletes > the file, file locking problems, asynchronous I/O...) and a potential > performance hit. > > Can anyone suggest a way around this problem? Is my shared memory idea > workable? Is there another way that I'm just blindly missing? > > As ever, any help would be very greatly appreciated. > > Cheers, > > JT