Hi,

In message <_A3356@delegate-en.ML_> on 07/05/06(02:16:26) I wrote:
 |The text is gzipped in the upstream proxy and passed to the filter
 |without gunzipped in this case.  DeleGate does gunzip the response
 |data when it interprets the data for cache, filter, MOUNT or so.
 |But in this case, it does not recognize the gunzip is necessary.
 |This problem is caused in 9.2.3-pre4 in which I postponed inserting 
 |(possibly unnecessary) CFI filter untill it see the response data.
 |The necessity of gunzip is detemined at the point of request relaying
 |when Accept-Encoding to be sent to the upstream-proxy or origin-server
 |is determined.  One of cahce, unconditional filter, or MOUNT need to
 |be activated in the point.  The most simple way will be activating
 |cache with short expiration (1 second) as this for example.
 |
 | CACHE=do EXPIRE=1s
 |
 |Or you can (should) stop doing gzip for text data in your upstream-proxy.
 |If it resides near of your DeleGate, doing gzip/ungzip text data between
 |the DeleGate and the upstream-proxy will be useless and might decrease
 |the performance.

A mystrey is why you see the problem not with all web servers but with
only restricted servers.  The only reason I can figure out is that
your upstream-proxy does gzip encoding for only restricted servers
including www.google.fr.


 |Anyway it will be fixed as the enclosed patch in the next release.
 |(it disables gzip in the upstream-proxy when with CFI and even when CFI
 |is conditional, thus it acts as 9.2.3-pre3 or former)

It is not correct.  DeleGate does not suppress the gzip in the origin
server or an upstream proxy, but do supress unrecognizable encoding
except gzip.

Cheers,
Yutaka
--
  9 9   Yutaka Sato <pfqcabdyi-mxhgu4yuz33w.ml@delegate.org> http://delegate.org/y.sato/
 ( ~ )  National Institute of Advanced Industrial Science and Technology
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller