I've marked the other two questions as answered, properly renamed them and continued with this, it seems to be unrelated since the app now works on WEBrick

So for all this to work, we need:

1. to get the correct js url in the webpage (can confirm by looking at html). If this fails there's a wagn bug.

2. the browser to actually make the request (can confirm by using browser tools, eg in chrome). Unlikely to fail, but could be a browser security configuration issue or something.

3. apache to receive the request (can confirm in apache log). if this fails there may be a network/server configuration issue

4. apache to pass the request on to wagn (can confirm in wagn log, will show up as a request). could also be a server config problem

5. wagn to check the permissions and do the file lookup and return the correct file. If this fails it's a wagn bug, but it would be surprising, because it works locally.

6. wagn to hand a file location back to apache and send it back via mod_xsendfile (see Wagn on Apache)

My hunch is that the problem is somewhere around step 3 or 4. Can you tell me what you're seeing in the logs? Is Apache receiving the requests? Is Wagn?

Still diagnosing the issue. I've setup a couple of VMs testing this issue only, independent of other questions I have. Will post results.

This is not an issue any more. Tested it today in both variations and it was the tmp assets that weren't generated correctly that were the culprit because of 'therubyracer' http://wagn.org/Failing_to_precompile_assets_on_ARM_devices_raspberry_pi_2

I think we can close this.

Sidenote: nginx is much easier to install than apache2. It just works, apache2 just requires so many settings from xsendfile to other options, I never get it right.