Bug 124580
| Summary: | Expose API for modifying WebSocket HTTP Handshake request | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | lfranchi <lfranchi> |
| Component: | WebKit API | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, beidson, p.jacquemart |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.9 | ||
lfranchi@kde.org
In order to implement a private cookie jar in Cocoa WebKit, absent a built-in method, the best solution is to implement webView:willSendRequest: and webView:didReceiveResponse and handling cookies manually. This means basically replacing the built-in cookie handling in the WebView and storing/loading cookies in client code.
However, when using WebSockets, the initial HTTP upgrade/handshake request does not go through this mechanism (WebSocketHandshake::clientHandshakeMessage builds the header directly). This means that it's impossible to include the correct cookies in the WebSocket handshake request, as the HTTP request bypasses any user code completely.
It would be great to be able to attach cookies etc to this HTTP request as with any other HTTP request, otherwise it's impossible to properly implement a sandboxed-cookie-jar app using Cocoa's WebView.
c.f. https://lists.webkit.org/pipermail/webkit-help/2013-November/003644.html
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
<rdar://problem/7450841>