Decode Querystring before ASM inspection

As per rfc2396, the "=" character is reserved and should not be encoded when used as a delimiter between a parameter and it's value.

From RFC 2396 sec 2.4.2:

A URI is always in an "escaped" form, since escaping or unescaping acompleted URI might change its semantics. Normally, the only timeescape encodings can safely be made is when the URI is being createdfrom its component parts; each component may have its own set ofcharacters that are reserved, so only the mechanism responsible forgenerating or interpreting that component can determine whether or not escaping a character will change its semantics. Likewise, a URImust be separated into its components before the escaped characterswithin those components can be safely decoded.

So basically what this means is that when a user agent or http server sees a URL, the very first thing it needs to do is split the URL in to its parts. After all of the parts are separated out, then the URL decoding/encoding can take place. So when we're breaking up the URL in to its components, we're looking for the '?', '&' and '=' characters as delimiters of the query string, query parameter and query value, respectively. Once the delimiters are gone then only the parameter names and values remain which are subject to URL encoding/decoding. If we are encoding then there could possibly be some left over '=' characters, which will likely be thrown in as part of a parameter value named closest to the left of the extra '=' character. If we are decoding then any %3d becomes part of a parameter name or value. For example:

/foo/?bar&baz=bl=eh path: /foo/ query string: bar&baz=bl=eh parameters: bar, baz parameter values: bar: (none) baz: bl=eh

and if we change to /foo/?bar&baz=bl%3deh we get the same exact results because we can decode after we separate the URL in to its components:

parameter values: bar: (none) baz: bl%39eh => (decode) => bl=eh