Closed Bug 1255938 Opened 8 years ago Closed 4 years ago

RFC 6265 cookies spec compliance issues

Categories

(Core :: Networking: Cookies, defect, P3)

defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox45 --- affected
firefox46 --- affected
firefox47 --- affected
firefox48 --- affected

People

(Reporter: cpeterson, Assigned: amchung)

References

()

Details

(Whiteboard: [necko-backlog])

Ivan Nikulin's test lists RFC 6265 compliance issues found in modern browsers. Data was obtained by running the IETF test suite across major browsers using a specially made test runner. Test fails are divided into categories for the working group to distinguish implementation bugs from de facto standards that should make their way to the specification.

Here are the test cases that Firefox fails but other browsers do not fail. Some test cases are failed by all or most browsers, thus becoming a de facto standard.

https://inikulin.github.io/cookie-compat/

PATH0014
Set cookie: "foo=bar; path=/cookie-parser-result/foo/qux/"
GOOD: Safari, IE, Edge, Chrome result: ""
BAD: Firefox 44 result: "foo=bar"

DISABLED_PATH0029
Set cookie: "foo=bar; path=/cookie-parser-result/foo/bar"
GOOD: IE, Edge, Chrome result: "foo=bar"
BAD: Safari, Firefox result: ""

OPTIONAL_DOMAIN0042
Set cookie: "foo=bar; domain=foo.example.org; domain="
GOOD: Safari, IE, Edge: ""
BAD: Chrome, Firefox: "foo=bar"
that's useful work. thanks! Nick - seems like a compat win, interested?
Flags: needinfo?(hurley)
Whiteboard: [necko-backlog]
See Also: → 537207
(In reply to Patrick McManus [:mcmanus] from comment #1)
> that's useful work. thanks! Nick - seems like a compat win, interested?

Let's keep it on the backlog for now - these are pretty strange-ish corner cases of cookie parsing, and I suspect that if anyone were hitting them, they've probably changed their cookie format long ago (since it's not like this has changed significantly).

There's also the fact that the current cookie parsing code is pretty hairy, so straightforward-looking compat wins may take more time than they're worth for cases like this :)
Flags: needinfo?(hurley)
Assignee: nobody → amchung
Whiteboard: [necko-backlog] → [necko-active]
Whiteboard: [necko-active] → [necko-next]
Whiteboard: [necko-next] → [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Priority: P1 → P3

https://inikulin.github.io/cookie-compat/ - this test is extremely similar to cookies WPTs. See: https://wpt.fyi/results/cookies?label=master&label=experimental&aligned

I mark this bug as invalid because the current firefox nightly is compatible with the cookies specs.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

@Andrea Marchesini IETF's http-state test suite is now a subset of WPT.

Do I understand correctly that by Nightly you imply version 75? If, so I still see quite significant amount of compatibility issues with exactly this subset: https://wpt.fyi/results/cookies/http-state?label=experimental&label=master&aligned

E.g. Firefox currently is the only browser that fails disabled-chromium0022 test: https://wpt.fyi/results/cookies/http-state/chromium-tests.html?label=experimental&label=master&aligned

Flags: needinfo?(amarchesini)

@Andrea Marchesini IETF's http-state test suite is now a subset of WPT.

This is an interesting point to discuss. http-state cookie WPTs do not follow RFC6265. A couple of examples:

  1. charsets - by RFC cookie-values should contain ASCII chars only (See cookie-octet), but we have WPTs testing cookie values such as foo=春节回家路·春运完全手册
  2. invalid chars: by RFC cookie names and values should not contain spaces. But we have WPTs testing Set-Cookie: foo bar=baz
  3. '=' is mandatory between cookie name and value, but we have tests such as: Set-Cookie: foo
    I can continue.

RFC6265 needs to be updated to what browsers do and WPTs should be written on top of the latest version of such RFC.
Without a proper spec, I don't know why and how those tests should pass.

Flags: needinfo?(amarchesini)
You need to log in before you can comment on or make changes to this bug.