flaws in encoding logic

[bartvde@…]

e-mails from Paul Ramsey:

As a followup to the discussion of encoding WMS URL parameters, the
logic in the mapwmslayer.c file seems to be backwards (and partially
missing).
 
The msSetWMSParamString function includes a boolean to optionally
encode the values passed (which is nice planning):
 
static int msSetWMSParamString(wmsParamsObj *psWMSParams,
                               const char *name, const char * value,
                               int urlencode)
 
But the calls to the function seem to use it backwards, encoding things
that shouldn't be encoded (LAYERS, BBOX, STYLES) and not encoding
others:
 
    msSetWMSParamString(psWMSParams, "LAYERS",  pszName, MS_TRUE);
    msSetWMSParamString(psWMSParams, "TRANSPARENT", "TRUE", MS_FALSE);
 
        snprintf(szBuf, 100, "%.15g,%.15g,%.15g,%.15g",
                 bbox.minx, bbox.miny, bbox.maxx, bbox.maxy);
        msSetWMSParamString(psWMSParams, "BBOX",    szBuf, MS_TRUE);
 
It doesn't look like the individual layers get encoded either. So the
upshot is that the Mapserver WMS client is probably generating
out-of-spec requests.

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.