On Mon, Nov 16, 2009 at 3:09 AM, Dan McGee <dpmcgee@gmail.com> 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/pacman-dev@archlinux.org/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/pacman-dev@archlinux.org/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.