WFS DescribeSchema fails on landvic service

[jng]

When a WFS feature source is set up in MapGuide to this service:

​https://services.land.vic.gov.au/catalogue/publicproxy/guest/dv_geoserver/datavic/wfs

Attempting to describe a schema fails. In the MG error log, it shows this error reported by the provider:

The requested URL returned error: '414 Request-URI Too Long'

[jng]

Also happening for their WMS service as well:

​https://services.land.vic.gov.au/catalogue/publicproxy/guest/dv_geoserver/datavic/ows

[jng]

Found the problem.

The cause is that the initial DescribeFeatureType response on the WFS service is *huge*.

There are 652 (!!!) WFS layers and the provider is doing a subsequent request stitching together all 652 layer names to a GET request, clearly exceeding whatever natural limits for a URL.

In such a case, the FdoWfsDescribeFeatureType http handler should be smarter and pivot to using a POST request if it is clear that stitching the GET request would produce a URL that exceeds 2000 characters.

Similar logic should apply for the WMS equivalent operation as well.

[jng]

Or an architectural-level fix is for these providers to implement the FDO RFC23 interfaces (GetSchemaNames, GetClassNames, DescribeSchema with hints)

[jng]

Further testing reveals the actual cause. It is not the 414 error from constructing a giant URL. Because when this happens, it does a fallback attempt where it doesn't try to append this giant list of layer names.

The actual problem is that the DescribeFeatureType response contains 2 layer names that are being treated as the same feature class name:

• WATER_IRRIGATION_SYSTEM_ALLOCATION
• WATER_IRRIGATION_SYSTEM_ALLOCATION_

Digging further shows that Xerces is reading these attributes wrong. The one with the trailing underscore is being read with the trailing underscore stripped out, resulting in an erroneous class name collison by the FDO XML SAX handler.

Attached is a minimal XML document that cannot be read into a FdoFeatureSchemaCollection

[jng]

Minimal failing DescribeFeatureType response

[jng]

One final note: The http 414 error is thrown because the fallback method of reading the XML failed due to to erroneous FDO class name collision. When the fallback method also fails, the original error (the http 414 error) is thrown back.

[jng]

The test case for the attached XML is:

1. Make a FdoFeatureSchemaCollection
2. Call ReadXml passing in a stream to the example file

Expect: A schema collection with 1 schema that has 2 classes. Get: An empty schema collection

[ajinopenspatial]

Hi Jacki,

After debugging the code I found out the real reason of the issue is from truncating the "Type" or "_Type" from the end of name property of the xml node "xsd:complexType" to get the layer's class name. If you check the test.xml file attached on the ticket you could find the 2 names are: WATER_IRRIGATION_SYSTEM_ALLOCATION_Type and WATER_IRRIGATION_SYSTEM_ALLOCATIONType. After truncating the "Type" or "_Type" at the end you will get the same class name "WATER_IRRIGATION_SYSTEM_ALLOCATION" which caused the 2nd exception while inserting it twice into a dictionary. After detailed search I found out that the truncate logic is defined in a .h file named "SchemaFromExternal.h" sitting under folder "workspace\fdo-trunk-dbg\Fdo\Unmanaged\Src\Fdo\Schema"(there is another file named "SchemaFromExternal.xslt" whose content is similar to the head file. but changing it or not will not affect the build). If we remove the lines whose line number is from 4090 to 4093 and rebuild the solution then you could run the unit test successfully to access the url "​https://services.land.vic.gov.au/catalogue/publicproxy/guest/dv_geoserver/datavic/wfs?request=DescribeFeatureType"

My question here is: is there a possibility that the published WFS layer's complexType name appended with _Type(such as the table name is A then its complexType name is A_Type)? From our side and the url in this ticket all names are appended with "Type" only after their table names. If appending "_Type" will never happen in the real word then removing the lines from the head file would be safe. Otherwise you may have to design a mechanism to know which was appended.

[jng]

Regarding your question, we can answer that with extra unit tests. If we can make a feature schema with the following classes:

• Foo
• Foo_

And dump to xml and load that xml into a new one and get the same set of classes, that's a good enough proof for me that FDO will only ever append Type and not _Type to every class name and we should be able to safely drop the _Type XSL transformation rule.

I'll be adding these tests shortly along with a full landvic WFS/WMS test. If everything passes with the dropping of the _Type XSL transformation rule, then I'll consider that as the fix.

[jng]

Fixed r8182