Out-of-spec Encoding of request URLs

[refractions]

The WMS spec. requires that all strings be encoded according the the URL
encoding RFC, with a few exceptions. The exceptions are mostly standard CGI
characters, except for the ',' when used as a separator for list-based
parameters. mapwmslayer is broken in the following ways:

- Some values that should be encoded are not.  A number of parameters are
allowed to be passed without any URL escaping, despite the fact that only
particular characters in the parameters are given exemptions in the WMS spec. 
The handling of the SRS for example, does not escape the value (presumably to
preserve the literal ':' as required by the spec) but that means that any other
non-allowed character can slip through. I personally think the spec is absurd in
this case and the current behavior probably causes no functional problems.

- Some values that should not be encoded are.  For example, a layer list of FOO
and BAR is coming out as LAYERS=FOO%2CBAR instead of LAYERS=FOO,BAR.  This
actually is a problem, because making an encoded request to a server that
properly follows the spec will result in failure if you are requesting more than
one layer. (Because the server will first split on ',' which you have encoded
before going on to decode the actual layer values.) The spec is absurd in this
case too, *but* not following it demonstrably causes problems of
interoperability (try requesting two layers from a cubewerx server). Following
the spec will not cause breakage against servers that do not follow the spec
(because the literal ',' characters will not be harmed by a decoding process).

The relevant portion of the spec is page 11 of the 1.1.1 version. In particular:

"When the characters "?", "&", "=", "/", ":" and "," appear in one of the roles
defined in Table 1, they are to appear literally in the URL. When such 
characters appear elsewhere (for example, in the value of a parameter), they
are to be encoded as defined in [IETF RFC 2396]."

Note that in the 1.3 version of the spec, they have backed off of ":" and "/"
(thank god) because not encoding them is extremely bad on an RFC level and
provides no functional benefit at all.

[bartvde@…]

*** This bug has been marked as a duplicate of 1296 ***