Could someone document ns_returnfp while we're talking about it? Titi Ala'ilima Lead Architect MedTouch LLC 1100 Massachusetts Avenue Cambridge, MA 02138 617.621.8670 x309
> -----Original Message----- > From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On > Behalf Of Jim Davidson > Sent: Tuesday, August 19, 2008 8:39 PM > To: AOLSERVER@LISTSERV.AOL.COM > Subject: Re: [AOLSERVER] Data "corruption" with fastpath caching > > Your right, the code snippet below could trip over a race condition as > you've described. But, that's not reason enough to change the > fastpath, it's reason to better document the behavior so folks don't > write code that uses ns_returnfile for temporary, dynamic content. > Although fastpath takes care to be correct in most cases (e.g., > stat'ing the file on each request and serializing read on cache miss), > the "fast" in fastpath is because it's primarily designed to return > simple static content with minimal overhead. > > BTW: I believe the ns_returnfile command didn't use the fastpath > originally -- I think it just opened and sent the content. It was > changed because folks asked for it to go faster I think -- can't > recall. > > Anyway, for your app, it might be easiest to not change your code but > instead write a new ns_returnfile to override the builtin -- maybe > just with open and ns_returnfp. > > -Jim > > > > > On Aug 19, 2008, at 4:00 PM, John Caruso wrote: > > > On Monday 05:53 PM 8/18/2008, Jeff Rogers wrote: > >> russell muetzelfeldt wrote: > >>> fastpath is making assumptions about what means something is the > >>> "same file", and those assumptions are not consistent with unix > >>> filesystem semantics - how is this not a bug? > >> > >> It's not a bug because no one ever said that it *was* strictly > >> following unix filesystem semantics, which isn't even a single > >> thing (ufs is slightly different than nfs, is slightly different > >> than ext2 -noatime, is slightly different than afs, etc.) It is > >> following a particular definition: if the file still exists and has > >> the same dev/inode/mtime/size as it did when you last checked, then > >> it is the same file. This of it as a if-modified-since or if-none- > >> match conditional GET. > > > > Actually that's not analogous, for the same reason that the > > analogies to caching of attributes in NFS, rsync or tar not noticing > > content changes if attributes stay the same, etc, don't apply: > > because this bug can happen *even with two files that have > > completely different names or paths*. Again, in this example...: > > > > set file [open "/var/tmp/myfile" "w"] > > puts $file "ABC123" > > close $file > > ns_returnfile 200 text/plain "/var/tmp/myfile" > > ns_unlink -nocomplain "/var/tmp/myfile" > > > > set file [open "/var/tmp/myotherfile" "w"] > > puts $file "XYZ987" > > close $file > > ns_returnfile 200 text/plain "/var/tmp/myotherfile" > > ns_unlink -nocomplain "/var/tmp/myotherfile" > > > > ...AOLserver will almost always return the contents of /var/tmp/ > > myfile rather than /var/tmp/myotherfile in response to the second > > ns_returnfile. > > > > I think the analogies to other systems aren't really germane anyway-- > > AOLserver's behavior has to be judged on its own merits. But > > adopting that standard, I can't think of any other program that > > would confuse /var/tmp/myfile with /var/tmp/myotherfile. > > > > - John > > > > > > -- > > AOLserver - http://www.aolserver.com/ > > > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED] > > > with the > > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > > Subject: field of your email blank. > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
