Bug 55228 - AbstractHttp11Processor overwrites Date header, even when set by application
Summary: AbstractHttp11Processor overwrites Date header, even when set by application
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.37
Hardware: All All
: P2 major with 1 vote (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-10 00:35 UTC by fern@alum.mit.edu
Modified: 2013-09-11 20:36 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fern@alum.mit.edu 2013-07-10 00:35:33 UTC
If the application sets the Date header, then it is most likely for caching purposes and Tomcat needs to return it as is.



A consistent Date header is very important for proper Age/Max-Age calculations.

http://www.w3.org/Protocols/HTTP/Issues/add-age.html
Comment 1 fern@alum.mit.edu 2013-07-10 00:41:10 UTC
I opened this bug against Tomcat6 since that is what we're using, but this bug exists on all Tomcat7, as well, and most likely Tomcat8.  I'm not sure how to deal with that.



Looking at tomcat-embed-core-7.0.42.jar:
AbstractHttp11Processor.prepareResponse
line: 1458

// Add date header
headers.setValue("Date").setString(FastHttpDateFormat.getCurrentDate());


You see that it sets the Date header, not checking if it had been already set by that application.  Should be able to easily wrap it with:

if ( headers.getValue("Date") == null ) {
  ...
}
Comment 2 Mark Thomas 2013-07-10 11:56:56 UTC
If a bug affects multiple versions open an issue (as you have done) against the earliest supported version you want to see the fix in. Fixes are applied to trunk and then back-ported through each supported version until the bug the issue was reported against is reached. So this will be fixed (assuming the bug is valid and it looks like it is at first glance) in trunk, 7.0.x and 6.0.x.
Comment 3 Mark Thomas 2013-07-10 12:54:44 UTC
I'm currently leaning to resolving this as invalid. As an origin server, Tomcat is required by RFc2616 to set the date header (using the current time) on every request.

I'd be prepared to implement this change given a valid use case but I currently don't see a valid, RFC 2616 compliant reason for an application to set the date header.
Comment 4 fern@alum.mit.edu 2013-07-10 22:06:17 UTC
The valid usecase is that we have implemented a Caching Filter (and many people have to).  And per that spec, we're supposed to return the Date header of when the original response was cached/generated.  It's required so that clients can properly calculate the age of the returned resource.  But Tomcat keeps overwriting the Date header, thus messing up the age calculation.

http://www.w3.org/Protocols/HTTP/Issues/add-age.html
Comment 5 Mark Thomas 2013-07-11 16:05:34 UTC
Fair enough.

This has been fixed for trunk and 7.0.x and will be included in 7.0.43 onwards.

The fix has been proposed for 6.0.x.
Comment 6 Mark Thomas 2013-09-11 20:36:04 UTC
Fixed in 6.0.x and will be included in 6.0.38 onwards.