Bug ID: JDK-8193348 All but first cookie sent from server are ignored by JWS client

JDK-8193348 : All but first cookie sent from server are ignored by JWS client

Type: Bug
Component: deploy
Sub-Component: webstart
Affected Version: 8u151

Priority: P3
Status: Closed
Resolution: Duplicate
OS: windows_7
CPU: x86_64

Submitted: 2017-12-11
Updated: 2018-05-31
Resolved: 2018-05-14

Related Reports

Duplicate :	JDK-8190689 - Java incorrectly requires "HttpOnly" cookie attribute to be case sensitive
Relates :	JDK-8190689 - Java incorrectly requires "HttpOnly" cookie attribute to be case sensitive

Description

FULL PRODUCT VERSION :
1.8.0_151

ADDITIONAL OS VERSION INFORMATION :
It does not matter. The problem shows on every Windows version from XP to 7 to 10.

A DESCRIPTION OF THE PROBLEM :
We have a web application that starts a Java application by Java Web Start. Our application server is behind a load balancer that adds a Load Balancer Session Stickyness cookie to each request. However, the client never sends back that cookie, so the load balancer is unable to route the new requests correctly. Note, that this is not a problem of the application that is called, but of JWS itself, as the request to load the Java app from the server is already missing the stickyness cookie. Here is an example from a *client* net trace:

----------------------
Client => Server

GET /someuri/publicapi/appname/302465FB61294AC6BDB38817A03AE823 HTTP/1.1
accept-encoding: gzip
User-Agent: JNLP/1.7.0 javaws/11.151.2.12 (<internal>) Java/1.8.0_151
UA-Java-Version: 1.8.0_151
Cache-Control: no-cache
Pragma: no-cache
Host: our.application.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Cookie: LoginCookie=AnUser%7c123%7cde-DE

----------------
Server => Client

HTTP/1.1 200 OK
Date: Mon, 11 Dec 2017 12:16:24 GMT
Server: Microsoft-IIS/8.5
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 1596
Content-Type: application/x-java-jnlp-file
Expires: -1
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Set-Cookie: ASP.NET_SessionId=vepnxqr9sym2lyzuhrgu3mk9; path=/; HttpOnly
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Set-Cookie: LVpersistence=kq21422o00000000000000000000ffff0dc11affo443; path=/; Httponly

<?xml version="1.0" encoding="UTF-8"?><jnlp spec="1.0+" codebase="https://our.application.com/someuri/Components/AppName" href="https://our.application.com/someuri/publicapi/appname/302465FB61294AC6BDB38817A03AE823"><information><title>AppName</title><vendor>Some Vendor, Inc.</vendor></information><security><all-permissions /></security><resources><j2se version="1.8+" /><jar href="AppName.jar" /><jar href="AppNameExt.jar" /></resources><application-desc main-class="somevendor.AppName.webstart.AppNameWebStart"><argument>-DocumentURL</argument><argument>https://our.application.com/someuri/publicapi/appname/302465FB61294AC6BDB38817A03AE823/Sign</argument><argument>-SignatureFormatType</argument><argument>3</argument><argument>-PostSignedData</argument><argument>on</argument><argument>-PostURL</argument><argument>https://our.application.com/someuri/publicapi/appname/302465FB61294AC6BDB38817A03AE823/PostURL/</argument><argument>-FinishURL</argument><argument>https://our.application.com/someuri/publicapi/appname/302465FB61294AC6BDB38817A03AE823/FinishURL/</argument><argument>-CancelURL</argument><argument>https://our.application.com/someuri/publicapi/appname/302465FB61294AC6BDB38817A03AE823/CancelURL/</argument><argument>-ErrorURL</argument><argument>https://our.application.com/someuri/publicapi/appname/302465FB61294AC6BDB38817A03AE823/ErrorURL/</argument><argument>-ShowUrlsInBrowser</argument><argument>off</argument></application-desc></jnlp>

----------------
Client => Server

GET /someuri/Components/AppName/AppName.jar HTTP/1.1
content-type: application/x-java-archive
accept-encoding: pack200-gzip,gzip
User-Agent: JNLP/1.7.0 javaws/11.151.2.12 (<internal>) Java/1.8.0_151
UA-Java-Version: 1.8.0_151
Cache-Control: no-cache
Pragma: no-cache
Host: our.application.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
If-Modified-Since: Fri, 20 Oct 2017 15:48:25 GMT
Cookie: LoginCookie=AnUser%7c123%7cde-DE; ASP.NET_SessionId=vepnxqr9sym2lyzuhrgu3mk9

As one can see the cookie "LVpersistence" is *not* sent back from the client to the server. This behaviour started as soon as we deployed JRE 1.8.0_151. We did not see that happen before.


