[webkit-reviews] review denied: [Bug 200165] WebSockets: response Set-Cookie header not handled when using platform APIs : [Attachment 375407] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Aug 2 11:32:08 PDT 2019
Alex Christensen <achristensen at apple.com> has denied review:
Bug 200165: WebSockets: response Set-Cookie header not handled when using
platform APIs
https://bugs.webkit.org/show_bug.cgi?id=200165
Attachment 375407: Patch
https://bugs.webkit.org/attachment.cgi?id=375407&action=review
--- Comment #17 from Alex Christensen <achristensen at apple.com> ---
Comment on attachment 375407
--> https://bugs.webkit.org/attachment.cgi?id=375407
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=375407&action=review
>> Source/WebKit/NetworkProcess/NetworkSocketChannel.cpp:111
>> +
m_session->networkStorageSession()->setCookiesFromDOM(m_request.firstPartyForCo
okies(), SameSiteInfo::create(m_request),
>
> The call to setCookiesFromDOM seems strange to me since this is a regular
HTTP response processing code path.
> Looking at MacOS setCookiesFromDOM implementation, this is mostly ok except
that we are doing client-side cookie checks to validate the duration.
> If we compare to the WebProcess handshake implementation, this is status quo
but I wonder if there is something better we could do here.
setCookiesFromDOM is for document.cookie=something. That should not be used
here because an HTTP-only cookie sent to a web socket handshake should not be
accessible from document.cookie. Could you add a test that verifies that?
Also, your code in NetworkSocketChannel::setCookies should be in a
soup-specific file because the NSURLSession-based implementation will not have
CFNetwork give WebKit cookies to tell CFNetwork to store. It will just do that
for us.
More information about the webkit-reviews
mailing list