Too many "Detected version update refreshing the page" when proxying with Apache

Troubleshooting
1

Hello,

I’m trying to properly set up an Apache2 reverse proxy on Debian 8 or Ubuntu 15.10. Mattermost is already running successfuly inside Docker with its port published on localhost:8605.

I’m using the Apache configuration as shown in https://github.com/mattermost/platform/issues/872 with the minor difference of not using SSL (so all the SSL* Apache directives and the RequestHeader set X-Forwarded-Proto “https” are commented out for the time being). Apache mods enabled: proxy, proxy_connect, proxy_http, proxy_wstunnel.

The problem is that I’m noticing a “Detected version update refreshing the page” console.log message each time I’m navigating from one channel to another (using either Firefox or Chrome), which translates into UI navigation performance being crappy, not working as a single-page-application.

I’m suspecting that something’s definitely wrong with Apache2 proxying, but I’d like some help trying to pinpoint it exactly. I’ve performed a number of steps to narrow down the problem (with no luck):

  • Proxying with Nginx or not proxying at all: of course, everything works as intended.
  • Turning on and monitoring all possible logging (Mm DEBUG logs, Apache logs, JS Console, Browser network tools, HTTP negotiations)
  • Deliberately “breaking” the Apache and Nginx configuration to see what fails (I’ve included an example below) and what ends up in DEBUG logs.
  • I’ve tried all Mm versions between 1.1 and 1.3.

I’ve read the source code of platform/web/react/utils/async_client.jsx around line 63 and monitored the HTTP traffic looking at the X-Version-ID header and comparing the HTTP transactions among proxying with Apache, Nginx or without proxy, but I didn’t notice something weird.

What strikes me most is that the problem doesn’t seem to relate with the WebSocket as I’d expected (and because Firefox, but not Chrome, tends to display the blue-bar complaint about the websocket). I’ve tried manually connecting on the websocket to ensure it’s not blocked. I’ve even tried to deliberately break Nginx WS proxying by using this bad configuration:

server {
server_name my.mattermost;
location / {
proxy_pass http://localhost:8065;
}
}

This config produces (as expected) a lot of “could not connect to web socket” console.log messages, but async_client behaves as intended when navigating different channels.

Unfortunately, I’m starting to run out of (hacking & forensics) ideas and would really appreciate some help, if possible, thanks in advance! :disappointed:

2

Try add

RequestHeader unset If-Modified-Since
RequestHeader unset If-None-Match

to your config file.(in VirtualHost)

since apache compares If-Modified-Since date, and return http 304 without X-Version-ID header if If-Modified-Since date is not too old, you will get “Detected version update refreshing the page” until apache returns http 200.

it would be better if static requests are cached, and only api requests are not cached, but I’m not sure how to do that.(I’ll modify this answer if I find better answer)

and, sorry about my bad english :slightly_smiling:

3

Oh, thank you so much. These Apache directives did the trick. I can improve the configuration for keeping caching for static requests, it will be no problem (using proper Location directives). I will try to post the complete Apache configuration once I finish polishing it a bit more.