On Mon, Nov 16, 2009 at 3:09 AM, Dan McGee <[email protected]> wrote: > > Yes. However, the only way to do this was to add even more flags to > the download (and thus callback). I had a "partial_ok" flag going for > a while in one iteration of the patch, but dumped it when I realized > the issue could be solved by just checking headers correctly. >
You are right, all these flags were getting messy :) >>> 2. http://www.mail-archive.com/[email protected]/msg03536.html - Here >>> we have a lighttpd bug to ruin the day. If we send both a Range: header and >>> If-Modified-Since: header across the wire in a GET request, lighttpd doesn't >>> do what we want in several cases. If the file hadn't been modified, it >>> returns a '304 Not Modified' instead of a '206 Partial Content'. We need to >>> do a stat (e.g. HEAD in HTTP terms) operation here, and the proceed >>> accordingly based off the values we get back from it. >>> >> >> These two issues look completely different. >> The link you gave was about If-Modified-Since not working correctly, >> and lighttpd not returning '304 Not Modified' because of some >> time/timezone issues. >> Besides, this should have been fixed in 1.4.24 which is in arch now. >> I guess you should report your issue to lighttpd :) > > Yeah. the original message was the same problem actually. The poster > of that message didn't diagnose it correctly, and it isn't the linked > issue to lighttpd. However, the lighty issue should be solved in their > Duke Nukem Forever 1.5 release. > Hmm, I am still confused here. Which original message ? Marc : http://www.mail-archive.com/[email protected]/msg03527.html lighttpd issue : http://redmine.lighttpd.net/issues/2047 Both seem to match perfectly : If-Modified-Since issue with DST , fixed in 1.4.24 None of them seem to talk about Range header. Anyway, if it's fixed in 1.5 , it's better than nothing. At least that code is available, anyone can get it from svn.
