[Webkit-unassigned] [Bug 28038] WebSocket API implementation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=28038


Alexey Proskuryakov <ap at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




--- Comment #4 from Alexey Proskuryakov <ap at webkit.org>  2009-08-12 09:34:49 PDT ---
> Hmm, how about WebSocketClientHandshake and WebSocketServerHandshake?
> What name do you recommend?

That's less misleading. I was thinking of having a single class to handle
handshake, not a pair of classes, but I didn't fully think it through, so it
may be a bad idea.

> > +    // FIXME: need dispatchEvent?
>
> Should I add the implementation in this patch, or ok in another patch?

I think it would be easiest to do it now, while this incomplete code is clearly
visible in a patch - hunting it down in trunk will be more difficult. Please
also make a test for addEventListener-installed listeners (as usual, to be
landed once the code becomes functional).

> What is the good way to handle overflow?
> May I close the connection if too long length is detected?

Sounds good to me. We probably want to log something to console in this case
(and in other error cases that can occur in WebSocket lifetime).

> Do we need to set maximum length of m_buffer? (512KB or so?)

It would probably be nice to use tryFastMalloc (to close the connection instead
of crashing if the server sends too large frame). If we were to add an
artificial limit on received frame size, I think that it should be
impractically huge, dozens of megabytes on desktop platforms - all we want is
to prevent crashing the browser with an incorrect frame size, right?

This doesn't seem like something that could happen during normal operation,
it's just a protection from server bugs, and it makes DoS'ing the browser via
WebSocket protocol more difficult.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.