[gdal-dev] Problems when mixing https calls

[Even Rouault]

Selon Ari Jolma <ari.jolma at gmail.com>:

> Even,
>
> Another strange thing with GDAL WFS driver. Earlier it did not try to
> access the HEAD of a XXX.resolved.gml and now it does:
>
> Here's an excerpt from my server logs. These calls are created by GDAL,
> the first is a good GetFeature call, which gets 215633 bytes of GML and
> the next is bogus. I can see this made up in ogrgmldatasource.cpp but do
> not understand why. In February this did not happen and GDAL parsed the
> GML the WFS provided fine (it actually created by GDAL too).
>
> 213.157.86.72 - ajolma [21/May/2013:00:02:56 +0300] "GET
>
/OILRISK-protected/wfs.pl?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=OILRISK.vtest.geom
> HTTP/1.1" 200 215633
> 213.157.86.72 - ajolma [21/May/2013:00:02:58 +0300] "HEAD
>
/OILRISK-protected/wfs.pl?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=OILRISK.vtest.resolved.gml
> HTTP/1.1" 200 -
>
> Do you have an idea what's going on here?

Ari,

I don't remind a recent change that might have affected this (but my memory can
be fragile), but reviewing the GML driver code, the fact that .resolved.gml is
probed means that the GML driver doesn't recognize the first bytes of the
GetFeature response to be a GML WFS document. Could you paste them ? My
hypothesis would be that the FeatureCollection root element is in a XML
namespace different from none, gml or wfs.

Does the probing of .resolved.gml, apart from slowing down the process, prevent
the driver to parse the GetFeature document ? I think it should not, but there
might be subtle issues since it will probably not use the schema obtained with
DescribeFeatureType to return the GML layer.

Even