Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/net/websocket: setting BinaryFrame #7350

Closed
gopherbot opened this issue Feb 18, 2014 · 8 comments
Closed

x/net/websocket: setting BinaryFrame #7350

gopherbot opened this issue Feb 18, 2014 · 8 comments
Milestone

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 18, 2014

by errordeveloper:

Default PayloadType is TextFrame and there seem to be no way of setting it to
BinaryFrame.

https://code.google.com/p/go/source/browse/websocket/hybi.go?repo=net#346

I'm not too sure what the fix would be, but in my case modifying that line 346 worked...
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Feb 25, 2014

Comment 1 by ledangster:

If your handler uses *websocket.Conn directly then you directly change PayloadType
(since it's publicly modifiable) to websocket.BinaryFrame before writing out the
frame(s):
 conn.PayloadType = websocket.BinaryFrame
 ...
 conn.Write(...)
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Feb 25, 2014

Comment 2 by errordeveloper:

That worked, pardon for newbie bug report. Perhaps I could suggest it needs
to be a little more clear in the docs.
@rsc
Copy link
Contributor

@rsc rsc commented Mar 3, 2014

Comment 3:

Labels changed: added repo-net.

@gopherbot gopherbot added new labels Mar 3, 2014
@bradfitz bradfitz removed the new label Dec 18, 2014
@mikioh mikioh changed the title go.net/websocket: setting BinaryFrame x/net/websocket: setting BinaryFrame Dec 23, 2014
@mikioh mikioh added repo-net and removed repo-net labels Dec 23, 2014
@mikioh mikioh changed the title x/net/websocket: setting BinaryFrame websocket: setting BinaryFrame Jan 4, 2015
@dmitshur
Copy link
Member

@dmitshur dmitshur commented Mar 1, 2015

PayloadType is an exported field. It should be documented.

Also, Write should probably mention that it uses the value of PayloadType. Its documentation currently says nothing about that.

dmitshur referenced this issue in shurcooL/play Mar 1, 2015
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc removed the release-none label Apr 10, 2015
@rsc rsc changed the title websocket: setting BinaryFrame x/net/websocket: setting BinaryFrame Apr 14, 2015
@rsc rsc modified the milestones: Unreleased, Unplanned Apr 14, 2015
@rsc rsc removed the repo-net label Apr 14, 2015
@odeke-em
Copy link
Member

@odeke-em odeke-em commented Jun 6, 2020

We no longer maintain x/net/websocket. @dmitshur and @ledangster, there was a suggestion for that documentation update but we instead recommend alternatives:

@odeke-em odeke-em closed this Jun 6, 2020
@dmitshur
Copy link
Member

@dmitshur dmitshur commented Jun 7, 2020

We no longer maintain x/net/websocket.

Do you have a reference for that? I'm asking because I don't know.

This is not to suggest that this package is maintained actively or in an exemplary manner, but as far as I can see, #18152 is still in open state with NeedsDecision state, which suggests to me it's still under maintenance.

I don't see a benefit in closing this issue (and not the 12 other open issues with "x/net/websocket:" prefix) until there's some sort of resolution to #18152, given that this issue properly titled/labeled and it is tracking a valid problem in the golang.org/x/net/websocket package that hasn't been resolved yet.

@agnivade
Copy link
Contributor

@agnivade agnivade commented Jun 7, 2020

Do you have a reference for that? I'm asking because I don't know.

Basically #18152 (comment).

It may not be worded explicitly, but it effectively means that.

Also: golang/net@97edce0

// This package currently lacks some features found in an alternative
// and more actively maintained WebSocket package:
//
// https://godoc.org/github.com/gorilla/websocket
//

Stress on "more actively maintained". Which indirectly means, this is not well-maintained.

AFAIU, #18152 is about doing something about the fact that it's unmaintained, by merging with gorilla/websocket or something else. But it is clear that the repo in its current state is unmaintained, and users are encouraged to look somewhere else.

@odeke-em
Copy link
Member

@odeke-em odeke-em commented Jun 7, 2020

Thank you for digging up the references @agnivade, and for helping me answer Dmitri’s question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.