JDK-8035144 : Expires value in MSK timezone in HTTP Header of response does not get respected by plugin.
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u75,7u51,7u76,8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-02-18
  • Updated: 2015-06-03
  • Resolved: 2014-08-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u76Fixed 8u40 b06Fixed 9Fixed
Related Reports
Relates :  
Description
It is noticed that Expires value in MSK timezone in HTTP Header of response does not get respected by plugin.

A typical pair of HTTP Header of request and response in MSK timezone (server side) are look like below:
=============== 
[Request] 
Url: http://127.0.0.1:8080/HTTP_Header_Filter/classes/RunBeforeExpireNoUpdate.jar 
Headers: 
accept-encoding - pack200-gzip, gzip 
content-type - application/x-java-archive 
user-agent - Mozilla/4.0 (Windows 7 6.1) Java/1.8.0-ea 
host - 127.0.0.1:8080 
accept - text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 
connection - keep-alive 

[Response] 200 
ContentLength: 2777 
Headers: 
ETag - W/"2777-1390642986140" 
Expires - Sat, 25 Sep 2055 14:44:18 MSK 
Last-Modified - Sat, 25 Jan 2014 09:43:06 GMT 
Accept-Ranges - bytes 
===================== 

Expired date in very future is sent back, however plugin does not respect this. The net effect is that plugin will try to query the status of the jar again instead of skipping the querying. 

The interesting part is that test executed on China and SCA's machine are both looking good. 
China sent back string look like:
=============== 
Expires - Sat, 25 Sep 2055 17:39:17 CST 
=============== 

Steps to reproduce:
1. Download tomcat and then unzip it locally - http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/stephen/deployment_stuff/do.NOT.remove.me/bugs/INTJDK-7184947/apache-tomcat-6.0.26.zip.
2. Change local timezone to MSK ( Europe/Moscow).
3. Startup the tomcat.
3. Set security level to Medium, since we will run unsigned code. Switch java console on. Set trace level to all.
4. In browser, load http://127.0.0.1:8080/HTTP_Header/html/testRunBeforeExpireNoUpdate.html
5. (You don't need to accept any dialog because whether the applet is working is irrelevant here). Make sure the jar is downloaded by inspecting the trace.
6. Do NOT clean cache.
7. Load the link again, if you see the below in trace, then the issue is reproduced:
===========
cache: Resource http://127.0.0.1:8080/HTTP_Header_Filter/classes/RunBeforeExpireNoUpdate.jar has expired.
network: Connecting http://127.0.0.1:8080/HTTP_Header_Filter/classes/RunBeforeExpireNoUpdate.jar with proxy=DIRECT
network: Connecting http://127.0.0.1:8080/ with proxy=DIRECT
network: ResponseCode for http://127.0.0.1:8080/HTTP_Header_Filter/classes/RunBeforeExpireNoUpdate.jar : 304
============


Expired behavior:
You should see something like below in trace when load the page second time
============
cache: Resource http://127.0.0.1:8080/HTTP_Header_Filter/classes/RunBeforeExpireNoUpdate.jar has future expires: Mon Oct 18 22:55:02 CST 2055 update check skipped.
============
Which means the "Expires" value is respected by plugin.

Note: no such issue when the server side time zone is changed to Biejing or SCA time. You could try to do so by change you local time zone. But remember to shutdown tomcat first before the change, then startup tomcat after the change.

Comments
Please note that three letter timezone codes are deprecated in Java and "CST" could be U.S. "Central Standard Time" and "China Standard Time", and the Java platform can then only recognize one of them. See: http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html
08-08-2014

Crucible review: https://java.se.oracle.com/code/cru/CR-JDK8UDEV-57
06-08-2014

Okay. Technically speaking this isn't a deployment issue. UrlConnection.getExpiration() returns 0 for "Wed, 15 Mar 2056 16:15:25 MSK" because inside it uses a deprecated Date.parse and only expects GMT timezone.I'll discuss it with our team whether it's worth fixing.
06-08-2014

And what's wrong with this ? What exactly are you expecting to see ?
04-08-2014

Tried it with 8u20 and 7u60. For 8u20 I had to sign all jars to be able to run the test. Response headers I got from the tomcat server: Accept-Ranges = [bytes] null = [HTTP/1.1 200 OK] Server = [Apache-Coyote/1.1] ETag = [W/"4346-1405424565465"] Last-Modified = [Tue, 15 Jul 2014 11:42:45 GMT] Expires = [Wed, 15 Mar 2056 16:15:25 MSK] Content-Length = [4346] Date = [Tue, 15 Jul 2014 12:15:25 GMT] Content-Type = [application/java-archive] See the attached 1run.log to see what I get from the first (clean) run. And 2run.log to see what I get after the step #7. I couldn't find "cache: Resource" in the second log. Setting to can't reproduce.
15-07-2014

regression_test_src: http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/8/deployment2/file/ac6a81c8b07c/new_framework/tests/plugin/HTTP_Header/src/HTTP_HeaderTest.java
18-02-2014

Affected tests: HTTP_HeaderTest::testRunBeforeExpireNoUpdate HTTP_HeaderTest::testRunBeforeExpireNoUpdateJnlp HTTP_HeaderTest::testRunBeforeExpireWithUpdate HTTP_HeaderTest::testRunBeforeExpireWithUpdateJnlp
18-02-2014