On Nov 10, 2003, at 19:57, user_Jamesday wrote:
2. 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)