From: "Igor Sysoev" <[EMAIL PROTECTED]>
> Here is first part of criticism.
>
> 1. You should not mix proxies and browsers.

It's a question. I've been thinking about this, and decided to refrain from
diving into a long common discussion about features of spiders,
content-feeders, general indexing robots, etc. I wouldn't let reader to sink
in unhelpful features of specific web clients before giving him a real tool
to serve those guys in accordance with his own business requirements (which
could be opposite to my own preferences). I firmly believe that we'll have
to deal with those guys in future. To make it practically helpful we have to
study all possible features of all available web clients on permanent basis,
and keep the community informed about current conditions of network clients.
To date we have too limited number of practically useful facts to stick with
this problem. Even more, we have to double-check some of "well-known" facts,
because the life is going on. New versions of old known web clients are
emerging sometimes. Sometimes people can make mistakes. Everything is going
to be changed on the earth, including the structure of this tutorial.

> 2. As I said you MS Proxy has not mask at all. "^1\.1 " is not a mask.
>    "^Squid/" is incorrect mask.
>    Here is example of Via header of HTTP/1.1 request that goes
>    though Squid, MS Proxy and Oops:
>
>    "1.1 proxy1.domain1.com:3128 (Squid/2.4.STABLE2), 1.0 PROXY2,
>    proxy3.domain3.com:3128 (Oops 1.5.22f1)"
>
> 3. Proxy masks will not help. About 70% of all proxied request are going
>    through Squid and about 15% are going through MS Proxy.
>    So much safe way is to disable proxy requests at all instead of tring
>    to look mask.
>    Besides I suspect that most proxies handle compressed content
incorrectly.
>    I had checked only Squid, MS Proxy and Oops but there are many another
>    proxies. So I think you should disable gzip for all proxied request
>    or enable it for all proxied request if you do not care about old
broswer.
>    mod_deflate by default disable it.

Since Igor fails to explain clearly the features of his "secret knowledge"
in both English and Russian to me, I decided to double-check his information
with the source authorities. Indeed, I was lucky to have a short
conversation on [EMAIL PROTECTED] mailing list with Henrik
Nordstrom, who is developing the Squid proxy. Now I have a real mask for the
Apache::CompressClientFixup handler and some new conditions for successful
implementation of content compression, serving the requests passed through
Squid. I'm going to make the appropriate changes in the text of tutorial as
version 0.02 a few days later together with other changes. Just a little
fragment of my conversation with Henrik Nordstrom for those who care:

From: "Henrik Nordstrom" <X>
Sent: Thursday, June 13, 2002 7:15 PM
Subject: Re: [squid-users] "Accept-Encoding" header

# Squid-2.5 and later supports caching of objects having the Vary
# header.
#
# Squid-2.4 and earlier denies caching of such objects as it cannot
# support more than one entity per URL.

On Friday 14 June 2002 02:43, Slava Bizyayev wrote:

# Should we consider the Squid-2.4 the only version compatible with
# content compression (as long as it denies to cache anything
# accomplished with Vary header)?
#
# Please, could you specify the earliest version, which is working
# this way?
#
# Am I understand correctly that we should refrain from
# doing the content compression on httpd when the request is coming
# through the Squid-2.5 (even we reply with Vary)?

From: Henrik Nordstrom <X>
Date: Fri, 14 Jun 2002 02:57:01 +0200
Subject: Re: [squid-users] "Accept-Encoding" header

# Both are fully compatible with all forms of server driven content
# negotiation (file type, encoding, compression etc), as long as you
# send a proper Vary header indicating such negotiation is taking
# place.
#
# Squid-2.4 and earlier won't be able to cache the reply as Squid-2.4
# and earlier can only support up to one entity version per URL.
#
# Squid-2.5 will cache the reply if possible, and honors the entity
# variance indicated by Vary.
#
# Squid-2.6 will most likely also support ETag, allowing Squid to ask
# the server which if any of the variants it already has is suitable
# for satisfying the new request type. In Squid-2.5 each request type
# is cached individually.
#
# The detection of Vary as uncacheable was added very long ago, probably
# during the Squid-1.X versions.
#
# Regards
# Henrik

Does it make sense? For me it means that every fact which is coming from
Igor Sysoev should be double-checked independently prior to practical usage.
I guess some significant changes in the next version of the tutorial... On
other hand, I feel better, knowing that guys from Squid are caring about our
clients, and life goes on.

> 4. You should not unset "Accept-Encoding". Better way is to set
>    $r->note('disable_gzip').

Sometimes it seems like Igor does not really understand what he is speaking
about. No comments.

> 5. There are two unrelated mod_deflate. First is my mod_deflate for Apache
1.3:
>    http://sysoev.ru/mod_deflate/
>    It'd been tested for one year on loaded sites.
>    Second is expiremental module for Apache2 by Apache tream.

I don't care about your personal affairs and associations. Please, keep it
in your personal records for future historical essays. This is a technical
tutorial.

Thanks,
Slava


Reply via email to