problem with echo_before when proxying a server which sends gzipped content
carsten.germer at intolabs.net
Thu Apr 3 15:14:37 UTC 2014
yes, it works with suppressing gzip between nginx and source-server with "proxy_set_header Accept-Encoding "deflate";"
Thanks a bunch!
I was aiming for a solution that preserves the gzip-compression between source and cache, but I'm caching long time, anyway.
> add_before_body / add_after_body
I did look at those before but I'd still have to find a way to get the $arg_callback to the URIs and output them with echo for the whole solution.
Works very fine with the neutered compression, thanks again!
Am 02.04.2014 um 19:21 schrieb nginx-request at nginx.org:
> Date: Wed, 2 Apr 2014 17:46:59 +0400
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx at nginx.org
> Subject: Re: problem with echo_before when proxying a server which
> sends gzipped content
> Message-ID: <20140402134659.GD34696 at mdounin.ru>
> Content-Type: text/plain; charset=us-ascii
> On Wed, Apr 02, 2014 at 02:48:33PM +0200, Carsten Germer wrote:
>> If I append something with echo_after it works fine in browsers
>> and in jQuery.
>> If I prepend anything with echo_before the answer can't be read
>> by browsers, "curl --compressed" throws "curl: (23) Error while
>> processing content unencoding: invalid block type".
>> If I configure Firefox with "about:config" to
>> "network.http.accept-encoding:true" it fixes fixes display in
>> When I look in the network tab of chrome console I see that
>> requesting ".../echo-after/" closes the request after 2Xms.
>> Requesting ".../echo-before" also gets 200 ok but never arrives
>> fully, is shown as "pending" indefinitely.
>> My best bet is, that it has something to do with gzip-compressed
> Something like
> proxy_set_header Accept-Encoding "";
> in relevant location should help.
> BTW, you may try add_before_body / add_after_body as available in
> standard addition filter module instead, see here:
> Maxim Dounin
More information about the nginx