Forum Discussion
NimbostratusQuestion on HTTP Persistence and iRules
My colleague and I seem to disagree on what happens with iRule processing on an HTTP Persistent connection. He thinks that if you have a rule that inspects a URI or SOAPAction header, that you can't perform any actions on that persistent connection if the iRule conditions were not met on the initial connection.
For example, if there is an iRule that routes to Pool A for default requests but a URI is matched for the subsequent request that should go to Pool B, over a persistent connection, that request will end up going to Pool A. This implies then that subsequent requests over that persistent connection would also end up going to Pool A and that initial requests that go to Pool B would persist to pool B even if they didn't match the conditions in the iRule.
Which is the case?
mahnscJust to clarify my last sentence there, he's saying that if the conditions were not matched during the initial connection, they won't be matched on a subsequent persistent connection even if there is a match. I disagree with this because all these switch -glob examples out there that route specific URIs to specific pools wouldn't work regardless of where the connection occurred in an HTTP persistent connection setting.
- Kevin_Stewart
Employee
You are correct. There'd be no point in trying to use URI-based pool selection if it wasn't able to select different pools on subsequent requests. A common example:
when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "/images/*" { pool images_pool } default { pool app_pool } } }You may, however, need to enable OneConnect on the VIP to allow the server side connections to bounce between different servers. And if you were using the built-in cookie persistence, you'd actually get two different persistence cookies for the two pools in the example.
