Feature #2005
closed[PATCH] X-Sendfile-Range header support
Description
I've implemented an X-Sendfile-Range header to be used in conjunction with the X-Sendfile/X-LIGHTTPD-send-file headers that allows for specifying the range of bytes to serve from the file specified by the X-Sendfile header. This header is extremely useful. As one example, it makes pseudo-streaming and FLV from within a FastCGI application trivial, without having to jump through hoops with mod_magnet (as there is no response headers magnet yet in 1.4,) or upgrade to 1.5. This is very important, in my opinion, due to the conflicts with luasocket function names in lighttpd, disallowing the use of something like LUA's memcache module to pass information between the FastCGI app and mod_magnet.
My implementation requires the following header field definition:
X-Sendfile-Range: x y
Where, in this case, x is the first byte to serve (zero-based,) and y is the final byte to serve + 1.
Example:
X-Sendfile-Range: 5 7000
If the X-Sendfile-Range header is absent, functionality is identical in that the entire file is served by default. If it is present, it is parsed and its values are applied to the http_chunk_append_file function. The dynamically defined Content-Length header is also updated with the appropriate Content-Length based on the range given. Finally, the X-Sendfile-Range header is removed after being processed, so that it never makes it to the client.
I've tested this very much locally, and hope to have the attached patch pushed in an upcoming 1.4.x release. The attached patch is against r2522 of the lighttpd-1.4.x branch. Please let me know if you've any questions or concerns. Thanks!
Files
Updated by stbuehler over 15 years ago
- Target version changed from 1.4.x to 1.4.23
Updated by stbuehler over 15 years ago
- Status changed from New to Fixed
- % Done changed from 80 to 100
Applied in changeset r2531.
Updated by stbuehler over 15 years ago
- Status changed from Fixed to Wontfix
- Target version deleted (
1.4.23)
This feature was removed, and we will try #2008 instead, so we don't have different methods for the same feature.
Also available in: Atom