search

mikedeboer / jsDAV

jsDAV allows you to easily add WebDAV support to a NodeJS application. jsDAV is meant to cover the entire standard, and attempts to allow integration using an easy to understand API.
http://www.mikedeboer.nl
MIT License
681 stars 159 forks source link

implement etags in FS backend #145

Closed edrex closed 8 years ago

edrex commented 8 years ago

I just copy and pasted from the fsext implementation, and it seems to work.

I imagine that most implementers will want etags, since they add considerable safety.

Ref: #111

mikedeboer commented 8 years ago

It's not so much about its usefulness, but more about the performance implications. In each PROPFIND on directories, it'll create a hash for each file on the first level of that directory - regardless of its size. This can be a considerably CPU-intensive operation, which is why I don't recommend this for production systems, unless you also implement a decent etag caching mechanism like other NodeJS static file servers probably have already.

edrex commented 8 years ago

Thanks for the explanation, makes sense.

Where would an in-memory cache need to sit in the runtime object hierarchy in order to stick around and be global? It seems based on a quick reading that file nodes get created per-request, so I guess the cache could hang on the tree object?

I could see wanting to have different cache implementations, a simple one invalidating using fs.stat and maybe also an eager one using fs.watch or one of cross platform watchers on npm.

mikedeboer commented 8 years ago

On 17 Feb 2016, at 19:01, Eric Drechsel <notifications@github.com mailto:notifications@github.com> wrote:

Thanks for the explanation, makes sense.

Where would an in-memory cache need to sit in the runtime object hierarchy in order to stick around and be global? It seems based on a quick reading that file nodes get created per-request, so I guess the cache could hang on the tree object?

The tree object would be a very good place indeed. The node path would be the cache entry identifier, along with the mtime. Or something else that’s smarter.

I could see wanting to have different cache implementations, a simple one invalidating using fs.stat and maybe also an eager one using fs.watch or one of cross platform watchers on npm.

Yeah, that’s possible or be able to pass in ‘cacheOptions’ to the tree/ server instance to configure the caching behavior. Depends on what get implemented.