<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>RE: [UMN_MAPSERVER-DEV] should Mapserver WMS client URL encode?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Paul -<BR>
<BR>
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.<BR>
<BR>
All commas are equal, but some commas are more equal than others!<BR>
<BR>
- Ed<BR>
<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Paul Ramsey [<A HREF="mailto:pramsey@refractions.net">mailto:pramsey@refractions.net</A>]<BR>
Sent: Fri 3/25/2005 3:10 PM<BR>
To: Ed McNierney<BR>
Cc: MAPSERVER-DEV@LISTS.UMN.EDU<BR>
Subject: Re: [UMN_MAPSERVER-DEV] should Mapserver WMS client URL encode?<BR>
<BR>
<BR>
Ed, Bart,<BR>
<BR>
I think the specification is clear enough: there is a difference<BR>
between a "," and %2C. This is particularly important for LAYERS, for<BR>
example:<BR>
<BR>
LAYERS=Roads%2C%20Rough,Roads%2C%20Paved<BR>
<BR>
If you decoded the LAYERS value *before* splitting on the "," you would<BR>
end up with four layers. If you did it after, you would end up with<BR>
two, as is intended.<BR>
<BR>
The same twisted logic I assume applies to the BBOX parameter because<BR>
of the European use of "," as the decimal place in floating point<BR>
numbers.<BR>
<BR>
So, basically, the behavior described in the specification is not<BR>
optional on either the client *or* the server side. If you treat it is<BR>
if it were, you will occasionally (but not very often) get degenerate<BR>
results in your WMS client/server interactions.<BR>
<BR>
BTW, Ed, you have read the paragraph you quoted exactly backwards: the<BR>
section requires that the special characters *not* be encoded when used<BR>
within the roles given in the table following. The roles for the ?,+,&<BR>
and = are standard CGI roles, so are sort of (really) redundant to be<BR>
in the WMS spec. The role for "," though, is quite particular to the<BR>
WMS spec (From the Table 1): Separator between individual values in<BR>
list-oriented parameters (such as BBOX, LAYERS and STYLES in the GetMap<BR>
request).<BR>
<BR>
So, to reiterate, you should never see a parameter that looks like this:<BR>
<BR>
BBOX=-180%2C-90%2C180%2C90%2C<BR>
<BR>
Because the specification says that in the role of separator for BBOX<BR>
(and LAYERS and STYLES) parameters the "," is to be left unencoded (and<BR>
damn the RFC!)<BR>
<BR>
BBOX=-180,-90,180,90<BR>
<BR>
On the server side, this little quirk of the spec requires some extra<BR>
steps in processing the magic parameters. For LAYER, BBOX and STYLES,<BR>
first split on comma, then decode the individual elements, then<BR>
continue processing. For any parameter *except* LAYER, BBOX and<BR>
STYLES, ordinary CGI handling is sufficient. This of course will break<BR>
any client that currently uses naive URL encoding on *all* value<BR>
parameters. Support for broken (out of spec) clients requires an extra<BR>
two-step to first check if there are any literal commas in the value<BR>
parameter.<BR>
<BR>
Paul<BR>
<BR>
On 25-Mar-05, at 8:54 AM, Ed McNierney wrote:<BR>
<BR>
> I don't recall the previous discussion, but it would seem strange for a<BR>
> WMS server to NOT handle HTTP querystrings that were URL-encoded. The<BR>
> specification doesn't QUITE come out and say that servers shall accept<BR>
> all valid encoded querystrings, but it does say (Section 6.2.1, WMS<BR>
> 1.1.1 spec):<BR>
><BR>
> When the characters "?", "&", "=", "/", ":" and "," appear in one of<BR>
> the<BR>
> roles defined in Table 1, they are to appear literally in the URL. When<BR>
> such characters appear elsewhere (for example, in the value of a<BR>
> parameter), they are to be encoded as defined in [IETF RFC 2396].<BR>
><BR>
> This section requires the client to encode at least these special<BR>
> characters. It doesn't say that the SERVER shall accept them, but I<BR>
> would expect that to be the intended result <g>. And if you're going<BR>
> to<BR>
> accept THOSE characters in RFC-2396 encodings, then it's reasonable to<BR>
> expect that ALL valid RFC-2396 encodings should be accepted.<BR>
><BR>
> The problem in the spec (as far as URL querystrings go) is that the<BR>
> focus is on the rules clients must follow in constructing URL<BR>
> querystrings, while there is nothing said about what rules servers must<BR>
> follow. I would say there's a strong implication throughout Section<BR>
> 6.2<BR>
> that any valid URL querystring should be supported by a WMS server.<BR>
><BR>
> - Ed<BR>
><BR>
> Ed McNierney<BR>
> President and Chief Mapmaker<BR>
> TopoZone.com / Maps a la carte, Inc.<BR>
> 73 Princeton Street, Suite 305<BR>
> North Chelmsford, MA 01863<BR>
> ed@topozone.com<BR>
> (978) 251-4242<BR>
><BR>
> -----Original Message-----<BR>
> From: UMN MapServer Developers List<BR>
> [<A HREF="mailto:MAPSERVER-DEV@LISTS.UMN.EDU">mailto:MAPSERVER-DEV@LISTS.UMN.EDU</A>]<BR>
> On Behalf Of Bart van den Eijnden<BR>
> Sent: Friday, March 25, 2005 10:50 AM<BR>
> To: MAPSERVER-DEV@LISTS.UMN.EDU<BR>
> Subject: [UMN_MAPSERVER-DEV] should Mapserver WMS client URL encode?<BR>
><BR>
> Hi list,<BR>
><BR>
> I remember a discussion initiated by me about a year ago about whether<BR>
> or not Mapserver CGI should react correctly to URL encoded requests.<BR>
> The<BR>
> answer was, if I remember correctly, that it does not have to do that.<BR>
><BR>
> Together with Nuno, I have been looking into a problem letting<BR>
> Mapserver<BR>
> WMS client talk with the ERMapper WMS.<BR>
><BR>
> ERMapper WMS does not like URL encoded parameters, but Mapserver WMS<BR>
> client does encode a few, like layers and bbox.<BR>
><BR>
> I would assume that given the outcome of the previous discussion,<BR>
> Mapserver WMS client is wrong in encoding the parameters.<BR>
><BR>
> Is this a right assumption?<BR>
><BR>
> Best regards,<BR>
> Bart<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>