At first glance it looks like this lib is sitting directly on the standard socket API. On emscripten socket API functions are tunnelled through WebSockets. Instead of getting HTTP on top of TCP you would get HTTP on top of WebSocket on top of TCP when using this lib. If you have a normal HTTP server on the other side it would get an initial HTTP message with a WebSocket handshake, and then switch over to WebSocket protocol. But then it would receive HTTP messages wrapped into WebSocket messages, which it will not interpret as HTTP. At least I think that this is the problem. If using the emscripten socket API you basically need a WebSocket backend and your own message protocol.
So I guess there's no way around using something based on the emscripten_wget functions if you want to communicate with normal HTTP servers, however be aware that these use XMLHttpRequests underneath which means you're also restricted by the same-origin-policy: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy Cheers, -Floh. Am Donnerstag, 18. August 2016 19:20:53 UTC+2 schrieb Sander Boer: > > Hi, > I'm a fan of small libs and I found happyhttp via Sean Barrett's (of stb > fame) site. > I have a small test writtten that connects to a url that serves a json and > it works fine in the terminal, the emscripten version complains about the > connection: > > "Firefox can't establish a connection to the server at ws:// > partnerapi.funda.nl/. test.js:5664:19 > The connection to ws://partnerapi.funda.nl/ was interrupted while the > page was loading." > > I guess I could work around it with emscripten_wget, but I wonder if my > approach is fixable. > > thx. > S > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
