WFS: posting doesn't always work

[fsteggink]

Hi,

I'm developing a WFS client, which I tested with multiple servers. I discovered that there were some problems with using HTTP POST to MapServer. (The default HTTP method of my client is GET, which works fine.) I've started a discussion on the MapServer users list. More information can be found there. I haven't installed MapServer myself, but was using public WFS servers on the internet.

Here are the results of one particular server (quoted from my mail): [quote] Well, it turned out that it depends on the presence of carriage returns in the post data if it will succeed or not. (The service URL is ​http://map.ns.ec.gc.ca/MapServer/mapserv.exe?map=/mapserver/services/envdat/config.map and the version is 4.8.3.)

Posting this will succeed (all on one line):

<?xml version="1.0" encoding="iso-8859-1"?><wfs:DescribeFeatureType version="1.0.0" service="WFS" xsi:schemaLocation="http://www.opengis.net/wfs ../wfs/1.0.0/WFS-basic.xsd" xmlns:wfs="http://www.opengis.net/wfs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><wfs:TypeName>wfs:envirodat</wfs:TypeName></wfs:DescribeFeatureType>

Posting this will not:

<?xml version="1.0" encoding="iso-8859-1"?> <wfs:DescribeFeatureType version="1.0.0" service="WFS"
xsi:schemaLocation="http://www.opengis.net/wfs
../wfs/1.0.0/WFS-basic.xsd" xmlns:wfs="http://www.opengis.net/wfs"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <wfs:TypeName>wfs:envirodat</wfs:TypeName>
</wfs:DescribeFeatureType>

The post data is not URL encoded. And posting the successful post body to ​http://map.ns.ec.gc.ca/envdat/map.aspx gives the infamous "no template provided" error. quote This says two things.

1. There is a problem with the online resource URL's. (This is the last URL mentioned, and the online resource URL's are the URL's which are supposed to be used, instead of the base URL which is used for the initial GetCapabilities request only.) I found that multiple servers had this problem.

2. It apparently matters if there are carriage returns and/or line feeds in the XML data. Very strange. (If they are present, the service times out, and finally returns a 502 error after five minutes.)

The other services I have tested are:

• ​http://www.bsc-eoc.org/cgi-bin/bsc_ows.asp (MapServer 4.8.1);
• ​http://wfs.alaskamapped.org/inventory (MapServer 5.0 RC 2);
• ​http://excise.pyr.ec.gc.ca/cgi-bin/mapserv.exe?map=/LocalApps/Mapsurfer/PYRWQMP.map (MapServer 4.8.1);
• ​http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap (MapServer 4.6.0).

Only the last service worked correctly with post data.

Since I don't have any MapServer experience (apart from testing my client against the WFS service), it is very hard to tell what the problem(s) is/are. Some people suggest that it could be a configuration / wrapper issue, but as I showed, there is also an issue with handling the data itself (the linebreaks). As I said, more information can be found in the e-mail thread, but this ticket contains the latest and most succint information.

[dmorissette]

There are multiple issues in this ticket:

1- The carriage return issue was fixed in MapServer 4.8.4 and 4.10.0 (ticket #1768)

2- You listed ​http://wfs.alaskamapped.org/inventory as having the carriage return problem, but it runs MapServer 5.0RC2 in which this should be fixed. Can you please double check that the error this server produces is indeed related to the carriage returns and not to something else?

3- You mention a "problem with onlineresource URLs". I'm not sure to follow you on this one. Can you please be more specific?

4- The ​http://map.ns.ec.gc.ca/envdat/map.aspx issue is a server configuration issue outside of MapServer's control since map.aspx doesn't support proper forwarding of POST request data. However, this server was very likely configured following the advice from section 2.4 of the WMS Server HOWTO at ​http://mapserver.gis.umn.edu/docs/howto/wms_server/#more-about-the-online-resource-url so this should be considered a documentation issue. I have added a comment about this at the bottom of this document. Hopefully they'll pick this up when the doc is updated.