Bug 62476 - Expires header shall use GMT timezone
Summary: Expires header shall use GMT timezone
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 9.0.8
Hardware: PC All
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2018-06-20 13:24 UTC by Konstantin Kolinko
Modified: 2018-06-20 15:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kolinko 2018-06-20 13:24:20 UTC
This issue was originally reported in a pull request 

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

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

The "Expires" header should be in GMT, like the "Date" header already is.


The chapter 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.