Hi Nick, Thanks for the reply! On Tue, Oct 5, 2021 at 3:02 PM Nick Kew <niq@xxxxxxxxxx> wrote: > > > > > On 5 Oct 2021, at 16:39, Matt Zagrabelny <mzagrabe@xxxxxxxxx.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@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|