I find it a bit surprising that a websocket request to Sanic ends up in an app.get handler (at least with the http1 server - didn't try asgi), as to my knowledge Sanic does not provide means to handle such requests in any meaningful way (you could respond 101 perhaps but then what?), and if you simply ignore the header, the connection will fail but your handler runs for nothing.
Also, it is not possible to serve GET and websocket (GET+Upgrade) at the same path like so:
@app.get("/")
def index(req):
...
@app.websocket("/")
def websocket(req, ws):
...
Would it be possible to change the routing such that upgrade: websocket requests are considered a different method than GET, or alternatively make the scheme also a part of routing (ws, wss, http and https each being different routing-wise)?
On the front side the same path as the document is convenient:
// Same path (easy peasy)
const ws = new WebSocket(location.href.replace(/^http/, 'ws'))
// Different path
const ws_path = '/ws' // sometimes hard to know in front code
const ws = new WebSocket(new URL(ws_path, location.href.replace(/^http/, 'ws')))
I find it a bit surprising that a websocket request to Sanic ends up in an
app.gethandler (at least with the http1 server - didn't try asgi), as to my knowledge Sanic does not provide means to handle such requests in any meaningful way (you could respond 101 perhaps but then what?), and if you simply ignore the header, the connection will fail but your handler runs for nothing.Also, it is not possible to serve GET and websocket (GET+Upgrade) at the same path like so:
Would it be possible to change the routing such that
upgrade: websocketrequests are considered a different method than GET, or alternatively make the scheme also a part of routing (ws, wss, http and https each being different routing-wise)?On the front side the same path as the document is convenient: