Hello!
On Mon, Oct 21, 2019 at 12:49:38PM -0500, J.R. wrote:
> > Also note that if you really need to force gunziping for some reason,
> > you can do so out of the box by using an additional local proxying
> > layer with appropriate "proxy_set_header Accept-Encoding".
>
> Yes, that is how I had
> Also note that if you really need to force gunziping for some reason,
> you can do so out of the box by using an additional local proxying
> layer with appropriate "proxy_set_header Accept-Encoding".
Yes, that is how I had it configured before patching, all content
between nginx and the upstream
Hello!
On Sun, Oct 20, 2019 at 12:00:07PM -0500, J.R. wrote:
> Recently I was looking into having my upstream server gzip content
> that is sent to nginx (which is acting as a reverse proxy) to reduce
> local bandwidth. However, I needed to decompress the response so nginx
> could do some manipul
Hello!
On Thu, Oct 17, 2019 at 04:42:54PM -0400, Ansuel wrote:
> I don't know if this is a bug or not but... yes you were right...
>
> All the work should be done in the ngx_http_read_client_request_body
> handler, as it does duplicate the r connection to another address
>
> What confused me is
On Mon, Oct 21, 2019 at 02:56:41AM -0400, tiendungitd wrote:
Hi there,
> > The access log that I see there does not seem to show me what you
> describe.
> Well, I just hightlight what I described, see http://prntscr.com/pm2qhl
Ok. In the first highlighted section, I see a POST which got a HTTP 2
