severity 400329 important tags 400329 + upstream thanks On Sat 25 Nov 2006, Tim Connors wrote: > > wwwoffle has the setting: > # lock-files = yes | no > # Enable the use of lock files to stop more than one WWWOFFLE process > # from downloading the same URL at the same time (default=no). > > Either way this is set, it is broken. > > If set to yes, it seems that a lockfile only manages to tell the > second process to give up loading the page at all, giving back a HTTP > 500 WWWOFFLE Server Error:
Well, it _does_ stop the additional WWWOFFLE processes from downloading the same URL, exactly as documented; nowhere does it say it does that gracefully. A simple reload after that will fix this, right? The 500 error page shouldn't be cached by your browser... > If set to no, then the first process to hit the cache gets their > download, but the second process only retrieves as much as had reached > the first process at that time. So the second download ends up > incomplete. No error is returned, so it may not even be apparent > until a later date -- hence dataloss. > > Marked as grave because of dataloss, since any webpage using crappy There's only dataloss if you set it to "no", so if it's probable that more than one user will be downloading the same URL simultaneously, then you should set it to "yes" (and expect the 500 error page to appear at those times, and be prepared to hit "reload"). > session management, or submition of forms, etc, ends up being broken > whenever the page is being concurrently loaded in two seperate > pages/processes with either setting, and one copy will not be complete In case of crappy session management, if more than one person is accessing the same pages, you wouldn't want the second (or third etc.) person to wait for the first's download to complete only to view that page, instead of the one belonging to his own session... so in that case the point is pretty moot, and the website simply broken, whatever caching system you use. > or will fail altogether. Most of the rest of the time, a reload ought > to fix it, but this sometimes ends up loading from the browser's own > cache, which has only been half downloaded (I can't seem to convince > opera to drop its version of its cache, and reload from the proxy) Traditionally shift-reload will do that. As the data loss you describe only happens when the lock-files is set to "no", I can't agree that the severity should indeed be "grave"; "important" seems much more appropriate, so I'm downgrading this bug's severity now. The whole point of the lock-files setting is to cope with this situation... Also keep in mind that the primary target of wwwoffle is a single system behind a dialup line, where the chances of multiple browser sessions downloading the same URL simultaneously aren't that large. In the meantime I'll contact the upstream author and try to resolve the 500 server error response, which, although not quite contrary to the documentation, is fairly unexpected (especially given the contents of that page :-) Thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
