Wicket
  1. Wicket
  2. WICKET-1777

Overflow when setting Expires header in WebResource

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.4, 1.4-M3
    • Fix Version/s: 1.3.5, 1.4-RC1
    • Component/s: wicket
    • Labels:
      None

      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);

        Activity

        Stefan Fussenegger created issue -
        Stefan Fussenegger made changes -
        Field Original Value New Value
        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. 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);
        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);
        Igor Vaynberg made changes -
        Assignee Igor Vaynberg [ ivaynberg ]
        Igor Vaynberg made changes -
        Fix Version/s 1.3.5 [ 12313175 ]
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.4-M4 [ 12313295 ]

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Stefan Fussenegger
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 5m
              5m
              Remaining:
              Remaining Estimate - 5m
              5m
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development