gh-112713 : Add support for 'partitioned' attribute in http.cookies

[giles-v]

Fixes #112713.

This PR adds support for the new Partitioned attribute in the Morsel object in http.cookies.

• Issue: Support for Partitioned cookies attribute #112713

---

📚 Documentation preview 📚: https://cpython-previews--112714.org.readthedocs.build/

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[gpshead]

I updated the wording here to clarify that Secure is required... but the CHIPS spec doesn't explicitly say anything about Path= though Path=/ appears in all of its examples. What wording should be used regarding Path, I'm not sure how I've phrased this is wholly accurate.

[giles-v]

Per privacycg/CHIPS#49, Path=/ is not needed. I'm going to push an update to this PR shortly.

[gpshead]

should set set Path=/ to also serve as a better example?

[giles-v]

Since Path=/ is no longer required for CHIPS, it seems like this is probably fine as-is.

[gpshead]

I'm leaving this as a Draft PR as whether or not this is desirable isn't settled - it is not yet a standard. We normally wait until something sees actual accepted adoption.

[giles-v]

Understood that CHIPS is a draft and that it probably makes sense to wait until it's ratified before adding to the stdlib. My understanding from reading the RFCs is that it has tentative support from Mozilla and Apple, so hopefully it will be mergeable whenever the wheels of the working groups turn! :)

I want to address this comment from #112713 by @gpshead:

What's the alternative within the existing http.cookies API for adding Partitioned to a cookie it creates and checking for Partitioned when parsing today without implementing your own parsing?

We are planning to provide a custom patch which does something like this (figuratively):

original_morsel_output = Cookie.Morsel.output

def patched_morsel_output(
    self: _MorselType,
    attrs: Optional[List[str]] = None,
    header: str = "Set-Cookie:",
):
    cookie_str = original_morsel_output(self, attrs, header)
    if "samesite=none" in cookie_str.lower():
        cookie_str += "; Partitioned"
    return cookie_str

Cookie.Morsel.output = patched_morsel_output

It's not ideal, but gives us space to also extend the stdlib in other ways since we'll be importing this instead of http.cookie from now on anyway.

[merwok]

@giles-v Please note that discussions on PRs should be about the implementation; wider discussion about the request itself happens on the issue or on python-ideas.

[danielbrunt57]

@merwok, @giles-v
Since 3.13.0rc2 is here already, it looks like this PR won't be merged into the final 3.13.0 release.
Will 3.13.0 Final be able to handle partitioned cookies or not?

[merwok]

Let’s not touch existing lines (better for git history etc)

[giles-v]

We can't avoid it either way, because if we keep the spacing alignment we'll need to realign all the lines to partitioned, being the longest key now.

I'm going to retain @gpshead's preference that we drop the alignment spacing in my rebase commit, and happy to follow whatever consensus emerges if you disagree.

[merwok]

No, keep the existing lines as is and don’t follow the alignment for the new line. Easiest thing to do!

[giles-v]

@merwok updated and marked Ready for Review. My rebasing skills are weak (sorry) but the changeset is correct.

[picnixz]

Since 3.13.0rc2 is here already, it looks like this PR won't be merged into the final 3.13.0 release.
Will 3.13.0 Final be able to handle partitioned cookies or not?

I don't think so. 3.13 won't accept new features per PEP 719: https://peps.python.org/pep-0719/#schedule (thus I'll remove the label).

@merwok By the way, we use the "3.x" labels on issues and "needs backport 3.x" on PRs.

[merwok]

This has missed the beta window, but I think an argument could be made to core-devs and RM on discuss that this change is useful to deal with an external standard. (I don’t have the time to be the one to do that)

We’ve had such a policy for changes to mimetypes for example. On the other hand, this is not a simple addition to a data dictionary, but a code change which we would not backport to stable branches, so the reply could be negative.

(Thanks for the gardening picnixz. GPS added the label, not I)

[giles-v]

This has missed the beta window, but I think an argument could be made to core-devs and RM on discuss that this change is useful to deal with an external standard. (I don’t have the time to be the one to do that)

I would be glad to support such an argument if it's public; given the timeline of Google's CHIPS adoption, waiting for the next release is going to be onerous for users. As someone who has not engaged with the Python community before however I don't think I have any standing to drive a discussion like that either.

[picnixz]

this change is useful to deal with an external standard

In this case, this could be categorized as type-security/bug fix (bugfixes would get backported to 3.12 and security fixes until 3.8) cc @Yhg1s

[merwok]

I think arguing for this feature as a security fix would go too far.

[giles-v]

@merwok @gpshead let me know if anything else is needed to get this approved. Sorry for delays on responding to your comments.