uri.parse does not follow RFC 3986 on JS

[keroami]

Current uri.parse does not follow the RFC.
JS new URL("") does not follow that RFC, either.

Specifically, "ws:path" is not split into a scheme and a path. This would be useful for opening a websocket from browser to the server, when connecting to the 'same' host.

As far as I can tell, the erlang ffi uri_string:parse() is following the RFC.

[keroami]

On Discord, Inoas suggested uri is a bit specific for stdlib. That it could be a separate lib (I'd say closer to gleam/http).

[lpil]

Let's use URL on JavaScript 👍

[keroami]

To what extent do you want to be compatible with uri_string:parse? uri.parse is gleam, and feeding strings on both targets to any library that needs a Uri should behave the same. e.g.

let assert Ok(ur) = uri.parse("ws:")

passes on Erlang & JS target a.t.m. but will fail in JS when using new URL("ws:").

[keroami]

and "ws:path" according to URL would have "path" as host. On Erlang, "path" is path. And I want it as path for lustre_websocket because I want to be able to tell people to use "ws:path" to open a websocket on the same host they're already connected to, without the need to know which host (and which absolute path) that is.

maybe that's what the title of this issue should reflect. The RFC is more like the solution that I had in mind (past tense)...

[keroami]

and an example the other way round: "::" is accepted by current uri.parse on JS, but rejected by both Erlang uri_string:parse and JS new URL.

[lpil]

I'm not sure what is best. If you were writing JavaScript today what would you use for connecting to a websocket in the desired way?