RESOLVED FIXED 35715
WebSocket test to transfer null character 
https://bugs.webkit.org/show_bug.cgi?id=35715
Summary WebSocket test to transfer null character
Fumitoshi Ukai
Reported 2010-03-03 19:22:23 PST
We should have test that WebSocket could send/receive message contains null character, which is frame type.
Attachments
Patch (2.96 KB, patch)
2010-03-03 23:58 PST, Fumitoshi Ukai 		ap: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Fumitoshi Ukai
Comment 1 2010-03-03 23:58:10 PST
Created attachment 49993 [details] Patch
Alexey Proskuryakov
Comment 2 2010-03-04 10:28:43 PST
Comment on attachment 49993 [details] Patch r=me, thank you for making the test! It makes me somewhat nervous that we have the following FIXME in send(): // FIXME: check message is valid utf8. Can one sneak 0xff in by passing invalid UTF-16 to send()? String::utf8() relies on platform-provided encoder, and I don't even know what ICU does for invalid input, let alone other implementations.
Fumitoshi Ukai
Comment 3 2010-03-05 01:51:52 PST
Committed r55574: <http://trac.webkit.org/changeset/55574>
Fumitoshi Ukai
Comment 4 2010-03-05 01:54:05 PST
(In reply to comment #2) > (From update of attachment 49993 [details]) > r=me, thank you for making the test! > > It makes me somewhat nervous that we have the following FIXME in send(): > > // FIXME: check message is valid utf8. > > Can one sneak 0xff in by passing invalid UTF-16 to send()? String::utf8() > relies on platform-provided encoder, and I don't even know what ICU does for > invalid input, let alone other implementations. Hmm, I think any values represented in UTF-16 couldn't be 0xff in UTF-8, since UTF-8 bit pattern should have at least one zero bit in every bytes. Maybe, we could remove this comment..
Note You need to log in before you can comment on or make changes to this bug.