[gdal-dev] Problems when mixing https calls

Even Rouault even.rouault at mines-paris.org
Tue May 21 01:38:09 PDT 2013


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

> On 05/21/2013 10:57 AM, Even Rouault wrote:
> > 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 ?
>
> <?xml version="1.0" encoding="utf-8" ?>
> <ogr:FeatureCollection
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>       xsi:schemaLocation="http://ogr.maptools.org/ .xsd"
>       xmlns:ogr="http://ogr.maptools.org/"
>       xmlns:gml="http://www.opengis.net/gml">
>    <gml:featureMember>
>      <ogr:vtest_geom_  fid="vtest_geom_.0">
>        <ogr:geometryProperty><gml:Point
>
srsName="EPSG:3067"><gml:coordinates>185607.11328746471554,6718884.468898030929267</gml:coordinates></gml:Point></ogr:geometryProperty>
>        <ogr:id>6483</ogr:id>
>      </ogr:vtest_geom_>
>    </gml:featureMember>
>
> ...
>
> >   My
> > hypothesis would be that the FeatureCollection root element is in a XML
> > namespace different from none, gml or wfs.
>
> It seems to be in ogr (it's made by GDAL). I'll try changing that.

Yes, that's the likely cause and using wfs as the namespace should fix it.

Perhaps the detection of WFS documents could be made more robust, but in the
above case, I'm not sure that GML documents emitted by default by OGR are valid
WFS documents that could be successfully read by other WFS clients. I think (but
I'm not 100% positive about that) that the wfs namespace should appear
somewhere. At least that's what I've seen in all documents emitted by WFS
servers.

>
> >
> > Does the probing of .resolved.gml, apart from slowing down the process,
> prevent
> > the driver to parse the GetFeature document ?
>
> yes, the resolved.gml is not older than the GetFeature doc, thus it is
> used and found to be empty. I commented that out but it still can't
> parse the features.

Ah right, since the .resolved.gml is in a GET parameter, the server returns a
successfull HTTP code...


More information about the gdal-dev mailing list