should Mapserver WMS client URL encode?

[Paul Ramsey]

Ed, Bart,

I think the specification is clear enough: there is a difference
between a "," and %2C.  This is particularly important for LAYERS, for
example:

LAYERS=Roads%2C%20Rough,Roads%2C%20Paved

If you decoded the LAYERS value *before* splitting on the "," you would
end up with four layers. If you did it after, you would end up with
two, as is intended.

The same twisted logic I assume applies to the BBOX parameter because
of the European use of "," as the decimal place in floating point
numbers.

So, basically, the behavior described in the specification is not
optional on either the client *or* the server side.  If you treat it is
if it were, you will occasionally (but not very often) get degenerate
results in your WMS client/server interactions.

BTW, Ed, you have read the paragraph you quoted exactly backwards: the
section requires that the special characters *not* be encoded when used
within the roles given in the table following.  The roles for the ?,+,&
and = are standard CGI roles, so are sort of (really) redundant to be
in the WMS spec. The role for "," though, is quite particular to the
WMS spec (From the Table 1): Separator between individual values in
list-oriented parameters (such as BBOX, LAYERS and STYLES in the GetMap
request).

So, to reiterate, you should never see a parameter that looks like this:

   BBOX=-180%2C-90%2C180%2C90%2C

Because the specification says that in the role of separator for BBOX
(and LAYERS and STYLES) parameters the "," is to be left unencoded (and
damn the RFC!)

   BBOX=-180,-90,180,90

On the server side, this little quirk of the spec requires some extra
steps in processing the magic parameters.  For LAYER, BBOX and STYLES,
first split on comma, then decode the individual elements, then
continue processing.  For any parameter *except* LAYER, BBOX and
STYLES, ordinary CGI handling is sufficient.  This of course will break
any client that currently uses naive URL encoding on *all* value
parameters.  Support for broken (out of spec) clients requires an extra
two-step to first check if there are any literal commas in the value
parameter.

Paul

On 25-Mar-05, at 8:54 AM, Ed McNierney wrote:

> I don't recall the previous discussion, but it would seem strange for a
> WMS server to NOT handle HTTP querystrings that were URL-encoded.  The
> specification doesn't QUITE come out and say that servers shall accept
> all valid encoded querystrings, but it does say (Section 6.2.1, WMS
> 1.1.1 spec):
>
> 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].
>
> This section requires the client to encode at least these special
> characters.  It doesn't say that the SERVER shall accept them, but I
> would expect that to be the intended result <g>.  And if you're going
> to
> accept THOSE characters in RFC-2396 encodings, then it's reasonable to
> expect that ALL valid RFC-2396 encodings should be accepted.
>
> The problem in the spec (as far as URL querystrings go) is that the
> focus is on the rules clients must follow in constructing URL
> querystrings, while there is nothing said about what rules servers must
> follow.  I would say there's a strong implication throughout Section
> 6.2
> that any valid URL querystring should be supported by a WMS server.
>
>         - Ed
>
> Ed McNierney
> President and Chief Mapmaker
> TopoZone.com / Maps a la carte, Inc.
> 73 Princeton Street, Suite 305
> North Chelmsford, MA  01863
> ed at topozone.com
> (978) 251-4242
>
> -----Original Message-----
> From: UMN MapServer Developers List
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU]
> On Behalf Of Bart van den Eijnden
> Sent: Friday, March 25, 2005 10:50 AM
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: [UMN_MAPSERVER-DEV] should Mapserver WMS client URL encode?
>
> Hi list,
>
> I remember a discussion initiated by me about a year ago about whether
> or not Mapserver CGI should react correctly to URL encoded requests.
> The
> answer was, if I remember correctly, that it does not have to do that.
>
> Together with Nuno, I have been looking into a problem letting
> Mapserver
> WMS client talk with the ERMapper WMS.
>
> ERMapper WMS does not like URL encoded parameters, but Mapserver WMS
> client does encode a few, like layers and bbox.
>
> I would assume that given the outcome of the previous discussion,
> Mapserver WMS client is wrong in encoding the parameters.
>
> Is this a right assumption?
>
> Best regards,
> Bart