Receiving 412 Precondition failed for static pages with certain request headers
Added by Anonymous over 11 years ago
Hello,
When requesting a static file from the server (with enabled etag) and the clients sends the following headers:
GET / HTTP/1.1 Host: xxxxxxxxxxxxxx User-Agent: xxxxxxxxxxx Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive If-Modified-Since: Sat, 05 Jan 2013 01:10:06 UTC If-None-Match: "3320126266" Cache-Control: max-age=0
It will receive
HTTP/1.1 412 Precondition Failed Content-Type: text/html Accept-Ranges: bytes Etag: "3320126266" Date: Sun, 20 Jan 2013 13:05:47 GMT Server: xxxxxxx Content-Length: 365 Last-Modified: Sat, 05 Jan 2013 01:10:06 UTC Via: xxxxxxxxxxxxx (my proxy) Connection: keep-alive
If I modify the time stamp in the request header from UTC to GMT everything works. I guess this happens, because lighttpd originally uses GMT timestamps in the response (I analyzed that with "tcpflow" and "telnet" on the server, but my proxy (which I am forced to use...) changes GMT into UTC. The result is, that my browsers send back UTC timestamps causing the error.
The error also goes away, if I remove the If-None-Match/etag from the request header.
So now you could say, that the problem is my proxy. However, as UTC and GMT are basically the same timezone it should work even if a client uses UTC in the request header. Additionally while I could ask my service provider to change the proxy configuration, other users of the website may see this problem, too (I actually have a few error messages in my log files from other clients). In my opinion there is no reason to send back a 412 error here. Is there any way to fix this? I could disable etags, but then I would loose support for gzip compression, as far as I know.
Any suggestions would help. Otherwise I have to think about switching to another webserver which I really do not want.
The lighttpd versions I have running are 1.4.19-5+lenny3 (debian/amd64) and 1.4.28-2+squeeze1 (debian/amd64), both show the same error in these rare cases, but work fine in all the other cases.
The following modules are loaded:
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_redirect",
"mod_rewrite",
"mod_expire",
"mod_magnet",
"mod_fastcgi",
"mod_status"
Replies (8)
RE: Receiving 412 Precondition failed for static pages with certain request headers - Added by stbuehler over 11 years ago
http://tools.ietf.org/html/rfc2616#section-3.3.1
[...]
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception.
[...]HTTP-date = rfc1123-date | rfc850-date | asctime-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc850-date = weekday "," SP date2 SP time SP "GMT"
[...]
So passing UTC is clearly invalid.
Otoh the standard says we should ignore invalid dates for If-Modified-Since...
http://tools.ietf.org/html/rfc2616#section-14.25
If the request would normally result in anything other than a
200 (OK) status, or if the passed If-Modified-Since date
invalid, the response is exactly the same as for a normal GET.
A date which is later than the server's current time is
invalid.
So, I'd say it is a bug in lighty
RE: Receiving 412 Precondition failed for static pages with certain request headers - Added by stbuehler over 11 years ago
I just tested it with a local lighty, and I get a 200 response.
So the 412 status code is probably not coming from lighty - either it is returned by the proxy or a backend behind lighttpd (php, ...).
RE: Receiving 412 Precondition failed for static pages with certain request headers - Added by Anonymous over 11 years ago
I verified this locally on the server via telnet. The request asks for a static file. PHP or any other scripting language is not installed.
GET / HTTP/1.1 Host: xxxxx User-Agent: xxxxx Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive If-Modified-Since: Sat, 05 Jan 2013 01:10:06 UTC If-None-Match: "365239230" Cache-Control: max-age=0
produces 412 error
if I change "UTC" into "GMT", the response is the expected 304 not modified.
Are you sure that you have etags enabled? If I remove If-None-Match from the request, it returns code 200 for UTC timestamp and still 304 for GMT timestamp. So I could "fix" the issue by disabling etags, but would then lose gzip compression for my static files (css/js) which is not acceptable.
RE: Receiving 412 Precondition failed for static pages with certain request headers - Added by stbuehler over 11 years ago
Ah, the etag must match to trigger the broken behaviour.
The current draft for HTTP/1.1 part 4 states: (http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-21#section-5)
In practice, the fields defined in this document are
consistently implemented in a single, logical order, due to the fact
that entity tags are presumed to be more accurate than date
validators.
[...]
it makes sense to ignore the If-Modified-Since when entity tags are
understood and available for the selected representation.
So even if the timestamp doesn't match (or we can't parse it) we could return 304, as long as the etag matches.
RE: Receiving 412 Precondition failed for static pages with certain request headers - Added by stbuehler over 11 years ago
I just committed the fix; it should follow the current draft now.
RE: Receiving 412 Precondition failed for static pages with certain request headers - Added by Anonymous over 11 years ago
Thanks for responding and fixing this so quickly.
RE: Receiving 412 Precondition failed for static pages with certain request headers - Added by sfoerster about 11 years ago
is this fix already availible?
RE: Receiving 412 Precondition failed for static pages with certain request headers - Added by dan.thomas almost 11 years ago
sfoerster wrote:
is this fix already availible?
I've just been trying to work that out myself! This is causing some trouble for our users right now.
Here's the fix being checked into the repo:
http://redmine.lighttpd.net/projects/lighttpd/repository/revision?utf8=%E2%9C%93&rev=2865
It looks like it's destined to go into v1.4.33:
http://redmine.lighttpd.net/projects/lighttpd/repository/revisions/2865/diff/branches/lighttpd-1.4.x/NEWS
However, the most recent release on the homepage is v1.4.32, which was November of last year. Alas, I don't know how release cycles work for Lighty. Anyone have any idea when we might see this released?