URI decoding H-E-DOUBLE-HOCKEY-STICKS

Yes, I know. As you can see in the iRule provided above, I do use [string tolower ...]. However, this doesn't help in the case of URI::compare where the strings must be decoded (internally) before they can be made lower-case for the purposes of comparison.

In thinking about the problem more, it seems it would be very nice if URI::compare not only a "-nocase" option, but also had an option to specify the comparison operator like matchclass (i.e. starts_with, equals, ...).

An additional idea comes to mind as well. Knowing that the starts_with operator is probably used most often to compare directory names in the HTTP URI, it would be nice if there was a starts_with_dir operator that eliminated the need for my two "if" conditions above.

Instead of this:

  if { $uri starts_with "/foo/" || $uri equals "/foo" } {

It would be just this instead:

  if { $uri starts_with_dir "/foo" } {

It seems that if URI::compare could be extended a bit, my iRule could be greatly simplified and robust URI comparisons could be made very easily. It seems like this would be a good area to enhance iRules since they are used for parsing the HTTP URI so much. As I read a lot of the forum posts here, I'm surprised to see how few people take into account URI encoding...I wonder how many administrators are parsing request URI's in a way that can be defeated with simple URI encoding (and I wonder for how many this exposes data they didn't intend to expose...).

Lastly, it seems the iRules wiki example for URI::compare maybe isn't right?

http://devcentral.f5.com/wiki/default.aspx/iRules/URI__compare.html

It shows a comparison between "http://www.foo.com/somepath" and [HTTP::uri] (which would only contain the "/somepath" part of the request). If URI::compare really does use RFC2616 section 3.2.3 for comparison, it seems this should fail.