2009/6/25 Chris Evans <[email protected]> > On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) > <[email protected]>wrote: > >> Hi, >> >> yuzo, tyoshino and I start working to implement HTML5 Web Socket and write >> design docs >> >> WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh >> Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm >> >> We'll send WebKit part to webkit-dev, if it looks ok. >> We'd welcome if you could give us feedback on our design docs. > > > Interesting feature :) It's hard to tell at first glance, because the > security section is empty -- but it appears like security has been > considered at least in > http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17. >
> > It might be worth being more explicit about security in our WebKit doc > (i.e. creating a new security section). > Ok, I added the security section. Anyway, the websocket protocol doc has "security considerations" section, but no information there yet.. > Possible tests we'll want include: > > - Connect a web socket to some ordinary HTTP server and confirm that the > connect fails. > - Connect a web socket to a real web socket server that fails to return a > websocket-origin header, and validate that the connect fails (if it didn't, > a simple server bug could open up responses to all origins) > - Check we respect the origin sent from the server. > - What about redirectors? Assuming unsupported, verify that connecting to a > redirector does not cause any redirection. > - URL integration: what happens if a ws:// or wss:// URL is entered into > the URL bar, or any other place an URL is accepted? (img tags, script tags > etc). > - What about embedded newline characters in the various strings the client > gets to specify (URL, resource name, protocol etc). Ensure that no lines > sent to the server can be caused to be split by doing this. > - Length encoding: ensure we handle excessively long length encodings, e.g. > 0xff 0xff 0xff... ad infinitum. Test we can handle decoded lengths that > happen to be negative (or very large) when assigned to int32, int64, uint32, > uint64. > - Cookies: ensure we _never_ transmit any HTTP cookies over the unencrypted > ws:// channel, if that cookie was marked Secure. Similar test for > Authorization headers. > Thanks for valuable test cases! We'll test these case. Thanks, ukai > > > Cheers > Chris > > >> >> Thanks, >> ukai >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
