|Summary:||Expires header shall use GMT timezone|
|Product:||Tomcat 9||Reporter:||Konstantin Kolinko <knst.kolinko>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Description Konstantin Kolinko 2018-06-20 13:24:20 UTC
This issue was originally reported in a pull request https://github.com/apache/tomcat/pull/115 I am confirming the issue and stating it here for a more clear description. Steps to reproduce: 1. Start Tomcat 2. Open a Browser and configure it to inspect network traffic (e.g. open "Network" tab in Developer's tools in Firefox) 3. Navigate to http://localhost:8080/examples/jsp/security/protected/index.jsp ACTUAL BEHAVIOR, Tomcat 9: The following response headers are sent by the server: [[[ HTTP/1.1 200 Cache-Control: private Expires: Thu, 01 Jan 1970 03:00:00 MSK Set-Cookie: JSESSIONID=1D318BE83811595C4AAB11B7859D613B; Path=/examples; HttpOnly Content-Type: text/html;charset=ISO-8859-1 Content-Length: 650 Date: Wed, 20 Jun 2018 13:04:40 GMT ]]] EXPECTED BEHAVIOR: The "Expires" header should be in GMT, like the "Date" header already is. SPECIFICATION: https://tools.ietf.org/html/rfc7234#section-5.3 https://tools.ietf.org/html/rfc7231#section-22.214.171.124 The chapter 126.96.36.199 defines "IMF-fixdate" production with literal string of "GMT". Obsolete date time formats there ("obs-date") do not cover this case either: they are for rfc850 and asctime dates. > GMT = %x47.4D.54 ; "GMT", case-sensitive This issue is reproducible with Tomcat 9. It is reproducible with Tomcat 7.0.88 as well.
Comment 1 Michael Osipov 2018-06-20 13:44:36 UTC
I'd send a fixed string literal instead of calculating it with a non-threadsafe SimpleDateFormat over and over again.
Comment 2 Konstantin Kolinko 2018-06-20 14:31:56 UTC
It is a static constant. It is calculated only once. Looking at references to RFC1123_DATE constant, I am more concerned of "TimeZone.getTimeZone("GMT")" calls in Response#addDateHeader(), #setDateHeader(), as getTimeZone() is a synchronized method. I tested and the value received by browser with r1833915 is Expires: Thu, 01 Jan 1970 00:00:00 GMT The 1ms in "new Date(1)" is nowhere to be seen.
Comment 3 Mark Thomas 2018-06-20 15:05:46 UTC
Fixed in: - trunk for 9.0.10 onwards - 8.5.x for 8.5.32 onwards - 8.0.x for 8.0.53 onwards - 7.0.x for 7.0.89 onwards I plan to review all of the standard date formatting and parsing for the next release round. I think there is scope to reduce duplication and syncs. Response#addDateHeader(), #setDateHeader() should be OK as the format is created on first use and then re-used.