WebSocket and relative URLs

[devsnek]

Relative URLs are good, and most assets on the web can enjoy usage of them (images, videos, flash objects, EventSource, etc), but the WebSocket constructor does not support them.

Presumably this is due to requiring a ws or wss protocol, but I would pose that using http and https is actually fine for WebSockets, as it accurately represents the method by which they acquire a connection.

So all together:

• Allow WebSocket to use http(s) protocol URLs
• If not, still allow relative URLs by mapping the protocol instead of throwing

[domenic]

@ricea, thoughts?

[ricea]

WebSocket is a distinct protocol that uses an HTTP handshake. It is not HTTP, and so should not use an HTTP URL.

Having magic behaviour for relative URLs is attractive, but probably too magical. You can always do something like

const url = new URL(relativeURL, location.href);
url.protocol = 'wss';
const ws = new WebSocket(url);

You could even monkey-patch the WebSocket constructor to do this automatically.

[devsnek]

You can always do something like

The point of this issue is kind of that people already do write code like that, and it's quite annoying.

WebSocket is a distinct protocol that uses an HTTP handshake. It is not HTTP, and so should not use an HTTP URL.

Well, the point I was making above was that since the initial negotiation is HTTP, an http scheme url is an acceptable identifier of the connection endpoint. If one takes the url, puts http onto it instead of wss, and fetches it, they should encounter a normal http conversation, albeit one probably ending in a 4xx.

Having magic behaviour for relative URLs is attractive, but probably too magical.

I mean it's just like new WebSocket('/gateway'), that doesn't seem very magical to me. Are you concerned there is some ambiguity about what that code could do?

[ricea]

The point of this issue is kind of that people already do write code like that, and it's quite annoying.

True. I have written code like that, and it certainly is annoying.

Well, the point I was making above was that since the initial negotiation is HTTP, an http scheme url is an acceptable identifier of the connection endpoint.

That's an interesting point I hadn't considered before.

On the other hand, we have a constant problem with people mixing up WebSockets and HTTP, and I don't want to make it any worse.

As a philosophical point, I don't like having two ways to do something. If http://endpoint/ starts to mean the same as ws://endpoint/ then people will spend hundreds of hours on Stack Overflow arguing about which is better.

[devsnek]

@ricea Well, I won't die on the "allow http scheme" hill, but I would like to press on allowing relative urls a bit more. I'm curious what your concern is about this behavior.

[bathos]

It does seem like a weird ceremony for the WebSocket constructor to mandate ws/wss even though it's immediately just mapped to http/https anyway. I remember the first time I set up web socket handling server side years ago that this obfuscation made it harder to develop an initial understanding of how it worked - it's more misleading than not imo.

[annevk]

Yeah, I'm not sure I agree with @ricea here. The ws/wss schemes were not worth the hassle in retrospect. Only results in a bunch of special cases in Fetch and URL. Also, if we had never included ambient credentials in the HTTP handshake I could see migrating away from the HTTP handshake to TLS ALPN, at which point a non-HTTP(S) scheme would arguably be slightly cleaner, but that does not seem feasible now.

(If we accept HTTP(S) schemes though we probably first want to normalize them to ws/wss, for the sake of consistency with the existing url getter. The fetch layer would still normalize them (back) to HTTP(S) schemes.)

[devsnek]

now this is quite interesting... the http scheme hill looks a lot more inviting now. it would be very exciting for changes here can clean up the spec as well.

I do think it would be weird if new WebSocket('https://foo').url was a wss but that's probably a bit far into the weeds at this point.

[ricea]

I realised that allowing HTTP(S) URLs and allowing relative URLs are almost the same thing, since you could do new WebSocket('//example.com/foo') to connect to an arbitrary website using a relative URL. So if we were going to do this, including support for HTTP(S) schemes would be more logical from my point of view.

I still don't think the ergonomic benefit is worth the added confusion, but if some other browser implemented it I wouldn't object.

[devsnek]

I could probably contribute to chromium but webkit and gecko are a bit outside my expertise. @ricea i assume you're responsible for this area of the spec for chromium, any chance of accepting theoretical work here?

[ricea]

I think I'd wait until gecko or webkit ship something before accepting a patch to chromium.

[mkurz]

Webkit implemented this recently and upcoming Safari 17 will ship that feature:

• WebSocket: Allow relative URLs and http(s) scheme WebKit/WebKit#13751
• https://bugs.webkit.org/show_bug.cgi?id=247149

would be nice if others catch up also.

[annevk]

This was fixed by #45.

[qguv]

For folks affected by the change in browser behavior, here's the status as of today (2024-05-10):

• Firefox shipped in 124.0 (released 2024-03-19)
• Safari shipped this in 17 a.k.a. 19616.1.27 (released 2023-09-18)
• Chromium shipped this in 125 (released 2024-05-08)
  • ticket: https://issues.chromium.org/issues/40244242
  • review: https://chromium-review.googlesource.com/c/chromium/src/+/5060558
  • roadmap: https://chromestatus.com/feature/5848709993857024

The previously-mentioned #45 has relevant links to track the implementations.

[ricea]

This is shipping in Chromium 125: https://chromestatus.com/feature/5848709993857024