Add simple HTTP server for HTML5 debugging

[Nallebeorn]

Godot version:
3.0 (stable)

OS/device including version:
Windows 10, Chrome 63

Issue description:
Using the Run in project shortcut to launch games doesn't work with Chrome. It just says Failed loading file 'tmp_export.wasm' The console displays a more detailed error message:

Failed to load file:///C:/Users/(username)/AppData/Local/Temp/Godot/tmp_export.wasm: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.
loadXHR @ tmp_export.js:324

And an equivalent error for the .pck. Firing up a simple python -m http.server instance in that directory, and accessing that through Chrome works fine, so the issue is definitely with Chrome's file:// policies. Firefox has no problems with this, so I guess Chrome is more restrictive here.

Would it be possible to launch a minimal local web server rather than opening the .html with file:// when running a project in the browser? That should solve the issue.

Steps to reproduce:

• Make sure .html files are set to be opened by Chrome
• Open any project and add a HTML5 export preset
• Run the project via Select devices... -> Run in browser

[Faless]

libwebsockets the library used in the WebSocket module ( #14888 ) also acts as a web server, we can use that instead of implementing our own if other devs agrees.

[mhilbrunner]

Would definitely try to avoid implementing a webserver. @Faless suggestion sounds good at first glance. :)

[GammaGames]

This would be a really handy feature! For now I do the following workaround:

1. Tell the engine to run in the browser
   
2. Get the path and filename for the temporary export from the URL (I am on Linux, so the folder is /home/jlieberg/.cache/godot and the filename is tmp_export.html)
   
3. Start a local server in the export folder (I'm using python3)

cd ~/.cache/godot
python3 -m http.server

4. Go to the server's URL with the filename from step 2. For me, it is http://localhost:8000/tmp_export.html
   

I'm not 100% sure if my export is working correctly, the screen flashes a lot whenever I do try to export to web. It does it when I serve it with npm's http-server module as well, so I don't think it's a server thing. But the files are available!
And you shouldn't have to restart the server unless the export folder changes, just refresh the localhost page after telling it to run the game in the browser.

[Rybadour]

What confuses me is that we have this button that says "Run in Browser" but without a webserver it can't run. Python or NodeJS has some extremely simple webserver implementations that would be trivial to implement. Are you worried about bloat?

[Faless]

but without a webserver it can't run.

Well, with a real browser (e.g. Firefox) you can 😉

Python or NodeJS has some extremely simple webserver implementations that would be trivial to implement.

We don't want to depend on Python nor NodeJS, requiring that for just a web server would be overkill.
As mentioned in the above comment, you can run a web server manually for now, while we work on the solution for 3.2.

[Cammymoop]

For anyone wondering Firefox now blocks loading these files by default too as of version 68 but you can disable it in about:config by setting privacy.file_unique_origin to false

[Zireael07]

As @FelixNemis pointed out above, Firefox now blocks too, so the 'run in browser' editor option is completely useless, requiring us to run a web server by ourselves.

I guess it deserves a priority label or something, otherwise all we get is broken UI/UX.

[Calinou]

@Faless Now that libwebsockets has been replaced by wslay, how would a Web server be integrated? According to its homepage, wslay doesn't provide HTTP functionality on its own.

[Faless]

@Calinou I'll just write a simple HTTP server that can serve file from the file system, without any fancy stuff (eg. connection modes, cookies, extra headers, etc), since we'll just use that for debugging I guess.
Unless there is some strong interest in having an HTTPServer exposed to GDScript...
WDYT?

[Calinou]

@Faless Sounds fine to me 🙂

I can see a few use cases for having an HTTP server exposed to projects, such as exposing a JSON endpoint to retrieve a dedicated server's metrics (e.g. player count) from a Web browser. Still, there are other ways to do this, such as having dedicated servers contact a master server (and expose the information to the Web browser from there). You will most likely want to use HTTPS or HTTP/2 for public endpoints, which implies using a full-fledged (and thus large) Web server anyway.