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

Open
gopherbot opened this issue Aug 5, 2011 · 7 comments

Comments

@gopherbot
Copy link

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Dec 9, 2011

Comment 3:

Labels changed: added priority-later.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2013

Comment 5:

[The time for maybe has passed.]
@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 7:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 8:

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

@rsc

This comment has been minimized.

Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.