You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/02/21 17:29:32 UTC
DO NOT REPLY [Bug 6616] New: -
date headers not working properly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6616>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6616
date headers not working properly
Summary: date headers not working properly
Product: Tomcat 3
Version: 3.3 Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: emiller@planalytics.com
Under regular use, DateTool.format1123(...) does not work.
The logic used to determine when to use the cached date/date String is
incorrect (it uses % instead of /). This is particularly nasty when the
persistence mechanism only has precision to the second (most file systems and
DB's), as the RFC 1123 String representation of date headers will not change
once it has been set once. This renders getLastModified(HttpServletRequest)
useless.
The caching of the data is not Thread-safe and it also does not reflect the
date format being used.
A simple correction is just:
public static String format1123( Date d ) {
return rfc1123Format.format( d );
}
public static String format1123( Date d,DateFormat df ) {
return df.format( d );
}
I don't know if the code to support proper synchronization and date-format
storage would ultimately offset the cost of SimpleDateFormat.format(...).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>