Assist: hosting love.js that requires custom headers and mime type support

Help
1

1. The problem I’m having:

I’m trying to host love.js https://github.com/2dengine/love.js

I can host it locally using MAMP/apache but I’m having an issue hosting it using Caddy on my cloud server.

Apache requires two headers to be set, and wasm mime type.

.htaccess

<IfModule mod_headers.c>
  Header set Cross-Origin-Opener-Policy "same-origin"
  Header set Cross-Origin-Embedder-Policy "require-corp"
</IfModule>
<IfModule mod_mime.c>
  AddType application/wasm wasm
</IfModule>

I don’t expect help with love.js itself, I just want to sanity check that I’m doing the caddy equivalent of what is needed for apache.

2. Error messages and/or full log output:

File main.lua  does not exist on disk.
  • So a problem somewhere in my setup
  • curl -vL shows mime type is working
  • query parameters are processed using javascript from URL so look OK to me

3. Caddy version:

v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=

4. How I installed and ran Caddy:

dnf install caddy

a. System environment:

Oracle Linux 8 (RHEL8)

b. Command:

systemctl start caddy

c. Service/unit/compose file:

n/a

d. My complete Caddy config:

love2d.gingerbeardman.com {
        tls email@example.com
        encode zstd gzip
        root * /var/www/love2d.gingerbeardman.com/htdocs
        file_server

        header {
                Cross-Origin-Opener-Policy "same-origin"
                Cross-Origin-Embedder-Policy "require-corp"
        }

        @wasm {
        file
                path *.wasm
        }
        header @wasm Content-Type "application/wasm"
}

5. Links to relevant resources:

2

This is not a log Caddy prints. It’s coming from elsewhere. I also don’t see it in the love.js codebase, so maybe your wasm file expects it?

3

That’s the strange thing. I copy my files from local Apache, where it works, to cloud server caddy and that message is printed in the browser console.

All files are all present and correct. main.lua is inside of a zip called nogame.love that the wasm extracts.

So something about the caddy setup means that the code is not able to find what it expects. That’s my question.

I’ll try local caddy soon, just in case.

4

OK, serving locally via Caddy on https:// works, the weird main.lua error disappears.

Will try to replicate that on my cloud web server.

But TBH I do not see the difference in setup. It’s exactly the same Caddyfile except for the domain name and the root path (caddy has permissions)

5

Found an issue! Made some progress.

I need to set very specific matcher on the .love (.zip) file type.

@love {
    path */play/*.love
}
header @love Content-Type application/zip

Testing all scenarios…

  • this works for the default “nogame.love”
  • but a custom game eg. ?g=mygame.love still fails
1 Like
6

Final issue was to do with my custom game code. The library is really bad at giving errors.

But the mime matcher is the solution.

Closing as solved.

1 Like
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.