REGRESSION.  Last worked in version 8u141

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create some Java app to be loaded from the server
2. Access the server through a load balancer
3. Configure the load balancer to add a session stickyness cookie to each response
4. Start the Java App on the client from a web page wie Java Web Start


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JWS should send back the session stickyness cookie to the load balancer when requesting the jar file of the application to be run on the client and for every request following the first.
ACTUAL -
JWS does not send back the session stickyness cookie.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages, no crashes.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
There is no source code. Just use any JWS app.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No workaround.

Comments

the app sets: Set-Cookie: ASP.NET_SessionId=vepnxqr9sym2lyzuhrgu3mk9; path=/; HttpOnly Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Set-Cookie: LVpersistence=kq21422o00000000000000000000ffff0dc11affo443; path=/; Httponly first cookie is "HttpOnly", second is "Httponly" this looks like an instance of https://bugs.openjdk.java.net/browse/JDK-8190689 fixed in 8u181
07-05-2018
does it affect 10?
14-02-2018
Updating with the additional information shared by the submitter: ========================================== Our web application offers a button that will download JNLP file. You can see the JNLP file in the web trace. It looks something like this: <?xml version="1.0" encoding="UTF-8"?> <jnlp spec="1.0+" codebase="https://our.url.com/HomeDir/Components/AppName" href="https://our.url.com/HomeDir/api/AppName/8BCDE6E168EE4FD4842AC07B75F9643F"> <information> <title>AppName</title> <vendor>Some Company, Inc.</vendor> </information> <security> <all-permissions /> </security> <resources> <j2se version="1.8+" /> <jar href="AppName.jar" /> <jar href="AppNameExt.jar" /> </resources> <application-desc main-class="somecompany.AppName.webstart.AppNameWebStart"> <argument>-DocumentURL</argument> <argument>https://our.url.com/HomeDir/api/AppName/8BCDE6E168EE4FD4842AC07B75F9643F/Sign</argument> <argument>-SignatureFormatType</argument> <argument>3</argument> <argument>-PostSignedData</argument> <argument>on</argument> <argument>-PostURL</argument> <argument>https://our.url.com/HomeDir/api/AppName/8BCDE6E168EE4FD4842AC07B75F9643F/PostURL/</argument> <argument>-FinishURL</argument> <argument>https://our.url.com/HomeDir/api/AppName/8BCDE6E168EE4FD4842AC07B75F9643F/FinishURL/</argument> <argument>-CancelURL</argument> <argument>https://our.url.com/HomeDir/api/AppName/8BCDE6E168EE4FD4842AC07B75F9643F/CancelURL/</argument> <argument>-ErrorURL</argument> <argument>https://our.url.com/HomeDir/api/AppName/8BCDE6E168EE4FD4842AC07B75F9643F/ErrorURL/</argument> <argument>-ShowUrlsInBrowser</argument> <argument>off</argument> </application-desc> </jnlp> The user has to double-click this file and then JWS will execute it. My trace starts after this double-click. You can easily write a dummy Web Start application that is called by a JNLP file. Remove all the "<argument>s". They are not needed to reproduce the issue. As I said, the bug is not in the app but in JWS itself. Then you can simulate a load balancer by using the Fiddler proxy (https://www.telerik.com/fiddler). I inserted the following code in Fiddler's CustomRules.js file in the method "onBeforeResponse": if (oSession.uriContains("AppName")) { oSession.oResponse.headers.Remove("Keep-Alive"); // Remove 2 headers ... oSession.oResponse.headers.Remove("Connection"); oSession.oResponse.headers.Add("Set-Cookie","ASP.NET_SessionId=vepnuzwfsyf2kyzuhoou4mj1; path=/; HttpOnly"); oSession.oResponse.headers.Add("Keep-Alive","timeout=15, max=100"); // ... and put them between 2 Set-Cookie headers oSession.oResponse.headers.Add("Connection","Keep-Alive"); oSession.oResponse.headers.Add("Set-Cookie","LVpersistence=rd20402o00000000000000000000ffff0ab3fc5fo443; path=/; Httponly"); } Now Fiddler will add the 2 Set-Cookie headers to every response coming from a web uri that contains "AppName". Of course, you will have to replace "AppName" by whatever name you gave to your test Web Start application. ========================================================
14-02-2018
Reported with JDK 8u151 Windows 7 The issue seems related to a production environment and is difficult to reproduce in house. According to the description, A JWS application is served from an application server that is behind a load balancer while adding a load balancer session stickyness cookie to each request. The load balancer fails to route the new requests correctly since the client server never sends back the cookie. As per submitter the issue is with JWS itself, as the request to load the Java app from the server is already missing the stickyness cookie. Checking with submitter to provide additional information and a complete test case to verify this issue in house.
12-12-2017