Bug 32598

Summary: Flakiness in WebSocket handshake console message
Product: WebKit Reporter: Fumitoshi Ukai <ukai>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, eric, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Fix flakiness in WebSocket handshake console message. ap: review+

Fumitoshi Ukai
Reported 2009-12-16 00:02:10 PST
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 2009-12-16 00:20:15 PST
Created attachment 44952 [details] Fix flakiness in WebSocket handshake console message.
WebKit Review Bot
Comment 2 2009-12-16 00:25:06 PST
style-queue ran check-webkit-style on attachment 44952 [details] without any errors.
Alexey Proskuryakov
Comment 3 2009-12-16 21:16:55 PST
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 2009-12-16 22:19:22 PST
Committed r52234: <http://trac.webkit.org/changeset/52234>
Fumitoshi Ukai
Comment 5 2009-12-16 22:27:08 PST
(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.