Project

General

Profile

Actions
Copy link

Bug #1346

closed

If-Range: fails with date specification

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

Status:
Fixed
Priority:
Normal
Category:
core
Target version:
1.5.0
ASK QUESTIONS IN Forums:

Description

Hello,

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

Actions
Copy link
 #1

Updated by jan about 17 years ago

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

fixed in r2000 for 1.4.x

Actions
Copy link
 #2

Updated by Anonymous about 17 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

Actions
Copy link

Also available in: Atom