Tried on Win 10 and FireFox and it doesn't close.... (Parallels desktop VM on Mojave)
FWIW WE found this in the Xojo cloud error logs. I have no clue how to read it.
5310 [Fri Feb 08 16:21:15.653718 2019] [:error] [pid 5655] [client 184.108.40.206:60548] [client 220.127.116.11] ModSecurity: Access denied with code 44 (phase 2). Match of “eq 0” against “MULTIPART_UNMATCHED_BOUNDARY” required. [file “/etc/httpd/conf.d/mod_security.conf” ] [line “34"] [id “200003”] [msg “Multipart parser detected a possible unmatched boundary.“] [hostname “18.104.22.168”] [uri “/upload_test/index.cgi/8623FFEE06AA5C966FB5EF07B9B01D36479CEA56/upload”] [unique_id “XF2se4Jmw3UZy4B3mie2NwAAAAQ”], referer: http://159.89.2 26.206/upload_test/
It looks like XojoClouds mod_security goes crazy on some Windows clients.
There are some messages that it can have “False positive“ catches
Wrote the same to the Feedback case
As @Kyryl P suggested: In my case it is a known bug in Apache/ModSecurity (not Xojo). It is particularly problematic with large PDF documents.
Until ModSecurity is patched the answer is to turn off a particular ModSecurity rule. This, of course, creates a whole other set of problems. But, at least the uploads are working.
I would like to point out that it’s not really a bug in mod_security. It’s doing exactly what it’s designed to do.
The issue arises from an attached file (does not have to be a pdf) having a particular sequence of characters, in this case:
Followed by any ascii character. This is the exact pattern that an http post request uses to break up attachments.
Having looked at a few offending PDF files on this case, it appears that the app that is creating these files is not properly encoding that data as simply opening the file in Acrobat Pro or PDFPenPro and saving a new file solves the issue.