12

I noticed that Glassfish-5 web server sends responses with only one Set-Cookie header, which contains several cookies. When I looking with firebug, I can see that they are separated by unknown character. Anyway - the Firefox reads only the first cookie. How to configure Glassfish5 to send several Set-Cookie headers - one for each cookie? rfc6265 states that:

  1. Overview
    ...
    Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. The usual mechanism for folding HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.
    ...

Also here it is stated:

When sending an HTTP Response with multiple cookies, CFHTTPMessage combines the cookies into a comma-separated list under a single "Set-Cookie" HTTP header. (This is referred to as "set-cookie-folding".)

Set-cookie-folding is NOT supported on Google Chrome, Firefox, and Internet Explorer. Each of those browsers will completely ignore every cookie after the first comma, rendering CFHTTPMessage completely useless for handling HTTP responses with multiple cookies in any browser other than Safari (which supports cookie-folding).

This is how the response looks on firebug: enter image description here Two cookies are joint by unknown character. As I noticed - other servers like Apache splits multiple cookies in one Set-Cookie header by new line character.

I've noticed that this happens only on HTTPS connections.

Also, I've opened an issue on Github here.

Tried the same web application to run on Tomcat 9 web server - Set-Cookie header cookies are separated by new line character, it's working like expected... enter image description here

The same response, but on Glassfish5, and again - cookies are joined by unknown character, and are not accepted by Firefox (just the first one): enter image description here

In NetBeans IDE 8.2 HTTP Server Monitor I can see, that 2 cookies are sent - it looks ok: enter image description here

Once again on FireFox - 2 cookies in one Set-Cookie header: enter image description here

Received only one - and the value is not correct... : enter image description here

The same on Firefox Developer Edition:
enter image description here

Totally confused..

Glassfish 5 uses Grizzly Framework 2.4.0 - I think sources available in grizzly-http-servlet-2.4.0-sources.jar - but can not find a code piece where the cookies are joined together in one line..

I can confirm now that it is related only to HTTP/2.0 protocol, tested on firefox by enabling/disabling network.http.spdy.enabled.http2 in about:config. On HTTP/1.1 via HTTPS cookies are set as expected.

Community
  • 1
  • 1
Ernestas Gruodis
  • 8,567
  • 14
  • 55
  • 117
  • could you please tell me the char code? – Dmitry Senkovich Aug 14 '17 at 13:17
  • Dang, I just realized you're using *Firebug*... With HTTP/2... Quoting getfirebug.com: *The Firebug extension isn't being developed or maintained any longer. We invite you to use the Firefox DevTools instead*. Okay there's Firebug.next, but... Do you still see this strange character with Firefox DevTools' Network tab? And how do you observe that only the first cookie works? – Hugues M. Aug 14 '17 at 22:30
  • Yes, it is the same on Firefox Developer Ed. I can check the cookies received by Tools -> Options -> Remove individual cookies. – Ernestas Gruodis Aug 14 '17 at 22:57
  • Also noticed that NetBeans IDE 8.2 HTTP Server Monitor shows request protocol HTTP/2.0, so it means it supports HTTP/2.0 ? – Ernestas Gruodis Aug 14 '17 at 23:24

3 Answers3

3

In a series of comments that we deleted since, I pointed that the weird responses were all http2, and gave directions to disable it server-side, as a work-around. Now to make room for other constructive comments (or answers) we deleted the old ones, and I rehashed them as a separate answer below.

It seems Grizzly's http2 filters are misbehaving (well let's assume that for a moment). Your Firefox screenshots are showing HTTP/2.0. NetBeans server monitor works OK likely because it does not support http2, so your server falls back to HTTP/1.1 in that case. (Edit: that was just a supposition, and a more recent comment hints that it might support http2...)

Grizzly supports HTTP2 since 2.4.0 but you have to explicitly enable it... and GlassFish does that by default.

How to configure Glassfish5 to send several Set-Cookie headers - one for each cookie?

While the Glassfish/Grizzly team works on fixing the (apparent) bug, you can disable http2 in GlassFish as a work-around.

Assuming your HTTPS listener is http-listener-2 you can do this from the command line:

asadmin set server.network-config.protocols.protocol.http-listener-2.htt‌​p.http2-enabled=fals‌​e

As far as I know this setting is not documented yet, I inferred the command above from this @Attribute in source code (and followed it through the code until GenericGrizzlyListener). In addition, it seems that attribute is not exposed in the admin console so I see no other way than using asadmin set as above (please note the "Version" attribute is a distinct setting).

I based my research on "latest promoted build" (b19 at that time, "latest nightly" would be b20). Links to GitHub point to b19.

Hugues M.
  • 19,846
  • 6
  • 37
  • 65
  • I can confirm that `asadmin set server.network-config.protocols.protocol.http-listener-2.htt‌​p.http2-enabled=fals‌​e` is working, so this is a temporary solution. – Ernestas Gruodis Aug 14 '17 at 20:07
1

The problem is now solved by professional glassfish team - we should change the file nucleus-grizzly-all.jar file with new one - available here at GitHub. Once again - many thanks to glassfish developer team!

Ernestas Gruodis
  • 8,567
  • 14
  • 55
  • 117
  • 1
    Ah, cool. So I think the problem was [here in EncoderUtils](https://github.com/javaee/grizzly/blob/33342e0858ec365424d7819bc3972d4fbaf1d629/modules/http2/src/main/java/org/glassfish/grizzly/http2/EncoderUtils.java#L287), the pesky character was a null character (`\u0000`), and the fixing commit is [here](https://github.com/javaee/grizzly/commit/a4196e096e34dd16988cc0283e9eb6de598713f2), (although the comment references another bug in the grizzly issues base, but perhaps it actually fixed several). – Hugues M. Aug 17 '17 at 22:16
1

You no longer need that custom nucleus-grizzly-all.jar. The issue has been released as part of the most recent Glassfish 5.0 nightlies and the most recent promoted build.

There were two different issues as I tracked the actual fix with a Grizzly issue and used the GlassFish issue for integration of Grizzly.

rlubke
  • 965
  • 5
  • 14