You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Stefan Fussenegger (JIRA)" <ji...@apache.org> on 2008/08/06 15:26:47 UTC
[jira] Updated: (WICKET-1777) Overflow when setting Expires header
in WebResource
[ https://issues.apache.org/jira/browse/WICKET-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Fussenegger updated WICKET-1777:
---------------------------------------
Description:
problematic code:
response.setDateHeader("Expires", System.currentTimeMillis() + (getCacheDuration() * 1000));
getCacheDuration() * 1000 is an integer operation causing an overflow if getCacheDuration() is set to be > MAX_INT/1000 seconds (approx. 25 days) which is by far less than the w3c recommendation for "never expires":
"To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21
changing getCacheDuration() to return long or forcing a long operation fixes the problem:
response.setDateHeader("Expires", System.currentTimeMillis() + getCacheDuration() * 1000L);
was:
problematic code:
response.setDateHeader("Expires", System.currentTimeMillis() + (getCacheDuration() * 1000));
getCacheDuration() * 1000 is an integer operation causing an overflow if getCacheDuration() is set to be > MAX_INT/1000 seconds (approx. 250 days) which is still less than the w3c recommendation:
"To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21
changing getCacheDuration() to return long or forcing a long operation fixes the problem:
response.setDateHeader("Expires", System.currentTimeMillis() + getCacheDuration() * 1000L);
> Overflow when setting Expires header in WebResource
> ----------------------------------------------------
>
> Key: WICKET-1777
> URL: https://issues.apache.org/jira/browse/WICKET-1777
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.4, 1.4-M3
> Reporter: Stefan Fussenegger
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> problematic code:
> response.setDateHeader("Expires", System.currentTimeMillis() + (getCacheDuration() * 1000));
> getCacheDuration() * 1000 is an integer operation causing an overflow if getCacheDuration() is set to be > MAX_INT/1000 seconds (approx. 25 days) which is by far less than the w3c recommendation for "never expires":
> "To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future."
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21
> changing getCacheDuration() to return long or forcing a long operation fixes the problem:
> response.setDateHeader("Expires", System.currentTimeMillis() + getCacheDuration() * 1000L);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.