Add Cookie#setAttribute

[BalusC]

For discussion, see #175 and #271

While at it I also took opportunity to:

• cleanup isToken helper method whose comment and methodname were completely out of sync with actual implementation
• fix "rfc2019" typo in comments to "rfc2109"
• add missing check for "HttpOnly" in cookie name
• removed outdated javadoc wrt version 1 being "experimental"

[BalusC]

Some thoughts:

• perhaps add removeAttribute() (this is likely to lead to confusing expected behavior, much better is to just not set attribute in frist place)
• perhaps detail in javadoc how exactly empty strings and nulls should be interpreted (natural expectation: empty string represents a boolean attribute such as Secure and null indicates that any predefined attribute should not be set)
• perhaps rename setAttribute() / getAttributes() to overrideAttribute() / getOverriddenAttributes() as that more clearly describes intended behavior

[joakime]

Since you are touching the RFC / version details in the javadoc, do we want to mention that RFC2109 is obsolete and replaced with RFC2965 which is also now obsolete and replaced with RFC6265.
The use of "Version" in the Cookie is also increasingly unsupported in modern browser updates (most browsers will either ignore the version attribute, or the entire cookie if it contains a version attribute).

[BalusC]

Candidate for a new ticket/PR indeed but not applicable in current context.

[joakime]

This PR is especially timely, considering that Chrome and Firefox devs are discussing a new Partitioned attribute for the Cookie spec on the ietf-http-wg

• https://lists.w3.org/Archives/Public/ietf-http-wg/2021AprJun/0099.html
• https://lists.w3.org/Archives/Public/ietf-http-wg/2021AprJun/0102.html
• https://hacks.mozilla.org/2021/02/introducing-state-partitioning/
• Let embedees optionally request access to partitioned cookies and storage privacycg/storage-access#75
• https://discourse.wicg.io/t/proposal-cookies-having-independent-partitioned-state-chips/5290
• https://github.com/DCtheTall/CHIPS

[pzygielo]

It looks that cloned Cookie shares *attributes with original. Is that as intended?

[gregw]

The implementation here needs to enforce the apidoc above that says:

This should override any predefined attribute for which already a getter/setter pair exist in the current version.

This can be done be removing all the fields and using only the map to store the attributes (and then updating the getters/setters accordingly). Alternately, known fields can be intercepted here and call the setters directly.

Eitherway, we need for the known fields to always appear in the map or to never appear in the map, and never have different values if they appear in both.

[BalusC]

Alternately, known fields can be intercepted here and call the setters directly.

That won't work in long term. An good example is the earlier proposal to make SameSite an enum. We want the API to behave in best possible compatible way when HTTP guys at some point decide to add a new value to the enumeration.

This can be done be removing all the fields and using only the map to store the attributes (and then updating the getters/setters accordingly).

It could only work if we redocument non-String getter methods to throw some runtime exception when an "incompatible" value was set via setAttribute().

[BalusC]

I've prepped another PR for this: #400

[BalusC]

Closing off. This is superseded by #400