| Summary: | WebSocket test to transfer null character | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Fumitoshi Ukai <ukai> | ||||
| Component: | WebCore JavaScript | Assignee: | Fumitoshi Ukai <ukai> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ap | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
|
Description
Fumitoshi Ukai
2010-03-03 19:22:23 PST
Created attachment 49993 [details]
Patch
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.
Committed r55574: <http://trac.webkit.org/changeset/55574> (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.. |