Specify how document.cookie diverges from [COOKIES] RFC

[domenic]

Currently the spec says

the user agent must act as it would when receiving a set-cookie-string for the document's address via a "non-HTTP" API, consisting of the new value encoded as UTF-8.

However, in the real world things like document.cookie = "foo" work and have an effect. There are probably many other possibilities; in general the RFC just has a grammar that things might not match, whereas I imagine browsers just accept anything and try to make sense of it, even if it fails to match the grammar.

@bsittler noticed this while working on some service worker cookie stuff, and previously it has come up in the jsdom project and its related tough-cookie helper:

• Parse "bare" cookies in non-strict mode salesforce/tough-cookie#10
• Enable parsing cookies with an empty or no key salesforce/tough-cookie#49
• Implement loose mode for cookie jars salesforce/tough-cookie#56

@Sebmaster and @inikulin led the charge for this in jsdom, so maybe they could help us spec the correct behavior for how document.cookie parses cookies? Alternately, looking at open-source browser code would get us pretty far.

This might be a compat issue if everyone hasn't managed to magically converge on a single behavior despite the lack of precise spec. Tentatively tagging as such for now.

[annevk]

Paging @mikewest.

[inikulin]

I'd love to help!

Here is what we can do:

• Create test runner for the IETF test suite that will produce output in machine readable format. Currently it can run only individual tests, or requires dev builds of the browsers in some cases which renders it unusable for the testing of IE and Edge. Also it can't produce machine readable reports at the moment. We will need them to aggregate and analyze results across browsers lately. I'm already working on it.
• Run tests in all major browsers:
  • Chrome
  • Safari
  • Firefox
  • IE
  • Edge
• Using aggregated test fails info we can build table in format:

Test case /browser	Expected	Chrome	Firefox	Safari
"foo="	""	"foo"	"foo"	""

• Triage fails into groups, e.g. if test fails in the majority of the browsers consider it as a de facto behavior and add this difference to the spec. For the minor cases consult with the developers / search for the issue tracker tickets to find motivation behind it.
• Modify IETF test suite by the way to align it with the proposed behavior. Make it default test suite for the spec.

I will try to provide you test results somewhere around next week.

[annevk]

Cool! Another thing here worth checking is <meta http-equiv=set-cookie>. If these invalid values still result in HTTP headers, it's likely the RFC will need to be updated somehow.

[inikulin]

@annevk AFAIK browsers uses the same code for all cookie parsing scenarios. Spec violations in document.cookie setter also shows up when you set cookie via HTTP-header. I'm pretty sure we will have the same results with <meta>.

[annevk]

I see, in that case it seems like something @mikewest and @mnot should be solving in the RFC. Your testing will still be useful, obviously, but given the scope of the problem it does not seem like something that needs to be addressed in the HTML Standard. Although I can understand if we need to make adjustments for a revised RFC that does handle this properly.

[inikulin]

Although I can understand if we need to make adjustments for a revised RFC that does handle this properly.

So, we will continue discussion here for now and once we will have some data and analyzis we will ping IETF guys, I guess?

[mnot]

Very good timing. We're about to start opening up the cookie RFC, so yes do ping us when you have some results. Any idea how long that will be?

[annevk]

@inikulin, yeah, we'll keep this open until the issue is resolved. @mnot, @inikulin mentioned earlier he was hoping to have something this week.

[inikulin]

Voilà
http://inikulin.github.io/cookie-compat/

[domenic]

OMG, this is amazing!!

[bsittler]

@inikulin this is really sobering. Thank you! What was the effective document charset for the test page?

[inikulin]

@bsittler UTF-8