Hey,
> 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.
>
Oh, I misunderstood your intention, I though you wanted Grizzly to
accept such a JSON cookie.
In general, if people want this "feature" to be supported - we can do
that, but definitely not as default behavior.
Thanks!
WBR,
Alexey.
>> On 21 May 2015 at 23:39 Oleksiy Stashok <oleksiy.stashok_at_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 backslash
>>>
>>> this 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...
>