Problem encountered with WebAssembly exporter and HTTP request calls.

[stubbsy345]

Operating system or device, Godot version, GPU Model and driver (if graphics related): OSX, Godot 3.0. build: ea37f44ec

Issue description: When ran locally the HTML request works well returning the expected response. However, when using the WebAssembly export the game fails to load and you get the following error:

**ERROR**: pre-main prep time: 4 ms
let it go dude!
**ERROR**: Calling stub instead of sigaction()
Successfully loaded index.pck/project.godot or project.binary
Init OS
Init Audio
Init VS
Init Physicsserver
WARNING: not found: physics/2d/thread_model
OpenGL ES 3.0 Renderer: Mozilla
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
close index.pck flags 1
Loaded certs from 'res://ca-bundle.crt':  171
**ERROR**: exit(0) implicitly called by end of main(), but noExitRuntime, so not exiting the runtime (you can use emscripten_force_exit, if you want to force a true shutdown)

my .crt file is included in the export and the project runs well locally. So I don't know what the problem is.

It then says the programme is slowing down my browers. If I click 'stop it', the following error function appears:

**ERROR**: enlarged memory arrays from 16777216 to 33554432, took 1 ms (has ArrayBuffer.transfer? false)
No file exists

EDIT: it is worth saying that the WebAssembly export works well if I remove code that make calls to the server.

Steps to reproduce: Make a HTTP request to a server from a 3.0 project and export project to webassembly. I am using a POST method sending a dictionary and receiving an answer from the server. The connection is being made over port 443 using an SSL connection. For this I have loaded my ca-bundle.crt file to make the secure connection. I am querying if it is a .crt file export issue. I have set my .crt file to be exported in the exporting window.

Link to minimal example project:

[Calinou]

