Custom Cookies

[mkarg]

Cookies, just as other aspects of HTTP, are under constant evolution. Unfortunately, there is no extension point in JAX-RS which allows to experimentally support new types of cookies. So at the moment, JAX-RS needs to adopt all new types of cookies in a hard-coded fashion. This prevents early adoption of new cookie types.

To allow application and implementation vendors to support constant cookie evolution, we should provide an extension point for custom cookies. So applications can provide custom cookies long before a hard-coded support is added to the JAX-RS standard.

[mkarg]

@eclipse-ee4j/ee4j-jaxrs-committers Comments? Ideas? :-)

[chkal]

I don't think that we need "custom cookie types", but "custom cookie attributes". And this could be achieved by adding a list of "custom attributes" to the NewCookie class.

Something like:

var cookie = new NewCookie( "key", "value", "/", null, null, 1000, true, true );
cookie.setCustomAttributes( Arrays.asList( "Foo", "Bar" ) );

Which would produce something like:

Set-Cookie: key=value; path=/; Max-Age=1000; Secure; HttpOnly; Foo; Bar

Currently, the NewCookie class is immutable, so perhaps the list of custom attributes should be supplied via the constructor. But that basically what I had in mind.

[mkarg]

I don't think that we need "custom cookie types", but "custom cookie attributes". And this could be achieved by adding a list of "custom attributes" to the NewCookie class.

Given the fact that a type is defined by the sum of its attributes, this is exactly what I meant. ;-)

On the other hand, it might be beneficial in some use cases to actually have a bit more support:

• Receivers of cookies would love to write receivedCookie.isFoo() (in contrast to myCookiePojo.isFoo() which already is possible), so in alignment with the general extensions design of JAX-RS it would make sense to have a "Cookie Provider" class which parses incoming cookie syntax into custom Cookie subclasses? The specification currently says such providers provide either a POJO or a Cookie, so maybe we could extend it to the case of subclasses of Cookie to guarantee this to work?
• Senders of cookies would like to have a CookieBuilder instead of endless parameter lists in constructors?