search

Tectu / malloy

A cross-platform C++20 library providing embeddable server & client components for HTTP and WebSocket.
BSD 3-Clause "New" or "Revised" License
68 stars 8 forks source link

Does the websocket handler need the full `request`? #38

Closed 0x00002a closed 3 years ago

0x00002a commented 3 years ago

Currently the full request is parsed and then handed off to the handler on the server side. I'm wondering, do we actually need to do this, or is the header enough? Is it possible that the request body could be anything but empty?

Tectu commented 3 years ago

Currently I can't think of any scenario where anything but the header is necessary for handing a request over to a corresponding handler. However, the handler itself of course needs access to the full request, not just the header as it might contain data that needs to be processed (think of the ws_echo example).

Am I maybe misunderstanding the question or the scope/context of it?

0x00002a commented 3 years ago

ws_echo echo's anything written to the stream after the initial connection, the oneshot echo does the same (reads once then echos and closes). I'm thinking about the request passed to the handler which is the request used by async_accept, afaik the websocket spec says nothing about the contents of that request and only cares about the headers. Also I found this issue in beast, which suggests it is only message to make the API easier to use (which is fair)

Tectu commented 3 years ago

This can be closed, eh?

0x00002a commented 3 years ago

I think so, unless we want to migrate to passing header in which I'm not sure about. It could be a bit misleading since it will always be an empty bodies request (actually I think since: #51 it is literally just a request constructed from the header) but it integrates with beast that way and I don't see any compelling reasons to change it.