A common use case for X-Sendfile is simple authentication - a backend determines if a user should get a file, and if so, fires off an X-Sendfile. In this use case, it makes very little sense for the backend to re-implement the things that lighttpd already does for serving other static files - figuring out and serving Content Type headers, ETags, 304 responses, etc.

Essentially, I'd like a way to tell lighty to "just serve the file the way you'd serve any other static file".

Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics)

Since http_response_send_file() supports HTTP Range requests,X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP,currently using X-Sendfile2 is probably manually generating 206 PartialContent status and Range response headers. A future version of lighttpdmight remove X-Sendfile2. Existing code should be converted to useX-Sendfile, which is easily done by removing all the special logicaround using X-Sendfile2, since the 206 Partial Content status and Rangeresponse headers are handled in http_response_send_file().