Mapserver does not URL decode HTTP GET requests

[bartvde@…]

When Mapserver receives a request over HTTP GET which is URL encoded, it does 
not respond properly.

E.g.:

http://www.vz.geodan.nl:1112/cgi-bin/mapserv.exe?
map=/ms4w_20/apps/general/map/gemeentes.map&SERVICE=WFS&VERSION=1.0.0&am
p;REQUEST=DescribeFeatureType&TYPENAME=Gemeentes

gives back:
mapserv(): Web application error. No template provided.

Whereas 
http://www.vz.geodan.nl:1112/cgi-bin/mapserv.exe?
map=/ms4w_20/apps/general/map/gemeentes.map&SERVICE=WFS&VERSION=1.0.0&REQUEST=De
scribeFeatureType&TYPENAME=Gemeentes

gives back the correct result.

This bug is the cause that the Mapserver GML does not validate in XMLSpy.

BTW: this applies to both WMS and WFS server (and probably WCS as well).

[dmorissette]

It is the responsibility of the HTTP client to decode the URL before calling the
server. The first URL that you quoted is not a proper way to call a CGI program.
This is not a problem only with MapServer, it's the way things work everywhere.

I'll mark as invalid, please reopen with a more specific example if there is a
place where MapServer fails to decode a URL before calling a remote server.

[dmorissette]

For the record, after a long thread of discussions, here is the conclusion:



-------- Original Message --------
Subject: [Mapserver-users] Why Mapserver GML does not validate with XMLSpy (last
one)
Date: Thu, 17 Jun 2004 23:10:38 +0200
From: Bart van den Eijnden <bartvde@xs4all.nl>
Reply-To: bartvde@xs4all.nl
To: mapserver-users@lists.gis.umn.edu <mapserver-users@lists.gis.umn.edu>
CC: Richard Duivenvoorde <richard.duivenvoorde@geodan.nl>
References: <200406172059.i5HKx273058938@chilled.skew.org>

Hi Daniel, Steve (cc list),

you guys were right (how could I have doubted .... :) ).

I asked the guy (Mike Brown) who's e-mail message was quoted in the post 
by the Altova support engineer. I have forwarded his message below. He 
states it is a bug in XMLSpy.

I hope this will get addressed in XMLSpy and I will contact them as well.

Thanks for your patience.

Best regards,
Bart

------- Forwarded message -------
From: Mike Brown <mike@skew.org>
To: bart.van.den.eijnden@geodan.nl
Subject: Re: question about CGI
Date: Thu, 17 Jun 2004 14:59:02 -0600 (MDT)

> Bart van den Eijnden wrote:
>> Hi Mike,
>>
>> somebody at Altova (from the XMLSpy product) is referring to an e-mail
>>  from you in a forum discussion. He states that you can use &amp; in the
>> URL to a CGI program to separate name value pairs. The people who 
>> created
>> the CGI are saying XMLSpy should decode &amp; to & before sending the
>> request to the CGI.
>>
>> Maybe you can shed some light on this?
>>
>> See:
>>
http://www.altova.com/forum/forums/forum.asp?forumid=28&page=1&select=4262#xx4262xx
>>
http://www.altova.com/forum/forums/forum.asp?forumid=28&page=1&select=4266#xx4266xx
>>
>> Thanks in advance.
>>
>> Best regards,
>> Bart
>
>
> I had to backtrack through the forum postings a bit to figure out where 
> XMLSpy was
> getting the URI in question and why it was trying to access it.
>
> It is clearly a bug in XMLSpy (or whatever they are relying on to 
> extract URIs
> from the whitespace-separated list of URIs in the xsi:schemaLocation 
> attribute).
>
> This is the URI (1):
>
>  
http://www.vz.geodan.nl:1112/cgi-bin/mapserv.exe?map=/ms4w_20/apps/general/map/gemeentes.map&SERVICE=WFS&VERSION=1.0.0&REQUEST=DescribeFeatureType&TYPENAME=Gemeentes
>
> You have written it in your attribute value in the manner required by 
> XML (2):
>
>  
http://www.vz.geodan.nl:1112/cgi-bin/mapserv.exe?map=/ms4w_20/apps/general/map/gemeentes.map&amp;SERVICE=WFS&amp;VERSION=1.0.0&amp;REQUEST=DescribeFeatureType&amp;TYPENAME=Gemeentes"
>
> Whatever conformant XML parser reads (1) in the XML document should not 
> even
> expose it as anything other than (2) to whatever is doing the 
> dereferencing.
> So if XMLSpy is asking your server for anything other than
>
>  
/cgi-bin/mapserv.exe?map=/ms4w_20/apps/general/map/gemeentes.map&SERVICE=WFS&VERSION=1.0.0&REQUEST=DescribeFeatureType&TYPENAME=Gemeentes
>
> then it is just wrong. The argument shouldn't even get as far as what 
> the CGI
> spec does and does not allow.
>
> That said, &amp; in a query part is allowable from the HTTP and URI 
> spec's
> point of view, but when parsed by a CGI engine, the 'amp;' is going to be
> considered part of the name in a name-value pair, and this is how it 
> will be
> exposed in the environment to your CGI application.
>
> -Mike
>
>