[Geoserver-devel] geoserver-trunk: requests without the 'version' parameter?

GeoServer GeoServer Developer
1

In running some old WFS requests against the new dispatching system in geoserver trunk, I was caught by two hard-to-figure-out 'bugs' with my requests:

1) My request wasn't in the right namespace. In the past geoserver has been very lax about requiring the <GetFeature> tag to be in the "http://www.opengis.net/wfs&quot; namespace.
Question: is this intentional? Or should we be more forgiving?

2) My request didn't have the 'version="1.0.0"' parameter on it. In the past this defaulted to version 1.0.0 (easy, as there was only one version of the WFS!). Now it defaults to 1.1.0 (there's code in the Dispatcher which prioritizes versions by 'recent-ness').
Question: is this intentional? Should we default to version 1.0.0, or 1.1.0?

Here're my thoughts:

There's a sizeable group of people who've written applications expecting geoserver to behave a certain way. If they upgrade to 1.6.x and everything they've written breaks (even though their requests are actually the problem as they weren't valid to start with!) then I think that's a bad thing. I think we should be very lax, and either enforce validity by being annoying (watermark images from invalid WMS requests with a 'hey...fix your request') or by having a 'strict' switch that changes to a more strict mode.

On the other hand, adding 'not-so-strict'ness to the Dispatcher takes an EXTREMELY clean and well-laid out piece of code and makes it much less clean. That makes me a little sad.

--saul

2

Hi Saul,

A lot of these checks were to comply with cite tests for wfs 1.1. The namespace one is hard since the new parser is pretty dependent on matching the namespaces up correctly. The version one should be pretty easy. However now that we support both wfs 1.0 and wfs 1.1 its a lot more important.

Regardless, both of things could fall under the "cite hacks" category, in which a flag controls if these checks are made or not. The dispatcher has a flag directly on it to set cite compliance or not. It uses it for some things but not all. I think i have a few jiras open for stuff like this.

So I definitely think there are some things that we should be more lax on. And I think that anything we have supported in the past we should support now. So feel free to schedule any bugs against 1.6.x for things the dispatcher is raising an error for now that it did not used to.

-Justin

Farber, Saul (ENV) wrote:

In running some old WFS requests against the new dispatching system in geoserver trunk, I was caught by two hard-to-figure-out 'bugs' with my requests:

1) My request wasn't in the right namespace. In the past geoserver has been very lax about requiring the <GetFeature> tag to be in the "http://www.opengis.net/wfs&quot; namespace.
Question: is this intentional? Or should we be more forgiving?

2) My request didn't have the 'version="1.0.0"' parameter on it. In the past this defaulted to version 1.0.0 (easy, as there was only one version of the WFS!). Now it defaults to 1.1.0 (there's code in the Dispatcher which prioritizes versions by 'recent-ness').
Question: is this intentional? Should we default to version 1.0.0, or 1.1.0?

Here're my thoughts:

There's a sizeable group of people who've written applications expecting geoserver to behave a certain way. If they upgrade to 1.6.x and everything they've written breaks (even though their requests are actually the problem as they weren't valid to start with!) then I think that's a bad thing. I think we should be very lax, and either enforce validity by being annoying (watermark images from invalid WMS requests with a 'hey...fix your request') or by having a 'strict' switch that changes to a more strict mode.

On the other hand, adding 'not-so-strict'ness to the Dispatcher takes an EXTREMELY clean and well-laid out piece of code and makes it much less clean. That makes me a little sad.

--saul

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

3

Justin Deoliveira ha scritto:

Hi Saul,

A lot of these checks were to comply with cite tests for wfs 1.1. The namespace one is hard since the new parser is pretty dependent on matching the namespaces up correctly. The version one should be pretty easy. However now that we support both wfs 1.0 and wfs 1.1 its a lot more important.

Regardless, both of things could fall under the "cite hacks" category, in which a flag controls if these checks are made or not. The dispatcher has a flag directly on it to set cite compliance or not. It uses it for some things but not all. I think i have a few jiras open for stuff like this.

So I definitely think there are some things that we should be more lax on. And I think that anything we have supported in the past we should support now. So feel free to schedule any bugs against 1.6.x for things the dispatcher is raising an error for now that it did not used to.

Just to share my 2 cents, what does the standard say?
I was looking into the wfs schemas, and I see the following:

wfs.xsd, BaseRequestType:
<xsd:attribute name="version" type="xsd:string"
                      use="optional" default="1.1.0">

whilst in wfs-basic.xsd, wfs 1.0, GetFeature, we have:
<xsd:attribute name="version"
                      type="xsd:string" use="required" fixed="1.0.0"/>

So, it seems in WFS 1.1 we could omit the version attribute, whilst
in 1.0 we cannot? Bleah, exactly the opposite of what we would like.

If the user did reference the wfs schema, we could use that reference
to decide on the wfs service level (not sure it's easy at all, but
since we parse the xsd anyways, we could use some elements or check
the default version value, no?).
If they are missing, we need a default, maybe configurable, since by
specification we should answer a GetFeature request with no version hints whatsoever as if it was a 1.1 request, no?
I mean, by making 1.0 the default we could break legitimate wfs 1.1
clients.

Cheers
Andrea

4

The spec says that version is only optional on a GetCapabilities request. All others it is mandatory. For a GetCapabilities request the version negotiation scheme is well defined, the most relevant aspect of it being that when no version is specified, the highest version supported by the server should be returned. This is a problem because clients that did not specify version before will be getting back a difference capabilities document.

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Saul,

A lot of these checks were to comply with cite tests for wfs 1.1. The namespace one is hard since the new parser is pretty dependent on matching the namespaces up correctly. The version one should be pretty easy. However now that we support both wfs 1.0 and wfs 1.1 its a lot more important.

Regardless, both of things could fall under the "cite hacks" category, in which a flag controls if these checks are made or not. The dispatcher has a flag directly on it to set cite compliance or not. It uses it for some things but not all. I think i have a few jiras open for stuff like this.

So I definitely think there are some things that we should be more lax on. And I think that anything we have supported in the past we should support now. So feel free to schedule any bugs against 1.6.x for things the dispatcher is raising an error for now that it did not used to.

Just to share my 2 cents, what does the standard say?
I was looking into the wfs schemas, and I see the following:

wfs.xsd, BaseRequestType:
<xsd:attribute name="version" type="xsd:string"
                     use="optional" default="1.1.0">

whilst in wfs-basic.xsd, wfs 1.0, GetFeature, we have:
<xsd:attribute name="version"
                     type="xsd:string" use="required" fixed="1.0.0"/>

So, it seems in WFS 1.1 we could omit the version attribute, whilst
in 1.0 we cannot? Bleah, exactly the opposite of what we would like.

If the user did reference the wfs schema, we could use that reference
to decide on the wfs service level (not sure it's easy at all, but
since we parse the xsd anyways, we could use some elements or check
the default version value, no?).
If they are missing, we need a default, maybe configurable, since by
specification we should answer a GetFeature request with no version hints whatsoever as if it was a 1.1 request, no?
I mean, by making 1.0 the default we could break legitimate wfs 1.1
clients.

Cheers
Andrea

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org