If-Range: fails with date specification
a HTTP 1.1 server has to support If-Range with a regular date specification. Unfortunately, version 1.4.16 fails to do that. Example see below (excerpt from my client's debug log). If-Range and Last-Modified are even a perfect match, but client gets a 200 response instead of "206 Partial Response".
Sun Sep 9 22:43:59 2007|!!|dlcon.cc:426(1098918224) | Request cooked: GET /debian/dists/unstable/main/i18n/Translation-de.bz2 HTTP/1.1 Connection: Keep-Alive Host: debian.netcologne.de Accept: */* If-Range: Tue, 16 May 2006 05:13:16 GMT Range: bytes=2641- User-Agent: Debian Apt-Cacher/0.1 ... Sun Sep 9 22:43:59 2007|!!|dlcon.cc:194(1098918224) | GOT: HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 1101751 Content-Type: application/x-bzip2 Date: Sun, 09 Sep 2007 20:46:56 GMT ETag: "8427839721015606317" Last-Modified: Tue, 16 May 2006 05:13:16 GMT Server: lighttpd/1.4.16
#2 Updated by Anonymous over 9 years ago
But, at the first glance, there is still one thing to improve: AFAICS you just make a string comparisson, but this would be wrong if the client has a newer copy of the file. IMO the server might decode the strings into time_t values or so and only then compare those values.
Also available in: Atom