[Webkit-unassigned] [Bug 81878] [WebSocket]Reserved1 bit should be 0 when no negotiated extension

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from joey <li.yin at intel.com>  2012-03-22 18:21:02 PST ---
(In reply to comment #6)
> (From update of attachment 133402 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=133402&action=review
> 
> > Source/WebCore/ChangeLog:12
> > +        RFC 6455 http://tools.ietf.org/html/rfc6455#section-5.2
> > +        MUST be 0 unless an extension is negotiated that defines meanings
> > +        for non-zero values. If a nonzero value is received and none of
> > +        the negotiated extensions defines the meaning of such a nonzero
> > +        value, the receiving endpoint MUST _Fail the WebSocket Connection_.
> 
> Now that I see a bit more what this is about...
> 
> Is there also a test in WebKit for the positive case? Setting the bit number and having an extension.
Yes, the normal test based on this way, for example simple.html.

> What about setting a bit, having an extension, but the extension does not define the meaning of the bit? (per: If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST _Fail the WebSocketConnection_.)
If it has negotiated extension in WebKit, the reserved bit1 means compress bit. If the reserved1 bit is set to be 1, it means the frame is compressed, or the frame is uncompressed. WebKit can handle these frames successfully.
But it seems no test case to cover it.

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