FileMaker 18 AH01144 WebDirect HTTPS Proxy Bug

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 [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


  • 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.
  • Any idea if this has been fixed in FMS19 ?

What happens if you put WD server on port 443, without port mapping (just for a test)?

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...

You could address the issue with transparency and documentation by providing a tech note along these lines

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
  • 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:

If you see any of these, then you are probably having the issue too.

grep proxy ssl_error_log.* doesn't return anything on my server.

I was able to reproduce the bug by asking a friend who is behind a big corporate firewall to test out my site. Here's a picture of what's going on:

  • We verified that, yes, they are behind a https re-encrypting proxy server
  • The error happens when you interact with a WebDirect UI element (in this case, clicking a button).
  • The McAfee Web Gateway seems to get confused and think that a file download has been initiated, and blocks the communication while "scanning the file"
  • this screws up WebDirect, and the webpage eventually shows this error.
1 Like

More testing: we stopped using PORT mapping, and are now just running FM WebDirect on port 443 as god intended.

But we still see the error. This time, we get a slightly different error message:

McAfee Web Gateway... RuleName block SWF and FLV if Site is Unverified

So now I'm not so sure what the core problem is - maybe there are 2 different bugs?

I wonder what causes McAfee to condier a "site is unverified"?