Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Cookie class and other specifications for RFC 6265 #37

Closed
glassfishrobot opened this issue Mar 29, 2012 · 8 comments
Closed

Update Cookie class and other specifications for RFC 6265 #37

glassfishrobot opened this issue Mar 29, 2012 · 8 comments
Labels
Candidate4NextRelease This issues should be consider for inclusion in the next release project. Enhancement New feature or request

Comments

@glassfishrobot
Copy link

Currently the Cookie class defaults to supporting RFC 2019 cookies.
RFC2019 was obsoleted by RFC2965 in 2000, which in turn was obsoleted by RFC6265 in 2011

The latest RFC appears to be well supported by browsers (eg Google cookies often contain commas which are not allowed by 2019, but are by 6265).

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
Reported by gregwilkins

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
gregwilkins said:
Actually my example of a , in the cookie value is wrong, as although google appears do be doing that, it is not allowed by RFC6265.
However, I do believe it is worthwhile reviewing the Cookie class and other cookie related parts of the spec against the latest RFC.

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
markt_asf said:
My experience has been that no matter what cookie specification is followed by the container, there will be a client or application that can't handle specification compliant values. We have had to add no end of hacks to Tomcat's cookie handling to allow checks to be bypassed to enable stuff to actually work. For example, anything that requires quoting (such as using commas in values) is often not handled correctly if it is quoted.

There is a clear unwillingness on the part of some browser vendors to adhere to the cookie specifications and no sign of this being a something that causes users to migrate to a more standards compliant browser.

I don't particularly like the situation that has lead to RFC 6265 (I would have preferred to see user demand driving browser compliance but that hasn't happened) but RFC 6265 is probably the best option since it is closer to what is actually happening than anything else. That said, I suspect container vendors will still need to add additional options to bypass some checks.

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
@shingwaichan said:
Adding it to the bucket of FUTURE_RELEASE

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
markt_asf said:
Ping. This really needs to get into Servlet 4.0

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
christopherschultz said:
+1 for updating and clarifying the spec. If Servlet 4.0 still contains a requirement to support RFC2019 (and nothing more recent), then the Java ecosystem will continue to suffer this confusion for another few years.

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
This issue was imported from java.net JIRA SERVLET_SPEC-37

@glassfishrobot
Copy link
Author

@gregw gregw added Enhancement New feature or request and removed Component: HTTP labels Jan 18, 2020
@gregw gregw added the Candidate4NextRelease This issues should be consider for inclusion in the next release project. label Sep 8, 2020
markt-asf added a commit to markt-asf/servlet-api that referenced this issue Nov 18, 2021
In summary:
- setVersion() is NO-OP, getVersion() is hard-coded to 0
- Restrictions on cookie name relaxed to 'must be non-null, non-empty
token'
markt-asf added a commit to markt-asf/servlet-api that referenced this issue Nov 19, 2021
In summary:
- setVersion() is NO-OP, getVersion() is hard-coded to 0
- Restrictions on cookie name relaxed to 'must be non-null, non-empty
token'
markt-asf added a commit to markt-asf/servlet-api that referenced this issue Nov 23, 2021
In summary:
- setVersion() is NO-OP, getVersion() is hard-coded to 0
- Restrictions on cookie name relaxed to 'must be non-null, non-empty
token'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Candidate4NextRelease This issues should be consider for inclusion in the next release project. Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants