Am Montag, den 12.10.2009, 18:15 +0200 schrieb Xavier: > On Mon, Oct 12, 2009 at 6:00 PM, Marc - A. Dahlhaus [ Administration | > Westermann GmbH ] <[email protected]> wrote: > > > > They are on different hosts and different carrier networks. > > They get time updates via ntp from the same source. > > System times are sane on this boxes. > > > >> Anyway we are using ust.mtime from libfetch. I would think this comes > >> from http Last-Modified and thus should not cause problems. > >> But I am not sure. I am still trying to understand how this stuff works :) > > > > Thanks Xavier, this information was what was missing in this puzzle for > > me. I sniffed the http headers with tshark and checked what pacman asks > > for per header and what lighttpd is sending back to pacman in response. > > This is definitely a lighttpd bug. It answers with "304 not modified" > > response even if the file was modified because of some missing checks. > > > > Sorry for the noise. > > > > If anybody is interested, this is the corresponding fix for > > lighttpd-1.4.23 which will be in 1.4.24 when it gets released: > > > > http://redmine.lighttpd.net/projects/lighttpd/repository/revisions/2643/diff/branches/lighttpd-1.4.x/src/http-header-glue.c?format=diff&rev_to=2408 > > > > Ah cool, glad to know it's already figured out :) > Wasn't it this bug : http://redmine.lighttpd.net/issues/2047
Yes, that's the one. > The patch linked there look like a subset of your link above. > But that makes sense because the revision fixing the issue seems to be > 2608 or 2609 > and your link above is a diff between 2408 and 2643 > > And don't worry about the noise, it's interesting to know that pacman > doesn't play nicely since 3.3.1 with lighttpd-1.4.23 because of a bug. Got that, thanks for your help with this problem. By the way, i'll post the repo-delta-clean stuff sometime this week after i got around to make a final set of tests. Marc
