HTTP::cookie exists v.s. [string length[HTTP::cookie NAME]] ?

ex is more or less returning a result of a comparison, not the actual value.

 

 

 

Try looking at the value

 

set ex2 [HTTP::cookie JSESSIONID]

 

 

CB

 

 

Yeah, I thought that myself.. but when JSESSIONID is null, [string length [HTTP::cookie JSESSIONID]] is still returning 1, which is what I'm having a hard time understanding.

 

 

If I fire up "tclsh", and try and run a string length against a variable with a null value, I should get 0.. right?

 

 

So here's a snippet of my logs from the test. First the code;

 

 

 

set ex [HTTP::cookie exists JSESSIONID]

 

set le [string length [HTTP::cookie JSESSIONID]

 

 

log local0. "DEBUG: ex: $ex le: $le"

 

log local0. "DEBUG: JSESSIONID: *******||*****"

 

 

And the output, if no JSESSIONID is set:

 

 

DEBUG: DEBUG: ex: 0 le: 1

 

DEBUG: JSESSIONID: *******||*****

 

 

 

So how is that possible? How can [string length[HTTP::cookie JSESSIONID]] return 1, when there is nothing in the cookie, and [HTTP::cookie JSESSIONID] returns false? If the "string length" command was evaluating [HTTP::cookie JSESSIONID] as a string, rather than interpreting it, I still shouldn't get 1.. I should get 25.. not 1.

 

 

I've worked around this oddity in my iRule already, so this is more of a curiosity at this point...

 

 

Er. Whoops. that 2nd log line should read:

 

 

log local0. "DEBUG: JSESSIONID: *******|[HTTP::cookie JSESSIONID]|*****"

 

 

It kinda seems obvious now that the variable is not updated when it's a null value. Perhaps an IF statement that resets the value when it detects that the JSESSION doesn't exist?

 

 

Thoughts?

 

 

CB

 

Well, as I mentioned I have a work around. I'm essentilly checking both;

 

 

if { ([HTTP::cookie exists JSESSIONID]) and ([string length[HTTP::cookie JSESSIONID]]) } {

 

persist uie add [HTTP::cookie JSESSIONID]

 

}

 

 

Without the "cookie exists" check, I was winding up with persistence records with blank keys! Yeech! (not sure how/why the system even allowed that to go into the table. I would assume it'd make a mess of things.. can persistence records collide I wonder?)

 

 

There is a setting the VIP where you can select a fallback persistence profile.

Right. You can set source_addr as the fallback. What I meant though, was that I would see universal persistece entries with no key. Again, not a big deal as I worked around it. It's just odd is all.

Hi jsmccombs,

Can you post the actual full rule you were testing and the version you were testing on? I tried the following on 9.3.1, 9.4.7, 10.0.0 and didn't see the issue you're describing:

 
    log local0. "path: [HTTP::path]" 
    log local0. "\[HTTP::header value Cookie\]: [HTTP::header value Cookie]" 
    log local0. "\[HTTP::cookie exists JSESSIONID\]: [HTTP::cookie exists JSESSIONID]" 
    log local0. "\[string length \[HTTP::cookie JSESSIONID\]\]: [string length [HTTP::cookie JSESSIONID]]" 
 } 
 

: path: /no_JSESSIONID_cookie

: [HTTP::header value Cookie]:

: [HTTP::cookie exists JSESSIONID]: 0

: [string length [HTTP::cookie JSESSIONID]]: 0

: path: /JSESSIONID_cookie_without_a_value

: [HTTP::header value Cookie]: JSESSIONID=

: [HTTP::cookie exists JSESSIONID]: 0

: [string length [HTTP::cookie JSESSIONID]]: 0

: path: /JSESSIONID_cookie_with_a_value

: [HTTP::header value Cookie]: JSESSIONID=test

: [HTTP::cookie exists JSESSIONID]: 1

: [string length [HTTP::cookie JSESSIONID]]: 4

It looks like in 10.0.0, the bug where [HTTP::cookie exists "cookie_name"] returns zero with a cookie with no value (JSESSIONID=) was fixed.

Aaron