tile38 icon indicating copy to clipboard operation
tile38 copied to clipboard

Published 20 hours ago • verified publisher icon tidwall

WebSocket interface doesn't reply to requests after connection upgrade

Open Kilowhisky opened this issue 2 months ago • 6 comments

Describe the bug I'm not sure if this is a bug or if i'm not using it correctly. I initiate a new WebSocket connection in Chrome and it appears to connect and upgrade the request properly. The problem is that any request I send after that the server doesn't reply and the server log has [ERRO] invalid HTTP request.

To Reproduce Steps to reproduce the behavior:

  1. Checkout this repo: https://github.com/Kilowhisky/tile38-viewer
  2. Run local tile38 using docker based on instructions on the website
  3. Run the react code
  4. Attempt to connect to the server using ws://localhost:9851

Expected behavior I would expect once I have established the WebSocket connection I can just treat it like a telnet connection.

Logs Screenshot 2024-05-05 at 1 43 07 PM Screenshot 2024-05-05 at 1 43 35 PM

Operating System (please complete the following information):

  • OS: Mac
  • CPU: Apple
  • Version: docker:latest
  • Container: Docker

Additional context

Kilowhisky avatar May 05 '24 20:05 Kilowhisky

Actually, re-reading the docs... it looks like websockets aren't designed for multiple messages...

I'll refactor to make use of standard HTTP calls I guess...

EDIT: Great, now chrome wants CORS headers to be present....

Kilowhisky avatar May 05 '24 21:05 Kilowhisky

So for this app I either need HTTP interface to support CORS or WebSockets to support a two way connection.

Both will require a PR...

What do you think? I can make them.

Kilowhisky avatar May 05 '24 22:05 Kilowhisky

I haven't had the chance to take a deep dive into your PR yet. Preflighting seems reasonable, though I wondering about the security ramifications of using Access-Control-Allow-Origin: * by default for directly connecting to a Tile38 instance, particularly from a web browser.

tidwall avatar May 14 '24 17:05 tidwall

Web browsers are the only http clients that adhere to CORS (and require it). Because of that I assumed that it just wasn't being used in browsers before since it wouldn't have worked anyways.

The * is a little more lax than I would have liked but building in a whole array of allowed origins would have been quite the work and also only benefited future use cases.

I just figured if it came up in the future, it could be added then. KISS and all that.

Kilowhisky avatar May 14 '24 18:05 Kilowhisky

Also, web sockets don't follow CORS so any web browser could already open a socket request to tile38. It's inefficient as hell, but it works.

Kilowhisky avatar May 15 '24 04:05 Kilowhisky