Mailing List Archive

Reverse proxy for app that only serves compressed content
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 HTTP/1.1
> < HTTP/1.1 404 Not Found

> $ curl -v -H 'Accept-Encoding: gzip' http://10.11.173.239/start.html 2>&1 | grep HTTP
>> GET /start.html HTTP/1.1
> < HTTP/1.1 200 OK

I've found a number of articles about using the proxy to compress
content on its way back to the client, but I can't find anything about
proxying an application that serves up compressed content in the first
place.

I this possible?

--
========================================================================
In Soviet Russia, Google searches you!
========================================================================

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Reverse proxy for app that only serves compressed content [ In reply to ]
> On 9 Oct 2020, at 18:25, Ian Pilcher <arequipeno@gmail.com> 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? To return compressed contents to a Client
that won't accept it, you could have the proxy set the request header.
To decompress contents on the fly, you'd use that filter from mod_deflate.

--
Nick Kew

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Reverse proxy for app that only serves compressed content [ In reply to ]
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 with mod_proxy_html.

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.

--
========================================================================
In Soviet Russia, Google searches you!
========================================================================

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Reverse proxy for app that only serves compressed content [ In reply to ]
> On 9 Oct 2020, at 22:31, Ian Pilcher <arequipeno@gmail.com> 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 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.

It also looks like questionable behaviour from the backend: if it's doing
content negotiation (as implied by it reacting to Accept-Encoding) then
this would seem to apply:

" If no Accept-Encoding field is present in a request [...]

Note: If the request does not include an Accept-Encoding field,
and if the "identity" content-coding is unavailable, then
content-codings commonly understood by HTTP/1.0 clients (i.e.,
"gzip" and "compress") are preferred; [...]"


[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=43454 tracks a bunch of
them. Specifically those that weren't already fixed before I introduced it.

--
Nick Kew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Reverse proxy for app that only serves compressed content [ In reply to ]
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, but note that the curl test was showing the
behavior of the backend iDRAC, not the proxy.

> It also looks like questionable behaviour from the backend: if it's doing
> content negotiation (as implied by it reacting to Accept-Encoding) then
> this would seem to apply:

It's a server BMC, so questionable (or worse) behavior is to be
expected.

--
========================================================================
In Soviet Russia, Google searches you!
========================================================================

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Reverse proxy for app that only serves compressed content [ In reply to ]
> On 9 Oct 2020, at 22:31, Ian Pilcher <arequipeno@gmail.com> 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 expected for me.
That is to say, if the client sets Accept-Encoding, the backend receives it.

I guess you must have something in your configuration (possibly set by some
third-party application) that changes it.

--
Nick Kew

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org