Miscalculating in _read_until

[hamax]

My _read_until:

def _read_until(self, delimiter, callback):
    self._read_buffer += self.recv(4096)
    pos = self._read_buffer.find(delimiter)
    if pos >= 0:
        pos += len(delimiter)
    if pos > 0:
        data = self._read_buffer[:pos]
        self._read_buffer = self._read_buffer[pos:]
        if data:
            callback(data)

[mordicuac]

works for me, thanks

[acid-head]

Hi, can you tell me what was the symptom given by this problem.
We have and issue where sockets get disconnected with this error:
error: uncaptured python exception, closing channel <websocket._Dispatcher at 0x5bfa908> (<type 'exceptions.AssertionError'>: [/usr/lab/jakarta-jmeter-2.4/bin/Python-2.7.1/Lib/asyncore.py|read|79] [/usr/lab/jakarta-jmeter-2.4/bin/Python-2.7.1/Lib/asyncore.py|handle_read_event|445] [/usr/local/lib/python2.7/site-packages/websocket.py|handle_read|146] [/usr/local/lib/python2.7/site-packages/websocket.py|_read_until|169] [/usr/local/lib/python2.7/site-packages/websocket.py|_handle_frame|172])

And I was wandering if this bug could be the cause.
Thank you.

[acid-head]

Argh,

Part of the exception gets eaten by the HTML code, anyway the exception type is 'exceptions.AssertionError' and the assert seems to be the one in _handle_frame, and _handle_frame is the callback function called by _read_until

[drewww]

This is an absolute must patch. I was having tremendous troubles with frame shifting issues. _read_until was mis-parsing things and the handle_header assertion would get broken because an \xff character would be at the end instead of just \r\n\r\n. This problem also came up in handle_frame - some frames would have an \xff at the start and end of the frame because read_until was leaving the frame open too long. For some reason this never happened to me when I was making just one socket, but for large numbers of sockets (I'm trying to load-test a socket.io server) it happened quite frequently.

Thanks so much for the fix, hamax. You're a life-saver! I was about to report this bug myself and then throw up my hands and go re-implement the whole thing in Java.