Open rbjorklin opened 3 years ago
Sounds good to me; a PR would be great. Mainly it would be useful if you could look through RFC6455 and ensure that the normalisation scheme matches module Http
or Https
. If so, it's fine to reuse them, but are often subtle differences.
The WebSocket Protocol attempts to address the goals of existing bidirectional HTTP technologies in the context of the existing HTTP infrastructure; as such, it is designed to work over HTTP ports 80 and 443 as well as to support HTTP proxies and intermediaries, even if this implies some complexity specific to the current environment.
https://datatracker.ietf.org/doc/html/rfc6455#section-1.1
It's also designed in such a way that its servers can share a port with HTTP servers, by having its handshake be a valid HTTP Upgrade request.
https://datatracker.ietf.org/doc/html/rfc6455#section-1.5
ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
The port component is OPTIONAL; the default for "ws" is port 80,
while the default for "wss" is port 443.
https://datatracker.ietf.org/doc/html/rfc6455#section-3
It looks to me like they intentionally made it fully compatible. I'll get a PR going.
I have found my way over here after trying to use https://github.com/vbmithr/ocaml-websocket and realizing that
ws://
andwss://
from RFC6455 are not supported. The library seems to work correctly with websockets when usinghttp://
orhttps://
though so this seems to be mostly a cosmetic issue that might be easily sorted by changing this into:Would this be acceptable?