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
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
|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
9 9 Yutaka Sato <firstname.lastname@example.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