iRule recognize blank space in URI?

another question if someone can help. Encoding all of URI is easy but turns all specical characters into encoded format and the server is not accepting the request. The cahllenge is that I need some way to ONLY find spaces and replace that with %20. Anyone with a good idea?

 

 

Thanks!

 

 

John

I think

 

 

regsub -all " " $newURI %20 encURI

 

 

will do it, if there is a better way, please let me know.

 

 

Thanks for all the help.

 

 

John

string map would probably be a lot faster.

Thanks, that worked. It is going to be pounded with probably 40.000 to 50,000 request per second so anything that can make it more efficient is great.

 

 

John

ok, I am back, strange problem.

 

 

Test request I am sending:

 

 

[root@bigip1:Active] config telnet 10.10.50.203 80 Trying 10.10.50.203...

 

Connected to 10.10.50.203.

 

Escape character is '^]'.

 

GET /vMoD/vMoDGenres?title=R and B HTTP/1.0 ^]

 

telnet> q

 

Connection closed.

 

 

Seeing in the ltm log:

 

 

Mar 24 15:13:31 tmm tmm[824]: Rule vmod_search : URI was matched. Result: /vMoD/vMoDGenres?title=R and B Mar 24 15:13:31 tmm tmm[824]: Rule vmod_search : It worked! /vMoD/vMoDGenres?title=R%20and%20B

 

 

 

But the tcpdump shows:

 

 

15:13:31.821046 10.10.50.202.38458 > 10.10.50.236.http: P [tcp sum ok] 1:58(57) ack 1 win 4380 (DF) (ttl 255, id 50573, len 109)

 

0x0000 4500 006d c58d 4000 ff06 3c33 0a0a 32ca E..m..@...<3..2.

 

0x0010 0a0a 32ec 963a 0050 8280 d372 c314 39d8 ..2..:.P...r..9.

 

0x0020 8018 111c 811f 0000 0101 080a 4e3a 2f0e ............N:/.

 

0x0030 5e35 f30e 4745 5420 2f76 4d6f 442f 764d ^5..GET./vMoD/vM

 

0x0040 6f44 4765 6e72 6573 3f74 6974 6c65 3d52 oDGenres?title=R

 

0x0050 2532 3061 6e64 2532 3042 2061 6e64 2042 %20and%20B.and.B

 

0x0060 2048 5454 502f 312e 300d 0a0d 0a .HTTP/1.0....

 

 

You can see that BIG-IP is putting "and B" and the end of the URI.

 

I just can't figure out where it is padding that. I changed the logging and it shows the same if I comment out the "encoding" section. I am wondering if it is being padded after the rule is executed.

 

 

any help would be appreciated.

Well it certainly looks as though the rule thinks things are being processed properly. I'd make sure that your last log statement saying "it worked!..." is actually capturing the HTTP::uri value, after it's set.

 

 

I'm also curious what your rule looks like at this point.

 

 

According to what I can see in the logs though, it looks like the rule is functioning properly.

 

 

-Colin

The rule is:

 

 

when CLIENT_ACCEPTED {

 

TCP::collect 60

 

}

 

when CLIENT_DATA {

 

set matchedURI [regexp -inline "/vMoD.+HTTP" [TCP::payload]]

 

log local0. "first match $matchedURI"

 

if { [string length $matchedURI] > 0 } {

 

set newURI [getfield [getfield $matchedURI " HTTP" 1] "\{" 2]

 

log local0. "URI was matched. Result: $newURI"

 

set uriRewrite 1

 

} else {

 

log local0. "no match"

 

set uriRewrite 0

 

}

 

}

 

when HTTP_REQUEST {

 

if {$uriRewrite == 1} {

 

log local0. "Encoding $newURI"

 

regsub -all " " $newURI %20 encURI

 

set encURI [string map { " " %20} $newURI]

 

HTTP::uri $encURI

 

log local0. "It worked! [HTTP::uri]"

 

 

}

 

}

 

 

 

Interesting thing is, if I send a request without space, or %20 already in it, then it does not pad extra characters, and it always seems to padd whatever is after the first space that gets replaced.

 

 

I suspect the problem is that you are trying to manipulate the HTTP::uri variable in the HTTP_REQUEST and you have already confirmed that an issue exists when there is a space in the URI and the HTTP parser gets a hold of it.

 

 

i.e.

 

You are modifying the HTTP::uri contents, but some misc crud (The end of a portion of the URI string is still hanging around and not being accounted for) is still in the buffer to send to the client.

 

 

My guess.

You need to rewrite the uri in CLIENT_DATA using TCP::payload replace. The HTTP parser will not recognize the spaces in the uri (the original problem) and so when you rewrite the uri, it only rewrites what it thinks is the uri (everything up to the first space). That is why you are left with the extra " and B".