should Mapserver WMS client URL encode?

[Ed McNierney]

Paul -

Thanks for the help!  Actually, I didn't read the spec backwards.  I just didn't realize that the original question was about commas in layer names!  My comments about the spec aren't incorrect (I don't think) but I did definitely omit the references to the special characters that are not to be escaped.  As you say, deciding that "%2C" and "," have two fundamentally different meanings is bizarre and more than a little error-prone.

All commas are equal, but some commas are more equal than others!

     - Ed




-----Original Message-----
From: Paul Ramsey [mailto:pramsey at refractions.net]
Sent: Fri 3/25/2005 3:10 PM
To: Ed McNierney
Cc: MAPSERVER-DEV at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-DEV] should Mapserver WMS client URL encode?
 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20050325/3cf60b87/attachment.html