Gregory Maxwell wrote:
On 9/17/07, Simetrical wrote:
On 9/16/07, Nick Jenkins wrote:
Presumably though if the size of a thumbnail is 0 bytes, then MediaWiki can safely assume that something went wrong, and that the cache is bad. E.g. Would an "if( filesize( $thumbnail ) === 0 )" or similar test help when determining whether to use the cache or not?
Thumbnail caches don't involve MediaWiki at all, do they? The change would have to be made with Squid, I think (which, ideally, would have gracefully refused to cache new things when it hit 0 bytes, rather than caching zero-byte files).
This is a change that I tried to advocate a long while back because of the intermittent issue with zero byte replies (mostly seen with large media files .. non-thumbnail stuff). While we were using the external popup media player I ran an additional squid just for media caching which was configured not to cache tiny files.
Have you a clue why it happens? Usually it would think in connections prematurely closed, but we're giving Content-Length... (this was worked on rfc2616, section 8.1.2.1)
The reason we can't do this everywhere is that certain responses which we really would want to be cached are zero bytes. ... In general anything that isn't cached is a potential outage causing agent.
For example, what if we did not cache zero byte files and I replaced a very widely used image with one which was actually zero bytes long?
You shouldn't be able to ("The file you uploaded seems to be empty..."). No problem about that. However, sometimes 0-size files appear, so maybe we shouldn't be too happily relying on it. Can we make amane report (eg via nagios-wm) when it sends empty files?
On the other hand, we will want to cache empty files coming from action=raw (ie old user css & js) Squids could detect the former because they have Cache-Control, but if we were to patch lighttpd, it's as easy as sending them expired.