Hey Alexey,
i'm not really keen on supporting JSON data. IMHO Clients should properly encode the data, yet Grizzly has to behave more defensively. I was thinking about at least catching the IllegalArgumentException when constructing javax.servlet.http.Cookies. I'll probably create a patch anyway when i'm back at work tomorrow.
A config parameter to toggle the behaviour might be an option but it might enable things like https://www.owasp.org/index.php/HTTP_Response_Splitting or other attacks.
On 21 May 2015 at 23:39 Oleksiy Stashok <oleksiy.stashok@oracle.com> wrote:
Hi Marc,
IMO we can keep current implementation as a default, but at the same time we can introduce a config parameter to be able to support json cookies.
WDYT?
WBR,
Alexey.
On 21.05.15 14:09, Marc Arens wrote:Moin,
web developers seem to get creative these days and start storing unencoded/stringified JSON data in cookies (see [1] for examples). As commas are forbidden as part of the cookie value per rfc 6265 [2] AFAIU
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslashthis of course causes problems when these cookies reach the grizzly server as part of a normal request. Grizzly versions from 2.2 to 2.3 split the cookie values after the ',' which might cause further exceptions and break the complete request.
e.g.
issue a request like: curl -v --cookie "name={\"id\":\"5070419\",\"Version\":\"undefined\"}"Grizzly now turns the JSON into two cookies
Cookie1:
Name: name
Value: {"id":"5070419"
Cookie2:
Name: Version
Value:If you are now using Servlets within Grizzly this will fail with an IllegalStateException while trying to create Cookies
Caused by: java.lang.IllegalArgumentException: Cookie name "Version" is a reserved token
at javax.servlet.http.Cookie.<init>(Cookie.java:150)
at org.glassfish.grizzly.servlet.HttpServletRequestImpl.getCookies(HttpServletRequestImpl.java:1127)
I compared Grizzly's cookie parsing to Jetty and while Jetty 7 fails in a slightly different way
Cookie1:
Name: name
Value: {"id":"5070419"
Cookie2:
Name: Version
Value:Jetty 9 seems to parse the cookie "correctly"
Cookie1:
Name: name
Value: {"id":"5070419","Version":"undefined"}
So my question is: Should Grizzly's cookie parsing be adjusted to behave more like Jetty although the RFC is pretty clear on this topic? What's your opinion on this? Maybe dropping malformed cookies while logging an error to simply defend against bad behaviour would be the way to go?
[1] https://github.com/carhartl/jquery-cookie
[2] http://tools.ietf.org/html/rfc6265#section-4.1.1
...it was evening and it was morning and there were already two ways to store Unicode...
...it was evening and it was morning and there were already two ways to store Unicode...