I have a webstore implemented in FileMaker WebDirect, and generally it works great.
However, on occasion we'll get a report that "the screen is blank". Digging into it, we've figured that it almost always happens with clients who are behind an HTTPS proxy of some sort. These are the kinds of services that take normal HTTPS requests, decode them, then re-encrypt them with a new certificate - in essence, performing a Man in the Middle (MITM) attack, though typically sanctioned by the IT department.
Most upsetting: most of the people behind HTTPS proxies are big corporate customers who are our best clients. So although this affects less than 1% of our users, it's the exact users we do not want to be inconveniencing.
I've dug into the errors and there are a few others having this issue, e.g.
We've had at least one client say "Yes, we had to add an exception so your IP address is exempted from our proxy server", so we are pretty sure that's the core issue.
An additional factor that seems relevant, is that our FileMaker WebDirect server is not running on port 443, but is actually running on port 8080, but our router is doing port mapping.
If you read the default FileMaker WebDirect Apache SSL config file, there are comments like this:
# Direct non websocket traffic heading for /fmi/webd/PUSH over to non websocket proxy rule because
# mod_proxy_wstunnel always adds "Upgrade: websocket" and "Connection: Upgrade" headers over ws://
# ProxyPass mapping even if client isn't requesting to use websockets
RewriteEngine on
RewriteCond %{QUERY_STRING} ^((?!X-Atmosphere-Transport=websocket).)*$
RewriteRule ^/fmi/webd/PUSH http://127.0.0.1:16021/fmi/webd/PUSH [P]
As far as I can tell, this bug requires:
FileMaker WebDirect over HTTPS
On the Server: HTTPS is being mapped from port 443 to another port
On the Client: the client is behind a HTTPS proxy (but not just any proxy! many are fine)
Something to do with the ws: (websockets) protocol
Questions/Ideas:
is anyone here also behind a HTTPS proxy and would be willing to help run a test or two? (The test is basically "go to this URL - does it work"?) Send me a private message.
I haven't run that test lately (and can't easily, since 443 is in use) but from all reports, the bug does not happen in that case. It seems to be the unique combo of these factors...
A big part of the issue is that the client it is most likely to affect is also the one least able to deal with it (big corporations with inflexible IT policies). In a few cases, the client solved the problem, but did not communicate with us what the solution they used. (Did they alllowlist our IP?)
Another problem is that we can't reproduce it ourselves, so debugging it is not within reach.
Here's a thing you can do: if you are running a WebDirect server on macOS:
in the Finder, go to /Library/FileMaker Server/HTTPServer/logs/
open the most recent ssl_error_log.xxxxxx (frustratingly, you can't double click these files since the timestamp is after the dot. But you can drag & drop into Console.app
look for errors like this:
[Thu Aug 05 07:42:03.683056 2021] [proxy:warn] [pid 39813] [client 161.69.XXX.XXX:47261] AH01144: No protocol handler was valid for the URL /fmi/webd/PUSH (scheme 'ws'). If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
[Thu Aug 05 07:42:39.594045 2021] [proxy_http:error] [pid 13229] (70007)The timeout specified has expired: [client 161.69.XXX.XXX:19097] AH01110: error reading response, referer: https://example.com/fmi/webd/database
If you see any of these, then you are probably having the issue too.
