[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 #27 from Kenichi Ishibashi <bashi at chromium.org>  2012-03-30 06:08:38 PST ---
(In reply to comment #25)
> (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.

How about adding

if (frame.compress) {
    result->fail("reserved1 bit is on");
    return result.release();
}

into #else block in WebSocketDeflateFramer::inflate() ?

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