Bug #3271
closedresponse headers being set onto 404 responses
Description
Updated lighttpd from 1.4.64 => 1.4.76.
Since then, we noticed that the custom cache headers are also being applied onto the 404 responses.
Example:
setenv.add-response-header sets the cache to 1 week for .css file.
Since we updated towards 1.4.76, we see the cache header of 1 week also onto f.e. a 404 of a css file.
When going back to 1.4.64, no additional cache headers are being added onto the response.
These headers force 404 requests being cached on the client side, and gives issues.
I also don't see a way to say that 404 responses should not have headers set by lighttpd.
Is this a known issue?
Updated by gstrauss 5 months ago
- Status changed from New to Invalid
- Target version deleted (
1.4.xx)
setenv.add-response-header does exactly that: add a response header.
If you are setting caching headers, you should use mod_expire which sets caching headers only for matching 200 OK or 206 Partial Content HTTP responses.
If you need to add something more custom than what mod_expire adds, then you can use mod_magnet and a few lines of lua to set a custom header only for HTTP 200 OK or 206 Partial Content HTTP responses.
Updated by gstrauss 5 months ago
The behavior change you noticed occurred between lighttpd 1.4.65 and lighttpd 1.4.66 in commit cdc88103 and is a fix for the bug in https://redmine.lighttpd.net/boards/2/topics/10583
The commit message includes:
check r->http_status before handling Range so that error handling is
(re-)invoked only if Range handling returns an error status.
The re-invoking of the error handling had the side-effect of wiping out the header added by setenv.add-response-header. That commit intentionally fixed that behavior, although it is not what you wanted since you were misusing setenv.add-response-header when you should be using mod_expire
Also available in: Atom