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>