Set-Cookie header in Glassfish-5: folding several cookies in one header not working on Firefox (https + HTTP/2.0)

Question

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:

3. 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: 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...

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

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

Once again on FireFox - 2 cookies in one Set-Cookie header:

Received only one - and the value is not correct... :

The same on Firefox Developer Edition:

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.

Answer 1

_{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.}

Answer 2

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.

Answer 3

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!