Bug #1346

If-Range: fails with date specification

Added by Anonymous about 8 years ago. Updated about 8 years ago.

Status:FixedStart date:
Priority:NormalDue date:
Assignee:-% Done:


Target version:1.5.0
Missing in 1.5.x:



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

-- blade

Associated revisions

Revision 2000
Added by jan about 8 years ago

added support for If-Range: <date> (fixes #1346)


#1 Updated by jan about 8 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

fixed in r2000 for 1.4.x

#2 Updated by Anonymous about 8 years ago

Thank you.

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.

-- blade

Also available in: Atom