WebFileUploader test help please!

We have been chasing one of those bugs that just does not want to give us enough information to let us fix it.

The problem is in the Webfileuploader. It seems to work without issue on the Macintosh regardless of the Browser (We have tested Chrome, Safari, Opera and Firefox)

But on widows on Chrome: The file uploader stalls. The progress bar goes to 100% and the dialog is NOT dismissed.
On Edge we can see the error code: “Internal Server Error 500”

The app is running at: http://159.89.226.206/upload_test/

I hate to impose on the community to do testing for me–– But I have literally spent a week And I do not have a true Windows environment That I can use regularity.

If anyone could kindly simply try to upload file–It would be greatly appreciated. (If the dialogue That contains the Webfileuploader closes – That means we are getting passed the bug.

Hi Jay,

All my tests are OK, meaning the Webfileuploader windows closes after uploading.
Note that both Windows machines are running in VM (Parallels Desktop) on macOS Mojave.

Details:
Windows 7 (Family Edition, SP1):
. Google Chrome 71.0.3578.98 (64 bits) --> OK
. Firefox 65.0 (64 bits) --> OK

Windows 10 (Family edition, 64bits) :
. Google Chrome 72.0.3626.96 (64 bits) --> OK
. Firefox 65.0 (64 bits) --> OK

Tried on Win 10 and FireFox and it doesn’t close… (Parallels desktop VM on Mojave)

Edge works fine here

Just tested:

  • Mac Chrome. Worked fine as you stated.
  • Windows 10 Chrome 70.0.3538.110 worked but the progress bar went to 100% then to about 75% and then seem to finish.
  • Edge worked fine.

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 73.196.148.120:60548] [client 73.196.148.120] 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 “159.89.226.206”] [uri “/upload_test/index.cgi/8623FFEE06AA5C966FB5EF07B9B01D36479CEA56/upload”] [unique_id “XF2se4Jmw3UZy4B3mie2NwAAAAQ”], referer: http://159.89.2     26.206/upload_test/

Safari on macOS MoHarvey worked OK

Thanks all: I have created a case if anyone is looking at the same issue:

Feedback: 54882

It looks like XojoClouds mod_security goes crazy on some Windows clients.

There are some messages that it can have “False positive“ catches

https://github.com/SpiderLabs/ModSecurity/issues/652
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/827
https://github.com/SpiderLabs/ModSecurity/issues/1804

Wrote the same to the Feedback case

Rodger 2 questions:

  1. Can you upload a very big PDF?
  2. Are you on a true PC or a virtual instance.

[quote=424327:@Jay Menna]Rodger 2 questions:

  1. Can you upload a very big PDF?
  2. Are you on a true PC or a virtual instance.[/quote]
    Jay, what do you consider “very big” ?

@Greg O’Lone 8 Megs fails on Xojo cloud.

We are now running the exact same code with the exact same PDF on AWS (as a test) and it does not fail.

On AWS we have nginx + standalone 64bit app inside docker container, and it works fine.

Sent a 6 Mo PDF and the window did not close on Edge.

Sent a 48 Ko PDF and doesn’t close…

Edge worked las time…

Tried again with Firefox and worked fine. (48 Ko)

Tried the 6 Mo with Firefox. Works

Tried again with Edge with 6 Mo and works…

I’m suspicious of WebFileUploader - see this bug report for example: <https://xojo.com/issue/53053>

SOLVED!

As @Kyryl Pekarov 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.