RESOLVED FIXED 32598
Flakiness in WebSocket handshake console message 
https://bugs.webkit.org/show_bug.cgi?id=32598
Summary Flakiness in WebSocket handshake console message
Fumitoshi Ukai
Reported Wednesday, December 16, 2009 8:02:10 AM UTC
In chromium port, handshake-error.html may outputs 3 lines of CONSOLE MESSAGE: line 0: Unexpected response code:101
Attachments
Fix flakiness in WebSocket handshake console message. (4.96 KB, patch)
2009-12-16 00:20 PST, Fumitoshi Ukai 		ap: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Fumitoshi Ukai
Comment 1 Wednesday, December 16, 2009 8:20:15 AM UTC
Created attachment 44952 [details] Fix flakiness in WebSocket handshake console message.
WebKit Review Bot
Comment 2 Wednesday, December 16, 2009 8:25:06 AM UTC
style-queue ran check-webkit-style on attachment 44952 [details] without any errors.
Alexey Proskuryakov
Comment 3 Thursday, December 17, 2009 5:16:55 AM UTC
Comment on attachment 44952 [details] Fix flakiness in WebSocket handshake console message. r=me Is it be possible to make a reliable test for this? That would involve sending a large response that no reasonable implementation would coalesce into one didReceiveData call.
Fumitoshi Ukai
Comment 4 Thursday, December 17, 2009 6:19:22 AM UTC
Committed r52234: <http://trac.webkit.org/changeset/52234>
Fumitoshi Ukai
Comment 5 Thursday, December 17, 2009 6:27:08 AM UTC
(In reply to comment #3) > (From update of attachment 44952 [details]) > r=me > > Is it be possible to make a reliable test for this? That would involve sending > a large response that no reasonable implementation would coalesce into one > didReceiveData call. I think it would be difficult to make a reliable test. It must send several chunks for handshake response header and each chunk should be delivered as following order - first chunk. containing first line with bad response code, but not finished whole handshake message - bad response code, so it closes the SocketStreamHandle. - before didClose comes, it receives second chunk, which would be already queued while it is processing the first chunk.
Note You need to log in before you can comment on or make changes to this bug.