x/net/websocket: remedy neglect; merge with gorilla websocket?

@dsnet

It is not well maintained, and essentially everyone uses https://github.com/gorilla/websocket.

This was raised as a concern in #17244: because it is in the x/net repository, people attach greater value to it than it really ought to have.

/cc @dsnet

EDIT 2016-12-02: Copying in my better-phrased problem statement from later in the thread:

The problem I see is that the ownership/maintenance story of x/net/websocket is unclear. It may suit your needs, and that is fine! However, it's not getting the same level of support as the standard library or even gorilla/websocket; it has no established owner AFAIK.

Along the lines of #17244, there is concern that it elevates the status and visibility of the package. I've anecdotally heard of it confusing many new users whose needs were much better filled with gorilla/websocket. I have not heard of someone using gorilla/websocket and then deciding to use x/net/websocket instead.

We can't just delete something and break people who aren't vendoring it.

We can document that it's deprecated perhaps.

Or somebody could maintain it.

Deprecated might be fine, but my experience is that I (and other devs I've talked to) have wasted time trying to use the package only to find out it fails in production and that Gorilla's package works.

I support a strong deprecation message. Would that message endorse the Gorilla implementation?

If we implement golang/lint#238, I think that will help people avoid wasting time developing with deprecated packages or features.

"fails in production" -- what are the open bugs? There's not much to WebSockets. I'm afraid we're going to spend more time discussing things on this bug than we would just fixing any such issues.

Beyond any bugs that could be fixed by maintenance, the deeper problem with x/net/websocket is that it has the wrong API. It puts an io.Reader/Writer interface on top of what is fundamentally a message-based protocol.

I agree it should be documented as deprecated in favor of gorilla/websocket.

It's been long enough since I last tried to use it, but off-hand, you cannot implement a correct websocket reverse proxy with the current API, since it tries to implement io.Reader/io.Writer. Websocket, for better or for worse, is a frame-oriented protocol, not a stream-oriented protocol.

I agree it has the wrong API. But we could add ReadMessage and WriteMessage to it and deprecate Read and Write.

I am in favor of maintaining less code, though, (not that we ever maintained x/net/websocket much?), and I have no personal or sentimental connection to x/net/websocket, and we actually use gorilla/websocket in Camlistore these days, but it still feels core enough that we should have an official answer for websockets in x/net.

I suppose this all kinda depends on the policy for x/* we figure out in #17244.

I had this problem with a version of my profile package. My solution was to move the code into a branch and deleting all the code from the package on master so it could not be imported. The README has told people not to use the package for years, now in addition jt says if they still want to do it anyway, they can find the code in the branch. I considered replacing the paxkage with one that panic'd during init, but that felt like adding insult to injury.

…

On Fri, 2 Dec 2016, 08:59 Brad Fitzpatrick ***@***.***> wrote: I agree it has the wrong API. But we could add ReadMessage and WriteMessage to it and deprecate Read and Write. I am in favor of maintaining less code, though, (not that we ever maintained x/net/websocket much?), and I have no personal or sentimental connection to x/net/websocket, and we actually use gorilla/websocket in Camlistore these days, but it still feels core enough that we should have an official answer for websockets in x/net. I suppose this all kinda depends on the policy for x/* we figure out in #17244 <#17244>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18152 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA2pJ4SojprgRJRtypivu71yvE_H4ks5rD1FIgaJpZM4LB-47> .

Please do not deprecate it. At work, we are using golang.org/x/net/websocket exclusively and we have never had any problem with it*. Quite the opposite, in our use case it's more robust than what we've ever expected.

*: Of course, that says nothing whatsoever about any trouble anyone else might have with it.

@cznic

@cznic, "deprecate" does not mean "delete".

Yep. But I guess it means "no more bug fixes for you, ever".

No, not really. Deprecated is not black & white. We continue to fix bugs in other deprecated stuff when there's a good bug report and a clear fix and super minimal risk of breaking existing users. It just means we're not adding features to it, or means that a better way is known to exist.

Great news, honestly. But then again, why to mark it deprecated in the first place? We can cope with it getting no attention from people not loving it, but we do and if we run into a bug we need to resolve, we would be more than happy to contribute the fix.

Status quo anybody?

https://tools.ietf.org/html/rfc8441

I stand corrected.

I just tagged v0.1.0, it passes all of the autobahn tests except for compression which I'll add later.

https://github.com/nhooyr/websocket

Let me know what you think.

edit: Have tagged v1.0.0 now 🎊

@fjl

I opened a PR to add my library to the deprecation message as well. golang/net#51

Should we make the deprecation message stronger as discussed in #33215?

It seems to actively have issues with pings as described by @fjl at ethereum/go-ethereum#19798 (comment)

The issue here isn't that github.com/x/net/websocket doesn't handle ping (it does). We are seeing the reproducer behave this way because SetWriteDeadline interacts badly with the built-in ping frame handler. Whenever the RPC client wants to write something, it sets a write deadline. In the reproducer it only writes once to establish the subscription. When the ping frame arrives 12 seconds after the write, the write deadline that's set has already passed and writing the pong frame fails. The pong write error is returned from Read, causing the client to reconnect.

I looked over the code and confirmed this is an issue. The ping handling code never resets the write deadline and instead relies on the user of the Conn to reset the deadline to zero after reading which is definitely confusing behaviour. I suppose this could be fixed pretty easily but people ought to just use gorilla or mine. Mine also has a net.Conn wrapper to make such a transition easier. I'll add this to the deprecation message.

websocket: Add nhooyr.io/websocket to the deprecation message

try https://github.com/lxzan/gws , provide better performance, easier to use API

这个包满足我的，因为很小，而且是官方维护。唯一不足的地方大多数人没法用它，因为不会Read。

var c *websocket.Conn
var buf bytes.Buffer
b := make([]byte, 1024)

for {
	n, err := c.Read(b)

	if n > 0 {
		buf.Write(b[:n])
	} else if err != nil {
		return
	}

	//处理帧数据，你可能有如下三种判断之一：

	if err == io.EOF { //表示帧结束? 但是你可能永远等不到io.EOF这个值
		//处理帧数据
		buf.Reset()
	}

	//或者
	if buf.Len() == c.Len() { //c.Len()? 这方法返回没有准确表达我需要的条件，不知道有什么作用:frame.Length?
		//处理帧数据
		buf.Reset()
	}

	//或者
	if buf.Len() == int(c.FrameDataLenth()) { //ok,非常棒。但是 websocket.Conn 没有这个方法：FrameDataLenth=frame.header.Length
		//处理帧数据
		buf.Reset()
	}

}

@bradfitz

@bradfitz do you think it's possible to continue the conversation about merging gorilla/webosocket into x/net/websocket now that they have new maintainers or that ship has sailed a long time ago?

Hello, is there any update on this? It's been a long time since gorilla/ws got maintainers.
I really want to have good ws solution in stdlib.

@sedyh

Hello, is there any update on this? It's been a long time since gorilla/ws got maintainers.
I really want to have good ws solution in stdlib.

@sedyh

'x/' packages like x/net/websocket aren't part of the standard library either. If you like gorilla/websocket just use it.

Additionally, in light of the recent xz open source attack, we've all been reminded that sending pressure comments to open source maintainers, urging them to incorporate code from individuals they don't personally know, is not advisable. The code of gorilla/websocket wasn't created with the same review standards as packages by the Go project. And I personally feel that it has gotten worse after the change in maintainership, see gorilla/websocket#873

websocket: update nhooyr.io/websocket to github.com/coder/websocket

Change https://go.dev/cl/614075 mentions this issue: websocket: update nhooyr.io/websocket to github.com/coder/websocket

websocket: update nhooyr.io/websocket to github.com/coder/websocket

Switch websocket library, net/x/websocket is deprecated in golang/go#…

Navigation Menu

Repository navigation

x/net/websocket: remedy neglect; merge with gorilla websocket? #18152

47 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

x/net/websocket: remedy neglect; merge with gorilla websocket? #18152

Description

Activity

bradfitz commented on Dec 1, 2016

zombiezen commented on Dec 1, 2016

dsnet commented on Dec 1, 2016

bradfitz commented on Dec 1, 2016

cespare commented on Dec 1, 2016

zombiezen commented on Dec 1, 2016

bradfitz commented on Dec 1, 2016

davecheney commented on Dec 1, 2016

cznic commented on Dec 1, 2016

bradfitz commented on Dec 1, 2016

cznic commented on Dec 1, 2016

bradfitz commented on Dec 1, 2016

cznic commented on Dec 1, 2016

47 remaining items

jech commented on Mar 30, 2019

nhooyr commented on Apr 7, 2019

nhooyr commented on Sep 21, 2019

lxzan commented on May 31, 2023

ruyi789 commented on Aug 28, 2023

dmytro-i commented on Sep 21, 2023

sedyh commented on Apr 22, 2024

gophun commented on Apr 22, 2024

gopherbot commented on Sep 25, 2024

abcbarryn commented on Oct 15, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions