Issue Details (XML | Word | Printable)

Key: SERVLET_SPEC-37
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Shing Wai Chan
Reporter: gregwilkins
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
servlet-spec

Update Cookie class and other specifications for RFC 6265

Created: 29/Mar/12 03:56 AM   Updated: 22/Feb/13 10:28 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags: FUTURE_RELEASE
Participants: gregwilkins, markt_asf and Shing Wai Chan


 Description  « Hide

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).



gregwilkins added a comment - 29/Mar/12 04:03 AM

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.


markt_asf added a comment - 29/Mar/12 09:00 AM

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.


Shing Wai Chan added a comment - 22/Feb/13 10:28 PM

Adding it to the bucket of FUTURE_RELEASE