Is the allowed cookie syntax documented anywhere?

[Kannan Goundan]

Chrome allows setting cookie values that don't follow the spec, which causes errors for server software that tries to parse the "Cookie" header.

I ran into this issue when trying to add the "Sign in with Google" button to my web application.  That feature ends up setting a cookie with name 'g_state' and value 'g_state={"i_l":0}".  The spec does not allow double quotes in cookie values (see "cookie-value" in https://datatracker.ietf.org/doc/html/rfc6265#section-4.1.1).

Even though my server isn't using the 'g_state' cookie, its presence in the "Cookie" causes the entire header to be out-of-spec, which causes the cookie parsing library to reject the entire header.

Ideally, Chrome (and other browsers) would follow the spec, but I imagine there are compatibility tradeoffs.  So in the short/medium term, I'd like to write a cookie parsing library (in JavaScript) that can parse the "Cookie" headers that are generated by popular browsers.

Is there documentation anywhere on what exactly Chrome allows?

[Ryan Hamilton]

I think the code you are looking for ParsedCookie::IsValidCookieValue.

There's a comment which appears relevant:

// Note that RFC6265bis section 4.1.1 suggests a stricter grammar for

// parsing cookie values, but we choose to allow a wider range of characters

// than what's allowed by that grammar (while still conforming to the

// requirements of the parsing algorithm defined in section 5.2).

//

// For reference, see:

// - https://crbug.com/238041

Cheers,

Ryan

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Kannan Goundan]

Thank you!  This is exactly what I was looking for.  (And thanks to the Chrome developers for the code comment!)

But man... it's frustrating that the spec defines two different grammars for the same thing.  Seems like that just increases the odds of compatibility issues for clients that are trying to follow the spec :-\

[Ryan Hamilton]

On Wed, Sep 22, 2021 at 5:21 PM Kannan Goundan <kan...@cakoose.com> wrote:

Thank you!  This is exactly what I was looking for.  (And thanks to the Chrome developers for the code comment!)

But man... it's frustrating that the spec defines two different grammars for the same thing.  Seems like that just increases the odds of compatibility issues for clients that are trying to follow the spec :-\

Yeah :( I have no insight into the particular choices here but I TOTALLY agree with your angst :( 

[Andrew Williams]

There's an issue open in the draft repo aimed at closing the gap between the two sections of RFC6265bis:

https://github.com/httpwg/http-extensions/issues/1399

Making progress on that is on my TODO list - I too would like to see this be made less confusing!

-Andrew

--

--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.