Wishlist : Handle xattr, and use it for proxy caching


I was dreaming of an implementation of xattr in nginx. We can determine
the MIME type for a file this way (
CommonExtendedAttributes ). lighttpd (
http://trac.lighttpd.net/trac/wiki/mimetype.use-xattrDetails ) and
apache with and additionnal module (
mod_mime_xattr 0.4 ) are currently
already doing this. Modern operating system are all implementing
extended file attributes.

But then, you can go even further. Why not implement more HTTP header in
xattr ? This way, we could have per-file HTTP header.
user.HTTP_SetCookie → send a cookie on a static file :slight_smile:
user.HTTP_ETag → force an Etag.
user.HTTP_Cache-Control → control caching of the file
user.HTTP_Last-Modified → different last modified than file mtime
user.HTTP_Code → 200, 404, 3xx (could be used with an
user.HTTP_Location xattr)

Now with “Expires”. If the timestamp is in the future, I think it won’t
be a problem, it can be served. But if the time is in the past, meaning
the file isn’t fresh ? We could have many configuration values :
→ direct : nginx just sends the expired file (doesn’t try to interpret
this header)
→ direct_without : nginx sends the file, but doesn’t send the outdated
expires header
→ 410 : HTTP error code (Gone). This way, a file could be kept
available on a server only 3 days, and no more without any external cron
→ delete : file is deleted from disk, answer a 404 error code
→ proxy_refresh : In case this file got caught inside a “proxy_store”
location, we can simply ask the proxy to validate the file again.

This way, we could easily implement a real cache instead of a “mirror on
demand” feature in nginx (yes, I know, there is already ncache). We add
a “proxy_store_xattr” switch to save HTTP headers on the disk as
extended attributes, which then will be served later (including HTTP
Response Code, meaning you can save 404 as 404 in the cache, 301 as
301). Then a switch “proxy_store_requires_expires” to only save if
there is an expires header. Full HTTP/1.1 compliant cache more would be
more difficult to implement.

Any comments are of course welcome.