Skip to content

Handle WFS version mismatch#1039

Merged
geographika merged 3 commits into
geopython:masterfrom
JakobMiksch:wfs-version-mismatch
Jun 4, 2026
Merged

Handle WFS version mismatch#1039
geographika merged 3 commits into
geopython:masterfrom
JakobMiksch:wfs-version-mismatch

Conversation

@JakobMiksch

@JakobMiksch JakobMiksch commented May 31, 2026

Copy link
Copy Markdown
Contributor

@geographika

Copy link
Copy Markdown
Contributor

Nice work - thanks @JakobMiksch ! Unless @tomkralidis has any further comments I'll merge in a day or so.

@domlowe

domlowe commented Jun 1, 2026

Copy link
Copy Markdown
Member

Just to say that the WFS version negotiation rules do allow the server to return alternative versions:
https://docs.ogc.org/is/04-094r1/04-094r1.html#15

But it is essentially a client decision how to deal with alternative versions - e.g. whether to accept it, ask for an alternative or cease communicating (as is the case in this PR).

@geographika

geographika commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

Thanks for the details @domlowe. The warning is an improvement on simply failing when parsing using the incorrect class.
@JakobMiksch - what happens if no version is sent with the GetCapabilities request? I guess it uses the default "1.0".

@JakobMiksch

JakobMiksch commented Jun 1, 2026

Copy link
Copy Markdown
Contributor Author

@geographika

what happens if no version is sent with the GetCapabilities request? I guess it uses the default "1.0".

It would raise an exception as well. I have not handled this case.

@JakobMiksch

JakobMiksch commented Jun 1, 2026

Copy link
Copy Markdown
Contributor Author

Just to say that the WFS version negotiation rules do allow the server to return alternative versions: https://docs.ogc.org/is/04-094r1/04-094r1.html#15

But it is essentially a client decision how to deal with alternative versions - e.g. whether to accept it, ask for an alternative or cease communicating (as is the case in this PR).

If users rely on the current functionality, we could hide the new check behind a new opening argument, that is False by default. Something like this maybe:

wfs = WebFeatureService(
   url="https://www.geoproxy.geoportal-th.de/geoproxy/services/STRNETZ_wfs", 
   version="1.0.0", 
   strict_version=False # <-- NEW OPTIONAL ARGUMENT
)

@geographika

Copy link
Copy Markdown
Contributor

@JakobMiksch - no I think this PR is an improvement on the current approach, but I will bump the version of the next release (from 0.35.0 to 0.36.0) as there is an API change in error type returned.

There is no version renegotiation implemented, so if a server returns a different GetCapabilities than expected it will fail with a parsing error as you discovered. By default WFS uses version 1.0.0, so prior to the PR:

>>> from owslib.wfs import WebFeatureService
>>> wfs = WebFeatureService(url="https://www.geoproxy.geoportal-th.de/geoproxy/services/STRNETZ_wfs")
AttributeError: 'NoneType' object has no attribute 'find'

After:

>>> from owslib.wfs import WebFeatureService
>>> wfs = WebFeatureService(url="https://www.geoproxy.geoportal-th.de/geoproxy/services/STRNETZ_wfs")
owslib.feature.common.CapabilitiesError: WFS version mismatch. Actual: 1.1.0, Requested: 1.0.0

@geographika geographika merged commit 2af4241 into geopython:master Jun 4, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Malformed WFS Capabilities causes cryptic stack trace

4 participants