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: Read/Copy fail with long frames #2134

Closed
gopherbot opened this issue Aug 5, 2011 · 8 comments
Closed

x/net/websocket: Read/Copy fail with long frames #2134

gopherbot opened this issue Aug 5, 2011 · 8 comments
Assignees
Milestone

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 5, 2011

by nroos@webware-experts.de:

When using io.Copy() with a websocket as source, this fails if incoming websocket frames
are too large.

The reason is because io.Copy() uses a buffer with a default size for the Read().
websocket.Read() in turn uses bufio.ReadSlice() to read the current frame up to the
final 0xff. But if the incoming websocket frame size exceeds the buffer size of
io.Copy(), a ErrBufferFull ("bufio: buffer full") is generated.

The websocket specification does not limit the size of a frame, so this behaviour is
somewhat undesirable, as the success of a io.Copy() depends on the size of internal
buffers and the undeterminable websocket frame size.

What steps will reproduce the problem?

1. One process needs to open a websocket connection to a Go websocket server (pseudo
code, obviously):

   ws := websocket.Dial("127.0.0.1:80")
   buf := make([]byte, 100000)
   ws.Write(buf)

2. Websocket server:

   ws := accepted websocket.Conn
   writer := io.Writer
   err := io.Copy(writer, ws)

What is the expected output?

   err == nil

What do you see instead?

   err == bufio.ErrBufferFull

Which revision are you using?  (hg identify)

   1b38d90eebcd+ (release-branch.r58) tip

   (patches applied at other locations)
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Aug 8, 2011

Comment 1 by nroos@webware-experts.de:

The websocket.Read() does not work either (with long websocket frames). This means i
can't even do a "manual" copy with a sufficient large buffer.
@rsc
Copy link
Contributor

@rsc rsc commented Aug 8, 2011

Comment 2:

we're still discussing what the right websocket api is.

Owner changed to @rsc.

Status changed to Accepted.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 9, 2011

Comment 3:

Labels changed: added priority-later.

@rsc
Copy link
Contributor

@rsc rsc commented Mar 12, 2013

Comment 5:

[The time for maybe has passed.]
@rsc
Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 7:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 8:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 9:

Labels changed: added repo-net.

@mikioh mikioh changed the title go.net/websocket: Read/Copy fail with long frames x/net/websocket: Read/Copy fail with long frames Dec 23, 2014
@mikioh mikioh changed the title x/net/websocket: Read/Copy fail with long frames websocket: Read/Copy fail with long frames Jan 4, 2015
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc changed the title websocket: Read/Copy fail with long frames x/net/websocket: Read/Copy fail with long frames 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 Feb 8, 2020

So we retired x/net/websocket with an advisory https://pkg.go.dev/golang.org/x/net/websocket?tab=doc to instead use

And thus I shall close this issue.

@odeke-em odeke-em closed this Feb 8, 2020
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
3 participants
You can’t perform that action at this time.