You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Matt Zagrabelny <mz...@d.umn.edu.INVALID> on 2021/10/05 15:39:22 UTC

[users@httpd] help with reverse proxy

Greetings,

Running:
dpkg -l apache2 | grep ii
ii  apache2        2.4.48-3.1+deb11u1 amd64        Apache HTTP Server

I am trying to configure a reverse proxy and am following the config file:

/etc/apache2/mods-available/proxy_html.conf

and the website:

http://www.apachetutor.org/admin/reverseproxies

I have a rust web server running locally (127.0.0.1:5050) and am
attempting to serve it via /polaris/

here are my configs:

<VirtualHost *:80>
    AllowEncodedSlashes NoDecode

    LogLevel Debug
    ProxyRequests Off
    ProxyPass        /polaris/ http://127.0.0.1:5050/
    <Location /polaris/>
        ProxyPassReverse /
        ProxyHTMLEnable On
        ProxyHTMLURLMap http://127.0.0.1:5050/ /polaris/
        ProxyHTMLURLMap / /polaris/
    </Location>
</VirtualHost>

 but am getting the following error in my web browser:

"""
Content Encoding Error

The page you are trying to view cannot be shown because it uses an
invalid or unsupported form of compression
"""

Looking at the logs I see:

[Tue Oct 05 10:22:11.247273 2021] [proxy:debug] [pid 7175]
mod_proxy.c(1258): [client 192.168.0.47:42900] AH01143: Running scheme
http handler (attempt 0)
[Tue Oct 05 10:22:11.247302 2021] [proxy:debug] [pid 7175]
proxy_util.c(2438): AH00942: http: has acquired connection for
(127.0.0.1)
[Tue Oct 05 10:22:11.247313 2021] [proxy:debug] [pid 7175]
proxy_util.c(2494): [client 192.168.0.47:42900] AH00944: connecting
http://127.0.0.1:5050/ to 127.0.0.1:5050
[Tue Oct 05 10:22:11.247487 2021] [proxy:debug] [pid 7175]
proxy_util.c(2717): [client 192.168.0.47:42900] AH00947: connected /
to 127.0.0.1:5050
[Tue Oct 05 10:22:11.247631 2021] [proxy:debug] [pid 7175]
proxy_util.c(3183): AH02824: http: connection established with
127.0.0.1:5050 (127.0.0.1)
[Tue Oct 05 10:22:11.247658 2021] [proxy:debug] [pid 7175]
proxy_util.c(3369): AH00962: http: connection complete to
127.0.0.1:5050 (127.0.0.1)
[Tue Oct 05 10:22:11.248442 2021] [proxy:debug] [pid 7175]
proxy_util.c(2453): AH00943: http: has released connection for
(127.0.0.1)
[Tue Oct 05 10:22:11.248477 2021] [xml2enc:debug] [pid 7175]
mod_xml2enc.c(195): [client 192.168.0.47:42900] AH01430: Content-Type
is text/html
[Tue Oct 05 10:22:11.248504 2021] [xml2enc:debug] [pid 7175]
mod_xml2enc.c(269): [client 192.168.0.47:42900] AH01434: Charset
ISO-8859-1 not supported by libxml2; trying apr_xlate
[Tue Oct 05 10:22:11.248735 2021] [xml2enc:debug] [pid 7175]
mod_xml2enc.c(483): [client 192.168.0.47:42900] AH01439: xml2enc:
consuming 10 bytes from bucket
[Tue Oct 05 10:22:11.248753 2021] [xml2enc:debug] [pid 7175]
mod_xml2enc.c(509): [client 192.168.0.47:42900] AH01441: xml2enc:
converted 10/12 bytes
[Tue Oct 05 10:22:11.248760 2021] [xml2enc:debug] [pid 7175]
mod_xml2enc.c(483): [client 192.168.0.47:42900] AH01439: xml2enc:
consuming 270 bytes from bucket
[Tue Oct 05 10:22:11.248770 2021] [xml2enc:debug] [pid 7175]
mod_xml2enc.c(509): [client 192.168.0.47:42900] AH01441: xml2enc:
converted 182/280 bytes
[Tue Oct 05 10:22:11.248777 2021] [xml2enc:debug] [pid 7175]
mod_xml2enc.c(509): [client 192.168.0.47:42900] AH01441: xml2enc:
converted 88/133 bytes

it sort of looks like I'm generating a loop, but I'm unaware of where
to fix the issue.

Any suggestions for what to do or next steps?

Thanks for the help!

-m

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


Re: [users@httpd] help with reverse proxy

