The proxy response input is dechunked as it is retrieved from the back end.
Any chunking to the client is introduced by httpd after filtering.
It may be that the request deflate and inflate filters have comingled a
zlib stream context?
On Tue, Sep 4, 2018, 12:43 Maarten Boekhold wrote:
> Hi,
>
Hi,
But I did try to inflate/rewrite/deflate in my first email... It just
didn't work. I suspect something failed because the data was chunked...
Maarten
On September 4, 2018 20:20:18 "Gillis J. de Nijs"
wrote:
Yes, it is. You can't rewrite something that's gzipped, so you'd have to
Yes, it is. You can't rewrite something that's gzipped, so you'd have to
unzip it first, or - like you did - never have it gzipped in the first
place.
See also http://www.apachetutor.org/admin/reverseproxies where there's a
full reverse proxy scenario configured and explained. It uses the same
Hi all,
I decided to force HTTPD to remove the Accept-Encoding: gzip, deflate
from the request, using:
RequestHeader unset Accept-Encoding
Now the response is properly processed by HTTPD. So it's likely an issue
with one or both of:
Content-Encoding: gzip
Transfer-Encoding: chunked
Is
Hi all,
Apache HTTPD 2.4.34 on Windows 10 downloaded from Apache Haus.
I'm trying to move a corporate application behind a reverse proxy. In
the process, I need to move the path this application is published on, eg:
/webapp1 --> /suite/webapp1
"webapp1" contains a specific JSP that returns an
