Hey Alexey,
my current approach looks like this
https://github.com/dermarens/grizzly-mirror/commit/bcc9184451fe55576c088b688c82489090fc81f2
No idea if a github pull request would be useful to you as you use github as
readonly mirror AFAIU.
> On 22 May 2015 at 01:48 Oleksiy Stashok <oleksiy.stashok_at_oracle.com> wrote:
>
>
> 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...
> >
>
...it was evening and it was morning and there were already two ways to store
Unicode...