HTTP requests are currently not implemented in the asm.js or WebAssembly platforms (they need to be implemented using the browser APIs, which probably also means the browser's certificate bundle will be used instead).

[stubbsy345]

Oh okay, is there any documentation on how to do this? Also is there a plan to implement the HTTP requests into the above platforms? Does the same stand true for 2.1.4 and the asm.js exporter or is this just an issue with 3.0? Thanks for your help.

[Calinou]

Oh okay, is there any documentation on how to do this?

It's probably not trivial to make HTTP requests work with the same API in both native and Web exports.

Also is there a plan to implement the HTTP requests into the above platforms?

Yes, it may not be done in time for 3.0, but it could land in a future release.

Does the same stand true for 2.1.4 and the asm.js exporter or is this just an issue with 3.0?

This feature is also unimplemented in 2.1.4 and the asm.js platform, it's not exclusive to 3.0.

[stubbsy345]

Okay thanks. That's a massive road block to my project. Do you know of any work around?

[Faless]

@stubbsy345 , depending on what you actually need you might think of using WebSocket (assuming it fits your needs). The implementation is still a work in progress, but you can see examples here https://github.com/Faless/godot-websocket-demo and a custom module here: https://github.com/LudiDorici/godot-lws

[stubbsy345]

Hey, so effectively what I need to be able to do is connect to a server that contains JSONs in BLOB storage. However, I also need to be able to connect to another server that contains a bot that we have created that interacts with the game. Is that possible using the websocket functionality? (Unfortunately I don't think I can use the above module as it says HTML5 breaks compilation).

We use an adaptation of the code found here: https://www.reddit.com/r/godot/comments/4f5fkv/returning_json_files_using_httpclient/

I'd really appreciate it if you could give me some tips on how I could adapt this for WebSocket protocol, if it is indeed possible.

[Faless]

@stubbsy345

We use an adaptation of the code found here: https://www.reddit.com/r/godot/comments/4f5fkv/returning_json_files_using_httpclient/

That won't work, unless you rewrite the HTTPClient code to use browser API.

(Unfortunately I don't think I can use the above module as it says HTML5 breaks compilation).

It does (I will hopefully fix that in the future), but you can, for now, use the module server-side to alllow ws:// connections to it (creating a WebSocket server).

The client (browser) will use the demo in https://github.com/Faless/godot-websocket-demo which does not need the module, but is compatible with it, so you'll be able to connect from the client (browser) to your server running the WebSocket server (again, a native Godot instance, compiled with the custom module, running on the server machine).

If you look at the screenshot in the module readme (or below) you can see communication between chromium/firefox running godot for HTML5 and the native server. The screenshot is taken from the exported demo projects. Check the code there for reference. It's hacky, but is probably your best shot for now.

[stubbsy345]

Okay, that may be an issue as one of the servers we can connect to is not created by us and also does not accept web sockets.

That won't work, unless you rewrite the HTTPClient code to use browser API.

How much work is this to do? I work for a small student start up that is trying to develop new tools for education and we have been using godot for our project. We had plans to begin online testing in December using the WebAssembly exporter but we hadn't realised HTTP wasn't initially going to be instigated. Funds are very tight, but perhaps we could pay a C++ developer to build this fix for us. Unfortunately none of our team has any C++ experience.

[leonkrause]

@stubbsy345 Even when HTTP is implemented in the HTML5 platform, browsers follow the same-origin policy for HTTP. If there's a server of a different host that you don't have control over, this can prevent you from sending/receiving data even per HTTP. The servers will have to send Access-Control- parameters in its HTTP headers with values that work for the game host. More details here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Is that something that the relevant servers can be setup to do?

[stubbsy345]

Thanks for your reply. The call I was making was to a bot service that doesn't accept websocket calls. However, I have come up with a solution. I am writing a C# websocket server and hosting it in azure, where I am also going to run the bot through. So I will convert my JSONs to strings and send them through the websocket, then convert back to JSONs at the server. I am happy to share the server code with yourselves and the godot community if you have any use for it.

[stubbsy345]

@Faless it is my understanding that you can send strings using websockets as well as byte arrays. This would be quite useful for me as I can send the JSONs as a string and parse at the server. However, I can't figure out how to do this using the current protocol as 'put_packet' will not accept a string. Is it possible to do this?

[leonkrause]

WebSockets in Godot will currently always send binary data. You can get a UTF8 byte array for a string using "string".to_utf8(), or get a string from a received UTF8 byte array using pool_byte_array.get_string_from_utf8().

[stubbsy345]

Sorry to bother you again. Could you just clear up an issue for me. I understand that to upgrade the connection to a websocket connection a HTTP call must first be made. I would like to be able to access the headers sent in this situation and add some custom ones of my own to send cookie data to the server. However, I believe the handshake is all being taken care for me. Is there a way of accessing this handshake and adapting it for my needs in the protocol used. Thanks.

[stubbsy345]

Also having no luck in connecting to secure ("wss://") websocket, if this isn't implemented it would be really useful to as a lot of browsers and servers will not accept the connection unless it is "wss:/"

[leonkrause]

To use TLS, please give this JavaScript code a try before opening any connections:

Module.websocket = {
    url: 'wss://'
};

You can use the JavaScript singleton to do this assignment. If you make this assignment on the default HTML page (that is, outside the game runtime JS context) instead, replace Module with game.rtenv

For accessing the HTTP headers, as far as I know the handshake is completely invisible to the JavaScript client side, making this impossible.

[stubbsy345]

But surely the handshake is being done with either gdscript or C++ somewhere. Therefore all I want to be able to do is add an extra header to this in order to send cookie data? Similar as can be done using the HTTP functions.

I understand the reasoning behind not providing HTTP for alpha 2 as there is so much to do. But is there any chance it may be a milestone for stable beta release. Websockets are great but for simple tasks such as retrieving save games and storing data in a cloud server it is a bit over kill and a lot more complex to get working. Mainly because most cloud services do not allow an easy endpoint for websockets.

[stubbsy345]

Okay so it seems to connect, but I am not getting any echo from my server. Do I need to instigate StreamPeerSSL in some way to send the data, whenever i try to link it to the PacketPeerStream it crashes the game.

[mhilbrunner]

This should either be closed, seeing as it devolved into a WebSocket support thread that hasn't much to do with the original issue, or be renamed to "Implement HTTPClient in HTML5 platform", if that is wanted / something that can and should be done (the above sounds like maybe this isn't the case). Didn't find any other issue on this.

[LinuxUserGD]

Will Godot 3.1 support WebAssembly high networked multiplayer?

[mhilbrunner]

@LinuxUserGD This is an issue tracker, not for support questions :) Better ask on IRC or Discord.

[leonkrause]

Saw this further up and want to clarify:

surely the handshake is being done with either gdscript or C++ somewhere

All code in the HTML5 platform is compiled to JavaScript (or WebAssembly, which calls into imported JavaScript functions). The browser's JavaScript interface to WebSockets is the global WebSocket object, which does not expose the HTTP handshake.

HTTPClient in HTML5 was tracked as #4226, so closing this as resolved and duplicate