Your last patch suggestion seems good, not caching something that looks
like a new file is fully in line with the intent of fastpath and

I'm not sure everyone is commenting on this new patch idea, maybe a
previous idea?

Anyway if the cache is for serving static (and likely older than a few
seconds) content, why cache it until it looks static? I think that is
the basic thrust of the patch. It would be impossible to poison the
cache by accident if you wait until a file ages a few seconds before you
stick it in. 

But the poison is really self-inflicted. The only data on the server
that can be unintentionally exposed is something that made it into the
cache in the first place. Stuff only makes its way into the cache by
filename. So if your application sends out secret files via
ns_returnfile, you could have a problem, but no long lived secret file
will ever fall into this trap by accident, it would have to cease to
exist (giving up its inode) after being place into cache, then a new
file would have to be created and served. All of this assumes that your
webserver process can read the secret file. 

BUT! Please pay attention to this: ns_returnfile is by definition "not
safe" in the context of most webserver APIs. It returns content that is
outside of pageroot. It exposes (to Tcl) an internal API which handles
returning files under pageroot. The reason it is exposed is so that
developers can easily create their own filehandlers and virtual servers.
The internal API handles a handful of annoyingly picky but important and
standard website and HTTP features. It also provides a number of hooks
for customization related to these features. 

tom jackson 

AOLserver -

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.

Reply via email to