>>>>> On Mon, 11 Oct 1999 13:18:12 +0400 (MSD), Oleg Bartunov <[EMAIL PROTECTED]> said:
> 1. Do you have some examples on-line to illustrate
> cache-friendly dynamical pages ?
On www.stadtplandienst.de the headers for the graphics have optimal
headers, I think. The headers for HTML could be improved though.
On the other machines where I have prepared everything to be
cache-friendly, I yet have to decide about a good expiration schedule.
And as often, without a pressing need, I haven't yet come around to
finetune it.
> 2. I'm building server with fully dynamic content using
> Apache, modperl and HTML::Mason and would like to implement
> cache-friendly strategy you described. But I have some problem:
> In Russia we have several encodings for russian language
> ( koi8-r - mostly Unix, win-1251 - mostly windows and several
> others). Documents generated in native server's encoding and
> translated to another encoding on-fly depending on several
> parameters (user directly specify port number for example or
> server understand on some logic (by User Agent string for example) what
> encoding would be the best for user). If user directly selected
> port number URL would changed, say http://some.host:8100/ for koi8-r
> and http://some.host:8101/ for win-1251. In such situation there
> are no problem with caching on proxy servers because URL's are different.
> But in case when server automagically recognize encoding of client
> URL stays the same for differnet encodings - just http://some.host/
> and this cause a trouble with proxy. Suppose if user1 from windows machine
> and user2 from Unix request the same document using the same proxy.
This is exactly the same problem for any content negotiation. If you
are using content negotiation, you *must* specify the Vary header as
described in my document. But as soon as you have a Vary header, you
are out of luck with regard to caching proxies because squid is unable
to cache documents with a Vary header (it just expires them
immediately) and I believe there is no other Proxy available that does
handle Vary headers intelligenty. So although you are acting
cache-friendly and correct, the current available cache technology
isn't up to the task.
But as a workaround you can and should work with a redirect.
1. Decide about a parameter in the querystring or in the pathinfo or
in the path that codifies everything you would normally handle by
interpreting an incoming header, like Accept, Accept-Encoding,
Accept-Charset, User-Agent, etc.
2. As one of the first things your program should check for the
precense of this parameter in the requested URI.
3. If it is there, you have a unique URI and can answer in a
cache-friendly way. If it isn't there, you code it into the
received URI and answer with a redirect to the URI you just
constructed.
An example: www.meta-list.net, where we roughly do the following,
where $mgr is an Apache::HeavyCGI object we created earlier and $cgi
is an Apache::Request object.
my $acc = $cgi->param('acc');
if (defined($acc)) {
my $lang;
($mgr->{CAN_UTF8},$mgr->{CAN_GZIP},$mgr->{CAN_PNG},$mgr->{Lang}) =
unpack "a a a a*", $acc;
} else {
my $utf8 = $mgr->can_utf8;
my $gzip = $mgr->can_gzip;
my $png = $mgr->can_png;
my $lang = $r->header_in("Accept-Language");
my $param = $utf8 . $gzip . $png . $mgr->uri_escape($lang);
my $redir_to;
if ($r->method_number == M_GET) {
my $args = $r->args;
$redir_to = $mgr->myurl . "?acc=$param";
$redir_to .= "&$args" if $args;
} elsif ($r->method_number == M_POST) {
warn "We got a POST but we are only prepared for GET!";
return;
}
$r->header_out("Location",$redir_to);
require Apache::Constants;
my $stat = Apache::Constants::REDIRECT();
$r->status($stat);
$r->send_http_header;
}
This code doesn't work exactly as posted because I simplified a few
things to illustrate the point, but I hope it helps clarify things.
--
andreas
