Parsing handshake before all data has been received results in an ArgumentOutOfRangeException. about fleck HOT 7 CLOSED

I am currently working on refactoring the request parsing so multiple drafts can be supported. One piece of that is ensuring a complete request before attempting to respond to the handshake. Expect this fixed soon.

from fleck.

Nice! Are you planning to support
draft-ietf-hybi-thewebsocketprotocol-06? That one uses SHA1 hashing
over MD5 and it would really help me out because of FIPS compliancy :)

On Wed, Aug 31, 2011 at 08:22, statianzo
[email protected]
wrote:

I am currently working on refactoring the request parsing so multiple drafts can be supported. One piece of that is ensuring a complete request before attempting to respond to the handshake. Expect this fixed soon.

Reply to this email directly or view it on GitHub:
#7 (comment)

from fleck.

I've been looking at draft-ietf-hybi-thewebsocketprotocol-10, as that's what has been implemented in Chromium 14. It also uses SHA-1. I'm not sure about its compatibility with hybi-06. However, adding that in should be easier soon.

On Friday, September 2, 2011 at 1:24 AM, enix wrote:

Nice! Are you planning to support
draft-ietf-hybi-thewebsocketprotocol-06? That one uses SHA1 hashing
over MD5 and it would really help me out because of FIPS compliancy :)

On Wed, Aug 31, 2011 at 08:22, statianzo
<[email protected] (mailto:[email protected])>
wrote:

I am currently working on refactoring the request parsing so multiple drafts can be supported. One piece of that is ensuring a complete request before attempting to respond to the handshake. Expect this fixed soon.

Reply to this email directly or view it on GitHub:
#7 (comment)

Reply to this email directly or view it on GitHub:
#7 (comment)

from fleck.

10 is fine too :) As long as it's SHA1 that's being used for the
handshake I'm happy. Thanks!

On Fri, Sep 2, 2011 at 14:49, statianzo
[email protected]
wrote:

I've been looking at draft-ietf-hybi-thewebsocketprotocol-10, as that's what has been implemented in Chromium 14. It also uses SHA-1. I'm not sure about its compatibility with hybi-06. However, adding that in should be easier soon.

On Friday, September 2, 2011 at 1:24 AM, enix wrote:

Nice! Are you planning to support
draft-ietf-hybi-thewebsocketprotocol-06? That one uses SHA1 hashing
over MD5 and it would really help me out because of FIPS compliancy :)

On Wed, Aug 31, 2011 at 08:22, statianzo
<[email protected] (mailto:[email protected])>
wrote:

I am currently working on refactoring the request parsing so multiple drafts can be supported. One piece of that is ensuring a complete request before attempting to respond to the handshake. Expect this fixed soon.

Reply to this email directly or view it on GitHub:
#7 (comment)

Reply to this email directly or view it on GitHub:
#7 (comment)

Reply to this email directly or view it on GitHub:
#7 (comment)

from fleck.

I'm still in progress of adding hybi, but the refactor of the "RequestBuilders" is complete (unless hybi-10 requires additional changes). I included some logic to check for complete requests.

Could you take a look at the hybi branch and see if you can repro this bug with it? I've been unable to reproduce it at all, even before i did the complete request check.

from fleck.

Hi,

sorry for such a late reply! I've tested your code awhile back and
forgot to send you an update.

I do get the 'No bytes recieved. Connection closed.' message from time
to time but no more crashes so that's a good thing.

cheers,
Ernst

On Sat, Sep 3, 2011 at 22:34, statianzo
[email protected]
wrote:

I'm still in progress of adding hybi, but the refactor of the "RequestBuilders" is complete (unless hybi-10 requires additional changes). I included some logic to check for complete requests.

Could you take a look at the hybi branch and see if you can repro this bug with it? I've been unable to reproduce it at all, even before i did the complete request check.

Reply to this email directly or view it on GitHub:
#7 (comment)

from fleck.

Good to know. I opted for the "No bytes = closed" option because otherwise it could wait indefinitely for a complete request to come through. Thanks for testing it out again.

from fleck.