Posted by Matt Zagrabelny <mz...@d.umn.edu.INVALID>.
On Wed, Oct 6, 2021 at 3:18 PM Nick Kew <ni...@apache.org> wrote:
>
> > Sort of. Chromium is now working, but FF is still reporting the
> > "Content Encoding" issue.
>
> Have you cleared FF's cache?

Well....

Not explicitly. I did use <shift>+<ctrl>+R, which I was under the
impression that that did a full reload and ignored cached pages.

However... https://support.mozilla.org/en-US/questions/1104556

So, I went into the settings and cleared cookies and site data. Which
seemed to fix the problem.

Both Chromium and FF now seem to work. I wonder how long it will work
before it fails. We'll find out!


> Also you don't appear to need mod_xml2enc
> (other pages might, but I'd guess probably not).

Agreed, but...

# a2dismod xml2enc
ERROR: The following modules depend on xml2enc and need to be disabled
first: proxy_html

So, I guess I'll leave it enabled for now.

> If you simply don't load it in the server you'll simplify things.
> In fact it looks as if mod_xml2enc needs updating to work
> correctly with HTML 5's <meta charset> nonsense!

Ha.

Thanks for all the help and expertise, Nick. I appreciate it!

Stop by Duluth, MN for a beer sometime. :)

Best,

-m


-m

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


Re: [users@httpd] help with reverse proxy

Posted by Nick Kew <ni...@apache.org>.

> On 5 Oct 2021, at 22:43, Matt Zagrabelny <mz...@d.umn.edu.INVALID> wrote:
> 
> GET /polaris/ HTTP/1.1
> Accept-Encoding: gzip, deflate

> HTTP/1.1 200 OK
> content-encoding: gzip

OK, that looks like it should be fine for the browser and server.

It looks like you're dealing with compressed data.
If the proxy is to rewrite links, it needs to be uncompressed for that.
mod_deflate can deal with that, but it adds complexity and processing
overhead, so you're probably better-off disabling compression -
which is what the Unset Accept-Encoding is about.

However, if compression were indeed at the root of the issue,
I'd expect to see something different in the log.  I have a distant
recollection of a bug dealing with that, but thought it was long-fixed.

> $ curl -v http://127.0.0.1:5050/

Looking at that, all is well, and you've got the document body, and you
do indeed have links correctly rewritten from /foo to /polaris/foo.
That's with no compression anywhere in the transaction.

> Sort of. Chromium is now working, but FF is still reporting the
> "Content Encoding" issue.

Have you cleared FF's cache?

Also you don't appear to need mod_xml2enc
(other pages might, but I'd guess probably not).
If you simply don't load it in the server you'll simplify things.
In fact it looks as if mod_xml2enc needs updating to work
correctly with HTML 5's <meta charset> nonsense!

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


Re: [users@httpd] help with reverse proxy

Posted by Matt Zagrabelny <mz...@d.umn.edu.INVALID>.
Hi Nick,

Thanks for the reply!

On Tue, Oct 5, 2021 at 3:02 PM Nick Kew <ni...@apache.org> wrote:
>
>
>
> > On 5 Oct 2021, at 16:39, Matt Zagrabelny <mz...@d.umn.edu.INVALID> wrote:
> >
> > I am trying to configure a reverse proxy and am following the config file:
>
> What you've described looks basically OK (the complexity may or may not be
> necessary).

Okay. Thanks for looking. I don't really know what I need and what I
don't at this point. I'm somewhat of a reverse proxy noob.

  The debug output from your log doesn't obviously indicate a problem.
>
> > """
> > Content Encoding Error
> >
> > The page you are trying to view cannot be shown because it uses an
> > invalid or unsupported form of compression
> > """
>
> Can you view the actual HTTP headers your browser is getting?

Sort of. Firefox no, but Chromium yes.

Firefox does not report any network traffic in the devtools tab. So... ???
BTW, this is the browser that yielded the "Content Encoding Error" in
my initial email.

Chromium shows the transfer of one document, but the "application"
still isn't working under Chromium. It is just a blank web page. Here
are the headers for that document:

GET /polaris/ HTTP/1.1
Host: zeus.z.net
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/93.0.4577.82 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: admin=true; username=foo

HTTP/1.1 200 OK
Date: Tue, 05 Oct 2021 20:14:55 GMT
Server: Apache/2.4.48 (Debian)
last-modified: Thu, 30 Sep 2021 15:24:02 GMT
accept-ranges: bytes
content-encoding: gzip
content-type: text/html;charset=utf-8
etag: "526ea4:1be:6155d692:3288efb4"
content-disposition: inline; filename="index.html"
Content-Length: 436
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive


> A commandline tool like curl or lynx will report them if your regular
> browser won't.

