iRule persitence on uri / payload

Question

I am trying to set persistence using an iRule based on uri.  The problem I think I might be having is related to the fact that the first uri that comes through does not contain the persistence string I want to use.  When the iRule executes my page fails each time.  this site does not use cookies&nbsp;
&nbsp;the url that contains my sessionid is as such - https://app.domain.com/AppName/con/...8346042343
&nbsp;where the 10.100.200.90.1308346042343 string is my sessionid&nbsp;
&nbsp;the iRule that I have in place (matches, but fails and kills my browser when used is&nbsp;
&nbsp;when CLIENT_ACCEPTED {
&nbsp;   set add_persist 1
&nbsp;}&nbsp;
&nbsp;when HTTP_REQUEST {
&nbsp;       set session_id [lindex [ split [HTTP::uri] "/" ] 3]
&nbsp;       log local0. "Parsed a webapp sessionid as $session_id"
&nbsp;       if { $session_id != "" } {
&nbsp;           persist uie $session_id
&nbsp;       }
&nbsp;   }&nbsp;&nbsp;&nbsp;
A little more investigation I find that if I log the session to ltm I see the following sequence before my browser crashes and fails.&nbsp;
&nbsp;Jun 17 21:47:35 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 
&nbsp;Jun 17 21:47:35 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 10.100.200.90.1308346445866
&nbsp;Jun 17 21:47:36 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 10.100.200.90.1308346445866
&nbsp;Jun 17 21:47:36 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 10.100.200.90.1308346445866
&nbsp;Jun 17 21:47:36 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 10.100.200.90.1308346445866&nbsp;

&nbsp;Interesting to note is that the first URI match is blank as it come from a dfferent pattern &nbsp;https://app.domain.com/AppName/com?...tion=relay
&nbsp;and contains the session id in the body of the page itself&nbsp;

Jun 1HTTP/1.1 200 OK
&nbsp;Date: Fri, 17 Jun 2011 21:47:24 GMT
&nbsp;Server: Apache-Coyote/1.1
&nbsp;RS-ID: FD4970736D89CFBECC8C54DD3F398DC3
&nbsp;Content-Type: text/plain
&nbsp;SafeWord-SSL: yes
&nbsp;Transfer-Encoding: chunked
&nbsp;

8d
&nbsp;Relay Parameter
&nbsp;Fri Jun 17 15:34:06 MDT 2011
&nbsp;maxpollinterval=6000
&nbsp;sessionid=10.100.200.90.1308346445866
&nbsp;pollincreasefactor=4
&nbsp;protocol=http
&nbsp;

0
&nbsp;
but does not contain the sessionid as being pull using the lindex split.  Perhaps I need to throw that URL out somehow before capturing the string in the iRule, but how if so correct?&nbsp;
&nbsp;Any help is greatly appreciated&nbsp;&nbsp;&nbsp;&nbsp;

&nbsp;
&nbsp;

&nbsp; &nbsp;

hamish · Answer

&nbsp; As a quick response (Sorry, need to digest your question and think about it a bit)... 
&nbsp;  
&nbsp; Just because the site doesn't use cookies doesn't mean you can't use session cookies yourself for session persistence... The Session cookies are INSERTED into the response. And the backend isn't actually involved in them at all. 
&nbsp;  
&nbsp; Let me think about the rest just in case you really really don't want to, or can't use (Not a browser?) active cookies for persistence.  
&nbsp; H

hamish · Answer

OK... 
&nbsp;  
&nbsp; I'm not sure why your browser crashes and fails... What your doing doesn't seem (To me) to be bad... The first request doesn't get persisted... The second does... But it's apparently not a problem with persistence that causing your browser failure, because I'd expect that to exhibit as an unknown session for the second access (If the client was balanced to the wrong poolmember for example). 
&nbsp;  
&nbsp; Myself, I usually always tend to use active cookies for persistence... I haven't yet seen an instance (For a browser) where it isn't possible to use a cookie... For other protocols, I've used various things. e.g. LDAP... 
&nbsp;  
&nbsp; For the life of me I can't see why anything the iRUle does would crash your browser... If the browser crashes because of bad input, then it's a problem with the browser... That;s a bug in the browser pure &amp; simple... (And usually indicative of a security vulerability... At the least a DOS vuln... If it can be exploited, then it's even worse). 
&nbsp;  
&nbsp; What browser is it? If IE&lt; does using firefox make a difference? What about chrome or Safari? 
&nbsp;  
&nbsp;  
&nbsp; H &nbsp;

mattkirkevold_6 · Answer

Hamish, 
 Thanks for the replies, greatly appreciated. 
 I think part of this is related to the browser starting a java applet (more info to me) and that session is what needs to persist.  This would crash out either FF or IE.  I did a birt more research and was also pointed to the following that did the trick. 
  
 http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/160/iRules-persist-v-persist-add.aspx 
  
 By setting the pesist add is the RESPONSE section I was able to then use the general persist in the REQUEST.  Because the REQUEST and RESPONSE have difference in representing the sessionid I used 2 different mthods to retrieve the sessionid.  This tested out and worked.

when CLIENT_ACCEPTED {
   set add_persist 1
}

when RULE_INIT {
  set ::debug 0
}

when HTTP_REQUEST {
set cli [IP::remote_addr]:[TCP::remote_port]
set session_id [lindex [ split [HTTP::uri] "/" ] 3]
if {$::debug}{log local0. "Client: $cli  Request session_id: &gt;$session_id&lt;"}
  if {$session_id != "" } {
      persist uie $session_id
  }
}

when LB_SELECTED {
if {$::debug}{log local0. "Client: $cli  LB to:  [LB::server addr]"}
}
  when HTTP_RESPONSE {
HTTP::collect 1
set parse [ findstr [HTTP::payload] sessionid= 10 ]
set session_id [split [lindex [split $parse] 0] " "]
if {$::debug}{log local0. "Client: $cli  Request session_id: &gt;$session_id&lt;"}
  if { $session_id != "" and $add_persist == 1 } {
      persist add uie $session_id
  }
}

-Matt

hoolio · Answer

If you have users connecting from behind the same proxy, you might get more than one session per TCP connection.  If that's the case, then you'd probably want to check each response for a new session ID versus doing this just once per connection. 
&nbsp;  
&nbsp; Also, if you're on a CMP capable platform and OS version, you should replace the global debug variable with a local one set in CLIENT_ACCEPTED to avoid CMP being disabled: 
&nbsp;  
&nbsp; http://devcentral.f5.com/wiki/default.aspx/iRules/CMPCompatibility.html 
&nbsp;  
&nbsp; Aaron

Forum Discussion

SSO Login Update Coming to DevCentral

Kevin - June 2026 Featured F5er

Tyler - May 2026 Featured Member

Recent Discussions

Hardware BIG-IP appliance reach EOSS, but the software version running on it not yet?

VPN Communication Error with F5 BIG-IP Edge Client

simultaneous disabling / enabling of all LTM objects

Query on source IP preservation for syslog traffic through F5 virtual server

qkview: revealing pool members & pools

Related Content

Rethinking Payload Parsing: Native JSON Handling in iRules

Persitence via Xfor

AppWorld Berlin iRules Contest!

HTTP Payload Collection

Help with tcp/http payload irule

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS