Bug 66465 - WebKit won't create WebSocket with IPv6 address
Summary: WebKit won't create WebSocket with IPv6 address
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-08-18 06:51 PDT by Cedric de Saint Martin
Modified: 2023-05-12 17:32 PDT (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cedric de Saint Martin 2011-08-18 06:51:39 PDT
When trying to create a WebSocket object in WebKit using : 

new WebSocket('ws://[::1]:8080')

An error will be raised : 

"WebSocket network error: The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 2.)"


It will do the same for every IPv6 address. It will also break if brackets [ ] are removed.
Comment 1 Alexey Proskuryakov 2011-08-18 10:42:29 PDT
<rdar://problem/9977173>
Comment 2 Alexey Proskuryakov 2011-08-18 10:44:36 PDT
Confirmed with Safari 5.1.
Comment 3 Cedric de Saint Martin 2011-08-18 19:43:34 PDT
Note : WebSocket will work properly if used with domain name (example.com) bound to ipv6 only. Then problem must come from address parsing.
Comment 4 Lamarque V. Souza 2013-02-28 14:23:32 PST
I cannot reproduce this problem. It seems fixed, can anyone confirm that?
Comment 5 David Gölzhäuser 2017-11-20 00:29:44 PST
We are experiencing similar issues right now:

WebSocket network error: The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 1.)

What is the current state of this issue?
Comment 6 James Diacono 2022-02-07 22:23:53 PST
I am experiencing this problem in Safari Technical Preview 15.4, release 135.

In my case, attempting to open a WebSocket connection to a server with a literal IPv6 address fails with

    WebSocket network error: The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 1.)

The address is ws://[::]:3589, which Chrome connects to without error. Safari succeeds when I use the equivalent IPv4 address, ws://localhost:3589.

The reason I ran into this is that I am attempting to debug a web application on my iPhone. I am serving the application from my laptop, which is connected to my phone via a USB personal hotspot. This hotspot only assigns my laptop an IPv6 address. I do not think I can alter my phone's /etc/hosts file to give my laptop's IPv6 address a domain name, so I am forced to use an IPv6 URL.
Comment 7 David Gölzhäuser 2022-02-09 08:55:38 PST
Take a look at this issue: https://bugs.webkit.org/show_bug.cgi?id=233752

Is yours also resolved in iOS 15.4 Beta 2
Comment 8 James Diacono 2022-02-09 16:18:16 PST
I will check next time I have access to a modern iPhone. In the meantime, upgrading STP to release 139 did not resolve the issue.

I noticed that I needed to add a '1' to my IPv6 URL for Chrome to consider it a secure origin: http://[::1]:3589. This did not help with Safari, but it got me thinking that maybe WebKit is rejecting [::] and [::1] as insecure.
Comment 9 David Gölzhäuser 2022-02-09 23:24:01 PST
I just read your issue again. My issue has something to do with the introduction iCloud Private Relay and the adoption of the Network layer in iOS. Your issue predates that change.

You may try to checkout this comment regarding the Safari development flags: https://bugs.webkit.org/show_bug.cgi?id=233752#c3
Comment 10 Anne van Kesteren 2023-05-12 08:11:00 PDT
Comment 0 seems to work fine today.
Comment 11 James Diacono 2023-05-12 17:32:02 PDT
I can confirm this is working in Safari v16.4 on MacOS.