Bug 100073 – Web Inspector: Response cookies are missed in CookiesTable of Network Panel

• Component: Web Inspector (Deprecated)
• Status: RESOLVED INVALID

[Peter Wang]

Created attachment 170059 [details]
test case

Access the attached page , it'll set 4 cookies in Browser.
The http response will be a little different, some browser will insert 4 cookies in one "Set-Cookie" header, like this "Set-Cookie: one=one; two=two; three=three; four=four".
When you access the attached page second time, there will be a mistake, as the attached picture shows.

The root reason is this statement(NetworkItemView.js:54):
 
if (request.requestCookies || request.responseCookies) {...} 

If "request.requestCookies" is not null the "get responseCookies()" will never be invoked.

[Peter Wang]

Created attachment 170060 [details]
the error

[Peter Wang]

Created attachment 170064 [details]
Patch

[Vsevolod Vlasov]

Comment on attachment 170064 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=170064&action=review

I can not reproduce this issue. Closing as invalid.

> Source/WebCore/inspector/front-end/NetworkItemView.js:-57
> -    if (request.requestCookies || request.responseCookies) {

request.responseCookies getter does nothing but lazy init _responseCookies field. Calling it explicitly can not change how the response cookies are shown in UI.

[Vsevolod Vlasov]

I can not repro on chromium.
If you can still repro this please provide some more details.

[Peter Wang]

This statement really has problem, but it'll be HIDDEN in this situation: if there is only one cookie in a "Set-Cookie" header, the "CookieParser" almost does nothing in this situation, so it's ok even if "responseCookies()" has not  invoked.

Some ports send multi cookies in separated "Set-Cookie" headers, like Qt and Chromium (seems just hides it recently, version "20.0.1132.47" on my PC has this bug).

BlackBerry inserts multi cookies into one "Set-Cookie" header (it meets HTTP protocol also, and that's why there is a loop in function "CookieParser.parseCookie"), so the problem becomes exposed.

I'm trying to building another ports to see if I can find a easier environment to reproduce it.

[Peter Wang]

Created attachment 170088 [details]
A figure to explain in what situation the error will be exposed

[Peter Wang]

Comment on attachment 170064 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=170064&action=review

>> Source/WebCore/inspector/front-end/NetworkItemView.js:-57
>> -    if (request.requestCookies || request.responseCookies) {
> 
> request.responseCookies getter does nothing but lazy init _responseCookies field. Calling it explicitly can not change how the response cookies are shown in UI.

If there are several cookies in one header, it has to be parsed through invoking "request.responseCookies". If there is one cookie in one header, "lazy init" can work well just because in this situation "request.responseCookies" does nothing so it's ok even if we don't invoke it.

HTTP sever usually inserts multi cookies in one header, but some browser response with separated headers. It's lucky that the "request.responseCookies" is behind the "||".

[Vsevolod Vlasov]

Even if this was a valid problem it should have been fixed in CookieParser.My experiments show that when server replies with the Set-Cookie header value like the one in your example, such value is not treated as a correct one a browser does not send such cookies in requests made later.

Try putting in your original php example.
header("Set-Cookie: cookieONE=ONE; expires=Tue, 23-Oct-2012 12:38:01 GMT, cookie3=3; expires=Tue, 23-Oct-2012 12:38:01 GMT, cookie4=4; expires=Tue, 23-Oct-2012 12:38:01 GMT");

[Peter Wang]

(In reply to comment #8)
> Even if this was a valid problem it should have been fixed in CookieParser.My experiments show that when server replies with the Set-Cookie header value like the one in your example, such value is not treated as a correct one a browser does not send such cookies in requests made later.
> 
> Try putting in your original php example.
> header("Set-Cookie: cookieONE=ONE; expires=Tue, 23-Oct-2012 12:38:01 GMT, cookie3=3; expires=Tue, 23-Oct-2012 12:38:01 GMT, cookie4=4; expires=Tue, 23-Oct-2012 12:38:01 GMT");

Ok, sir. Agree to close this bug for now. It's unfair that ask you to review code but cannot provide a way to reproduce bug on your platform.

I wish I can send my device to you for debugging, but it's really expensive for me :).

Maybe we can meet a test case in future.