On Nov 10, 2003, at 19:57, user_Jamesday wrote:
- Technically, isn't a caching proxy server a better idea? That way,
those in France can avoid the transatlantic round trip time increases but still edit the main wikipedia/Wikimedia databases. (Mav, that's something your test didn't show, unless you were doing it from a French proxy service)
A caching proxy that doesn't know the wiki's internal state would just function as a non-caching proxy, which would make it slower to load pages and group all its users behind a single IP address.
Each page can be updated at any time, and we need to be able to show the current version to users, including when they view the page immediately after editing it. Pages may be altered with user-specific information such as the login name, extra links, and various output options for people who are logged in, and talk page update notification for both logged-in and non-logged-in users.
The simplest way to ensure this is to disable caching altogether, and require that every page be reloaded every time. That puts unnecessary strain on the server regenerating and resending unchanged pages as people click around, so we do allow for some caching, with caveats:
The cache-control header is marked to tell proxies *not* to cache pages, because a page sent to one person isn't necessarily the page that would be sent to someone else. The browser can cache, but is told to re-request the page every time, so that the cached page can be rechecked as to whether it's current. If it is current we don't have to regenerate the page or wait for it to download, but there is still a round trip to the server for every hit.
'Plain' page hits by non-logged-in users are cached on the server and the cached version is sent out without additional rendering if and only if the wiki knows it's an okay match. (Page hasn't changed, non-logged-in user with no talk notification.) These cached pages are also sent compressed if possible, which saves on bandwidth.
-- brion vibber (brion @ pobox.com)