struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (WW-3492) DefaultHttpHeaders does not handle last-modified and if-modified-since requests correctly
Date Mon, 28 Jan 2013 06:57:13 GMT


Hudson commented on WW-3492:

Integrated in Struts2-JDK6 #633 (See [])
    WW-3492 uses getter instead direct field access (Revision 1439265)

     Result = SUCCESS
lukaszlenart : 
Files : 
* /struts/struts2/trunk/plugins/rest/src/test/java/org/apache/struts2/rest/

> DefaultHttpHeaders does not handle last-modified and if-modified-since requests correctly
> -----------------------------------------------------------------------------------------
>                 Key: WW-3492
>                 URL:
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Plugin - REST
>    Affects Versions:
>            Reporter: Gordon McNaughton
>            Assignee: Lukasz Lenart
>            Priority: Minor
>             Fix For: 2.3.9
> 1.  Create a controller method that creates a DefaultHttpHeaders object, then calls lastModified(...).withNoETag()
> 2.  Hit the method in a browser; verify that the response contains a "Last-Modified"
header and no "ETag" header
> 3.  Refresh the browser
> 4.  Verify that the browser request contains an "If-Modified-Since" header with the same
> 5.  Look at the http response code
> What happens?
> The controller returns a 200 OK instead of a 304 Not Modified, so the browser can't use
its cache.
> DefaultHttpHeaders has code ( ln 132) that tries to determine
whether the last modified date matches the "If-Modified-Since" header.  However, it does so
by making a string comparison between the header string ("Tue Sep 07 16:34:08 PDT 2010") and
a number of milliseconds ("112345..."), which is going to fail.
> I worked around this by adding custom code to the controller that compares lastModified
and If-Modified-Since, and calls withStatus(HttpServletResponse.SC_NOT_MODIFIED) if appropriate,
but it would be cleaner if DefaultHttpHeaders handled this automatically (as it is obviously
trying to do).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message