How come there is only 22 languages in the stats from the db-dumps? Where is the rest? is there a techincal reason or is it just a practical issue, or is it simply that not enough people have wnated to see them?

just wondering

Lightning

Tomos at Wikipedia wrote:

Brion-

I use several different combinations of IE and Windows, but Win 98 2nd ed. and IE 6, Win XP and IE 6 seem to cause the problem. XP & Netscape 7 does not. I will send you further details via email.

After some time spent with a Win98 box and a packet sniffer, I think I've found the problem.

The presence of this line in our HTTP response headers:

Vary: Accept-Encoding

causes IE6 to avoid caching the page. I've disabled it on ja.wikipedia.org, please confirm if the behavior is changed for you.

The intent of this line is to keep proxy servers from re-serving gzip-compressed cached pages to clients that don't advertise gzip support. It shouldn't really matter, though, as we also tell proxies to only re-serve pages to the original requesters as a protection against leaking logged-in users' pages to other people (who would then see the wrong user name, etc). (Further, compressed output is not yet supported except through the anonymous user page cache, and is not enabled on the server that ja.wiki is running on.)

I don't _think_ it will be problematic to remove it.

I'm pretty sure our usage is in accordance with specs, though. Extract from RFC 2616, which defines HTTP 1.1:

------------------------------------ 13.6 Caching Negotiated Responses

Use of server-driven content negotiation (section 12.1), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. See section 14.44 for use of the Vary header field by servers.

A server SHOULD use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known as the "selecting" request-headers.

When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request. ------------------------------------

IE is technically not out of specs as far as I can tell; it seems to err on the side of caution of that "MUST NOT" by just not caching anything instead of doing the checks to determine matching. :P

-- brion vibber (brion @ pobox.com)