[Webkit-unassigned] [Bug 82100] [WebSocket]Reserved bits test case should cover both extension and no-extension scenarios

[bugzilla-daemon at webkit.org]

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





--- Comment #25 from joey <li.yin at intel.com>  2012-03-30 05:38:38 PST ---
(In reply to comment #24)
> (In reply to comment #23)
> > It sounds good. Can you provide some detailed information or example to do that?
> > Thanks.
> 
> If the port doesn't support deflate-frame extension, the opening handshake should not contain "Sec-WebSocket-Extensions: deflate-frame". You can check it via request.headers_in in web_socket_do_extra_handshake(). If "comressed=true" and there is no deflate-frame extension header in the request, you may want to abort the handshake in similar way handshake-error_wsh.py does.

Yeah, it can work, but it still had another issue. 
When it had no negotiated compressed extension, if browser received a frame with setting reserved-1(compressed) bit, browser should failed the connection, it makes sense, as chromium did.
But it was checked in the #if ZLIB code segment, it can't work in Qt port because of disable ZLIB. WebKit qt-port can receive the unexpected frame and can't fail the connection.

So maybe we need another obvious operation before calling m_deflateFramer.inflate function, like the reserved-2 and reserved-3 bit checking.
But if we do that, it will have a duplicate check for reserved-1 bit in these enable ZLIB WebKit ports.

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