> On 9 Oct 2020, at 22:31, Ian Pilcher wrote:
>
> Currently, the client (browser) sends its request with an Accept-
> Encoding header, but the proxy's request to the server does not include
> that header, so the server returns a 404.
Just to add to my previous reply, I've verified it works as
On 10/9/20 6:15 PM, Nick Kew wrote:
That would appear to be a bug. Indeed, a regression since I did extensive
testing
of the proxy and fixed a number of far-more-arcane bugs some years ago[1].
It seems implausible, and your test with curl seems to contradict it.
I'm not sure I follow this,
> On 9 Oct 2020, at 22:31, Ian Pilcher wrote:
>
>
> Currently, the client (browser) sends its request with an Accept-
> Encoding header, but the proxy's request to the server does not include
> that header, so the server returns a 404.
That would appear to be a bug. Indeed, a regression
On 10/9/20 2:21 PM, Nick Kew wrote:
What do you want to happen?
I need the proxy to include the Accept-Encoding header in the request
that it sends to the server (and pass the compressed response back to
the client). I *may* need the proxy to decompress the response if I
need to do anything
> On 9 Oct 2020, at 18:25, Ian Pilcher wrote:
>
> but I can't find anything about
> proxying an application that serves up compressed content in the first
> place.
This is really a question for the client and the backend server.
The proxy is just the messenger!
What do you want to happen?
I am trying to configure httpd to reverse proxy a Dell iDRAC 8. The
iDRAC will only respond to requests with gzip'ed content; i.e. it
returns a 404 if the request does not include an 'Accept-Encoding: gzip'
header.
$ curl -v http://10.11.173.239/start.html 2>&1 | grep HTTP
GET /start.html
