Forum Discussion

Chris_FP's avatar
Chris_FP
Icon for Cirrus rankCirrus
Aug 04, 2014

iRule adding extra time to HTTP::cookie expires <cookiename> 1200 relative command

We have an iRule which adds a version 0 cookie (suffice to say it has to be version 0 due to browser versions...) and also performs a HTTP::cookie expires 1200 relative.

 

However when I use firebug to view the cookie it shows an expiry time, not of 1200s into the future, but roughly 1300s into the future.

 

If I change the command to HTTP::cookie expires 1 relative which should mean it expires within 1 second the cookie arrives with an expiry of around 90s

 

The F5 has NTP enabled and has the correct time showing, the laptop also has NTP / correct time so I am at a loss to understand why the additional time being added to the cookie.

 

Is this a known bug or can somebody suggest something else I can check.

 

Regards

 

8 Replies

  • I have now tried this on 2 different F5's (virtual) - going to different back-ends etc, one running 11.3.1 and the other running 11.4.1 and they both exhibit the same behaviour!
  • Arent you missing a cookie name from that command?

    HTTP::cookie expires cookiename 1 relative
    
    • Chris_FP's avatar
      Chris_FP
      Icon for Cirrus rankCirrus
      cookiename is the scrubbed version of what the cookie is actually called...
  • it seems okay here. i am using 11.5.1. sgt is gmt+8.

    // HTTP::cookie expires test 1 relative
    
     config
    
    root@(B6900-R69-S40)(cfg-sync Standalone)(Active)(/Common)(tmos) list ltm virtual bar
    ltm virtual bar {
        destination 100.100.100.41:80
        ip-protocol tcp
        mask 255.255.255.255
        pool foo
        profiles {
            http { }
            tcp { }
        }
        rules {
            qux
        }
        source 0.0.0.0/0
        source-address-translation {
            type automap
        }
        vs-index 2
    }
    root@(B6900-R69-S40)(cfg-sync Standalone)(Active)(/Common)(tmos) list ltm rule qux
    ltm rule qux {
        when HTTP_RESPONSE {
      HTTP::cookie insert name test value 1234 path / version 0
      HTTP::cookie expires test 1 relative
    }
    }
    
     test
    
    [root@client3 ~] date; curl -I http://100.100.100.41
    Tue Aug  5 15:41:01 SGT 2014
    HTTP/1.1 200 OK
    Date: Tue, 05 Aug 2014 07:28:45 GMT
    Server: Apache/2.2.3 (CentOS)
    Last-Modified: Sun, 09 Feb 2014 08:39:51 GMT
    ETag: "41879c-59-2a9c23c0"
    Accept-Ranges: bytes
    Content-Length: 89
    Content-Type: text/html; charset=UTF-8
    Set-Cookie: test=1234;expires=Tue, 05-Aug-2014 07:41:03 GMT;path=/;
    
    // HTTP::cookie expires test 1300 relative
    
     config
    
    root@(B6900-R69-S40)(cfg-sync Standalone)(Active)(/Common)(tmos) list ltm rule qux
    ltm rule qux {
        when HTTP_RESPONSE {
      HTTP::cookie insert name test value 1234 path / version 0
      HTTP::cookie expires test 1300 relative
    }
    }
    
     test
    
    [root@client3 ~] date; curl -I http://100.100.100.41
    Tue Aug  5 15:42:29 SGT 2014
    HTTP/1.1 200 OK
    Date: Tue, 05 Aug 2014 07:30:13 GMT
    Server: Apache/2.2.3 (CentOS)
    Last-Modified: Sun, 09 Feb 2014 08:39:51 GMT
    ETag: "41879c-59-2a9c23c0"
    Accept-Ranges: bytes
    Content-Length: 89
    Content-Type: text/html; charset=UTF-8
    Set-Cookie: test=1234;expires=Tue, 05-Aug-2014 08:04:10 GMT;path=/;
    
  • Yesterday one of the boxes appeared to be adding almost 120 seconds to the total. There does not appear to be any pattern to it
  • I have now tried this on a physical device and this one is adding on 33 seconds, so my cookie comes back 20m33s into the future.

     

    Something is definitely not right - I will have to raise a case with F5 support on this.

     

  • I managed to make it so I could target the URL on port 80 so I could use wireshark on the laptop to see what the LTM was sending back.

     

    The capture clearly showed that the LTM WAS setting the cookie expiry time correctly but Firebug was displaying a completely (almost random +xx seconds) time!

     

    No idea why Firebug was not displaying the correct expiry time but it isn't the iRules that is causing the problem.

     

  • Thank you Chris for coming back and telling us how it was resolved. Its good to know what was the root cause of the problem.