Thanks for the hint. Here are some cURLs...

Here is the output when talking to the application:

$ curl -v http://127.0.0.1:5050/
*   Trying 127.0.0.1:5050...
* Connected to 127.0.0.1 (127.0.0.1) port 5050 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:5050
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-length: 446
< last-modified: Thu, 30 Sep 2021 15:24:02 GMT
< accept-ranges: bytes
< content-type: text/html
< etag: "526ea4:1be:6155d692:3288efb4"
< content-disposition: inline; filename="index.html"
< date: Tue, 05 Oct 2021 20:08:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
<!doctype html><html><head><title>Polaris</title><meta
charset="UTF-8"><link rel="icon shortcut" type="image/png"
href="/favicon.c84c16f1.png"><link rel="mask-icon"
href="/mask-icon.17698134.svg" color="#cb8bbe"><link rel="stylesheet"
type="text/css" href="/index.0b276229.css"><link rel="stylesheet"
type="text/css" href="/index.0eb5d501.css"></head><body> <div
id="vue-container"></div> <script src="/index.d9f7726e.js"></script>
</body></html>


...and here is the output when talking to the apache gateway:

$ curl -v http://zeus.z.net/polaris/
*   Trying 192.168.0.42:80...
* Connected to zeus.z.net (192.168.0.42) port 80 (#0)
> GET /polaris/ HTTP/1.1
> Host: zeus.z.net
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Tue, 05 Oct 2021 20:14:11 GMT
< Server: Apache/2.4.48 (Debian)
< last-modified: Thu, 30 Sep 2021 15:24:02 GMT
< accept-ranges: bytes
< content-type: text/html;charset=utf-8
< etag: "526ea4:1be:6155d692:3288efb4"
< content-disposition: inline; filename="index.html"
< Vary: Accept-Encoding
< Content-Length: 471
<
* Connection #0 to host zeus.z.net left intact
<html><head><title>Polaris</title><meta charset="UTF-8"><link
rel="icon shortcut" type="image/png"
href="/polaris/favicon.c84c16f1.png"><link rel="mask-icon"
href="/polaris/mask-icon.17698134.svg" color="#cb8bbe"><link
rel="stylesheet" type="text/css"
href="/polaris/index.0b276229.css"><link rel="stylesheet"
type="text/css" href="/polaris/index.0eb5d501.css"></head><body> <div
id="vue-container"></div> <script
src="/polaris/index.d9f7726e.js"></script> </body></html>

Again, I'm confused why the curls and chromium seem to work, for the
first document, at least, but firefox is choking. Anyhow...


> There's a confusing issue here: the word "Encoding" can refer to
> three different things in the context of HTTP.  Your error message
> appears to refer to the Content-Encoding header.  What we need
> to diagnose is what the backend sets, what the browser gets, and
> what happens between them.
>
>
> Meanwhile, does it fix the problem if you add to the config section:
>         RequestHeader Unset Accept-Encoding ?

Sort of. Chromium is now working, but FF is still reporting the
"Content Encoding" issue.

Also, I had this reverse proxy working yesterday - or so it appeared.
Long story longer...

Setting up the reverse proxy to be served out of the webroot (/)
seemed to make serving out of another location (/polaris/) work.

Buf if I make innocuous changes to the configs then eventually the
reverse proxy breaks and I get a blank page. With me making changes
over the past several days it has felt flaky and inconsistent as to
how reliable the reverse proxy is able to serve the application.

That is what it feels like now. So I am reluctant to say that the
above "RequestHeader Unset Accept-Encoding" is the silver bullet.

Let me know what you think.

Thanks!

-m

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


Re: [users@httpd] help with reverse proxy

Posted by Nick Kew <ni...@apache.org>.

> On 5 Oct 2021, at 16:39, Matt Zagrabelny <mz...@d.umn.edu.INVALID> wrote:
> 
> I am trying to configure a reverse proxy and am following the config file:

What you've described looks basically OK (the complexity may or may not be
necessary).  The debug output from your log doesn't obviously indicate a problem.

> """
> Content Encoding Error
> 
> The page you are trying to view cannot be shown because it uses an
> invalid or unsupported form of compression
> """

Can you view the actual HTTP headers your browser is getting?
A commandline tool like curl or lynx will report them if your regular
browser won't.

There's a confusing issue here: the word "Encoding" can refer to
three different things in the context of HTTP.  Your error message
appears to refer to the Content-Encoding header.  What we need
to diagnose is what the backend sets, what the browser gets, and
what happens between them.


Meanwhile, does it fix the problem if you add to the config section:
	RequestHeader Unset Accept-Encoding ?

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