Hi, On Thu, Nov 21, 2019 at 6:44 PM Chris Hegarty <chris.hega...@oracle.com> wrote: > I’m still doing some background reading, but it seems at the very minimum > that the less-than-fresh java.net.HttpCookie would need to know about, and > support, the SameSite attribute. Currently attributes are modelled through a > pair of explicit per-attribute mutators and accessors, so ( following that > style ) SameSite would need a new pair of these. ( maybe a more general > modelling of attributes is needed? ) Without a general modelling of > attributes, and without SameSite being published as part of an RFC, then I’d > be reluctant to bake SameSite into the Java SE Specification ( as a pair of > mutators and accessors methods ). > > Maybe I’m missing your point or making an incorrect assumption ( I’m still > digesting some of this material )?
On the client side it would be nice to have the SameSite semantic implemented, I would say. I mean that HttpClient (in general, but more specifically java.net.CookieStore) should return cookies also taking into account the SameSite semantic, similarly to what it does today where it takes into account the Domain and Path and Secure attributes. Also, applications may need to know if a cookie had a SameSite attribute and what was its value (and therefore either a specific getter, or a generic, map-like, way to retrieve cookie attributes). A generic way to retrieve cookie attributes would allow applications to manually implement logics such as SameSite. Currently the only option applications have is to _not_ use the JDK classes (CookieManager & CookieStore) and do manually the parsing of Set-Cookie, the storage of cookies, and their retrieval - it's not optimal (code duplication, introducing bugs, different interpretation of the spec, etc.). -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
