translate config server.modules "mod_compress" to "mod_deflate"
accept compress.* directives, but issue DEPRECATED warning trace
mod_deflate differences from mod_compress:
- mod_compress compress.filetype was exact match; deflate.mimetypes is
prefix match (behavior change might compress longer mimetype matches,
which are likely of similar type and compressability)
- mod_compress always sent entire (compressed) file for Range request
mod_deflate will stream compress range result (not stored in cache)
- mod_compress would short-circuit request with 403 Forbidden error
if request file did not exist (stat() failed) (This behavior was
unfriendly to other handlers)
- mod_compress compress.cache-dir layout differs from deflate.cache-dir
layout; file cache should be cleared (or renamed) when migrating from
mod_compress to mod_deflate
- mod_deflate does not issue Vary: Accept-Encoding if request does not
contain Accept-Encoding. The identity response can be cache by
proxies and served to clients. Historically, some proxies disabled
caching if any Vary: response was seen. If the Vary header is
desirable, mod_deflate code which checks for Accept-Encoding and
compression type can be moved down a few lines to be below the
setting of the Vary response header.
reject whitespace following request header field-name and before colon
Such whitespace is forbidden in RFC 7230 Section 3.2.4.
strict header parsing is enabled by default in lighttpd. However,
if explicitly disabled in lighttpd.conf, lighttpd will continue to
accept (and re-format) such field-names before passing to any backend.
UNSAFE: server.http-parseopts = ( "header-strict" => "disable" )
This is NOT RECOMMENDED since doing so disables other protections
provided by lighttpd strict http header parsing.
(thx fedormixalich)
x-ref:
stricter request header parsing
https://redmine.lighttpd.net/issues/2985
unit tests for request processing
collect existing request processing tests from Perl tests/*.t
(test_request.c runs *much* more quickly than Perl tests/*.t)
enable with, e.g.:
extforward.headers = ( "Forwarded" )
or
extforward.headers = ( "Forwarded", "X-Forwarded-For" )
or
extforward.headers = ( "Forwarded", "X-Forwarded-For", "Forwarded-For" )
The default remains:
extforward.headers = ( "X-Forwarded-For", "Forwarded-For" )
Support for "Forwarded" is not enabled by default since intermediate
proxies might not be aware of Forwarded, and might therefore pass
spoofed Forwarded header received from client.
extforward.params = ( # overwrite "Host" with Forwarded value
#"host" => 1
# set REMOTE_USER with Forwarded value
#"remote_user" => 1
)
Note: be cautious configuring trusted proxies if enabling these options
since Forwarded header may be spoofed and passed along indescriminantly
by proxies which do not handle Forwarded.
To remove "Forwarded" from incoming requests, do not enable these
options and instead use mod_setenv to clear the request header:
setenv.set-request-header = ( "Forwarded" => "" )
Other proxy-related headers which admin might evaluate to keep or clear:
setenv.set-request-header = ( "X-Forwarded-For" => "",
"X-Forwarded-By" => "",
"X-Forwarded-Server" => "",
"X-Origin-IP" => "",
"Via" => "",
#...
)
x-ref:
"Forwarded HTTP Extension"
https://tools.ietf.org/html/rfc7239
"Forward authenticated user to proxied requests"
https://redmine.lighttpd.net/issues/2703
new directive cgi.local-redir = [enable|disable]
*disable* RFC3875 6.2.2 local-redir by default.
(behavior change from when local-redir support added in lighttpd 1.4.40)
The reason for this behavior change is that CGI local-redir support
(RFC3875 6.2.2) is an optimization. Absence of support may result in
additional latency in servicing a request due the additional round-trip
to the client, but that was the prior behavior (before lighttpd 1.4.40)
and is the behavior of web servers which do not support CGI local-redir.
However, enabling CGI local-redir by default may result in broken links
in the case where a user config (unaware of CGI local-redir behavior)
returns HTML pages containing *relative* paths (not root-relative paths)
which are relative to the location of the local-redir target document,
and the local-redir target document is located at a different URL-path
from the original CGI request.
x-ref:
RFC3875 CGI 1.1 specification section 6.2.2 Local Redirect Response
http://www.ietf.org/rfc/rfc3875
"CGI local redirect not implemented correctly"
https://redmine.lighttpd.net/issues/2108
"1.4.40 regression: broken redirect (using Location) between url.rewrite-once URLs"
https://redmine.lighttpd.net/issues/2793
secdownload.path-segments = <number>
include only given number of path segments in hash digest calculation
secdownload.hash-querystr = "enable" | "disable"
include the query string in the hash digest calculation
x-ref:
"secdownload.path_elements support"
https://redmine.lighttpd.net/issues/646
"mod_secdownload option to include url GET parameters in md5"
https://redmine.lighttpd.net/issues/1904
directives to set value, rather than append values to headers, env
setenv.set-request-header
setenv.set-response-header
setenv.set-environment
These directives take precedence over the setenv.add-* counterparts
Set a blank value for request or response header to remove the header
(blank value in environment will be set as the value; not removed)
setenv.*-environment is now deferred to handle_request_env hook.
setenv.*-response-header is now processed in handle_response_start hook.
x-ref:
"setenv.add-or-replace-response-header"
https://redmine.lighttpd.net/issues/650
"set-request-header or remove-request-header support for mod_setenv"
https://redmine.lighttpd.net/issues/2295
Loosen local redirect handling in mod_cgi to skip handling as local
redirect if the Location matches con->uri.path, since if the request
is intended to redirect back to the same CGI using the same request
method, path info, and query string, the CGI would logically just
return the final intended response. Loosening this handling avoids a
problem with applications (potentially) accessible through multiple
gateways, where the application is not aware of this specific handling
of Location in the Common Gateway Interface (CGI/1.1), the application
sends abs-path in the Location response header instead of absoluteURI,
and the application expects the client to receive this Location response
header instead of the server to process as a CGI local redirect.
One example of such an application is LuCI,
which sends Set-Cookie with Location: /abs-path
https://github.com/openwrt/luci
(Note that this loose check for matching con->uri.path is not perfect
and might not match if the CGI returned a path with a different case
and the server is on a case-insensitive filesystem, or if the path
returned by the CGI is rewritten elsewhere to a different con->uri.path
before getting to mod_cgi.)
RFC3875 CGI 1.1 specification section 6.2.2 Local Redirect Response
http://www.ietf.org/rfc/rfc3875
x-ref:
"CGI local-redir handling conflicts with LuCI redirect w/ Set-Cookie"
https://redmine.lighttpd.net/issues/2779
"CGI local redirect not implemented correctly"
https://redmine.lighttpd.net/issues/2108
support Transfer-Encoding: chunked request body in conjunction with
server.stream-request-body = 0
dynamic handlers will still return 411 Length Required if
server.stream-request-body = 1 or 2 (!= 0)
since CGI-like env requires CONTENT_LENGTH be set
(and mod_proxy currently sends HTTP/1.0 requests to backends,
and Content-Length recommended for robust interaction with backend)
x-ref:
"request: support Chunked Transfer Coding for HTTP PUT"
https://redmine.lighttpd.net/issues/2156
Aside: must have cmake enable building openssl for tests to pass
due to tests/lighttpd.conf including config options requiring openssl
algorithms in mod_secdownload.c:
(secdownload.algorithm = "hmac-sha1")
(secdownload.algorithm = "hmac-sha256")
$ cmake -L .
$ cmake -DWITH_OPENSSL:BOOL=ON .
$ make -j 4 -k
$ make test
x-ref:
https://blog.lighttpd.net/articles/2006/12/25/1-5-0-goes-cmake/
