A browser's (Chrome) DescribeFeatureType request to GeoServer version 2.12 returns an inline XML response in the browser's window.

Using that same browser to send a DescribeFeatureType request to a GeoServer version 2.14, the response is a document that is downloaded to the Windows' Downloads directory with the filename geoserver-describefeaturetype.application. This document contains the same XML content as the inline XML response when requesting from GeoServer version 2.12.

Coincidently, QGIS is not able to resolve the DescribeFeatureType request to the GeoServer version 2.14 but does resolve the DescribeFeatureType request from GeoServer 2.12.

We don't see any settings in GeoServer to modify how it responds to DescribeFeatureType requests.

Interestingly, a browser's GetCapabilities request to both versions of GeoServer yields an inline XML response from GeoServer.

The DescribeFeatureType request is in the form https://myserver.com/geoserver/mynamespace/wfs?request=DescribeFeatureType

and the GetCapabilities request is in the form


Most importantly, we want to get the WFS connection from QGIS to GeoServer version 2.14 working. But we also want the inline response to a DescribeFeatureType request.

Any suggestions?

  • I have no problem in using GeoServer 2.16 with QGIS 3.11. Please clarify how it appears that your QGIS can't read DescribeFeatureType from your server.
    – user30184
    Jan 15, 2020 at 8:46
  • You might be thinking about this the wrong way around. It's unlikely that GeoServer is giving different responses to the same request from different sources (unless you've tied it down with some security, but you've not mentioned that), it's much more likely that actual requests are different somehow.
    – nmtoken
    Jan 18, 2020 at 13:23
  • The other possibility is the response is the same, and Qgis can't parse it. This can happen with complex feature WFS
    – nmtoken
    Jan 19, 2020 at 12:35

1 Answer 1


A GetCapabilities request must include the service type, so https://myserver.com/geoserver/mynamespace/wfs?request=GetCapabilities is not correct, it should be:


This will give an XML result in your browser.

Similarly, a DescribeFeatureType request must include the service parameter and version, and ideally type to be described (otherwise you get all types), so should be something like:


You can also add an output format depending on what's listed in the GetCapabilities response for your version of service.

For QGIS you just specify the service URL (without any WFS request parameters) so just:


QGIS will (should) add appropriate WFS request parameters.

If QGIS (or any other client) can read the GetCapabilities response, but then fails in other operations you should check whether URLs in the GetCapabilities response are as expected. There's no requirement for all advertised URLs to be the same, though it's common.


typename vs. typenames in WFS requests

In a WFS 2.0.0 service the specification tells us to use typename for DescribeFeatureType request but typenames for GetFeature

  • Or you can use the global service from myserver.com/geoserver/wfs?
    – user30184
    Jan 15, 2020 at 8:48
  • Thanks, @nmtoken. I should have included the 'service=wfs` and version=2.0.0 in my post to avoid confusion. GeoServer fills in with default values if they are not present. The results are identical regardless if I explicitly include them in the URL or not - I still receive a document in my Downloads directory than inline within the browser window. Same with DescribeFeatureType. I agree with how the QGIS URL should be supplied - I already did that. I can see the layers, but when I double click on one of them to set a filter, I get the "DescribeFeatureType failed" message.
    – slalomchip
    Jan 16, 2020 at 1:42
  • @user30184 - We have Global Services enabled in GeoServer. I'm not an admin of the server and I don't quite understand what you mean by "use the global service from ...". Can you clarify?
    – slalomchip
    Jan 16, 2020 at 1:45
  • Global services are those which are not accessed by including the workspace part in the URL. localhost://geoserver/wfs is global while localhost://geoserver/topp/wfs, the URL model that was used in the answer, is pointing to a virtual service in the GeoServer vocubulary docs.geoserver.org/master/en/user/data/webadmin/workspaces.html. Versions 2.14 and 2.16 work for me with QGIS so the problem is not generally in the new version. Unfortunately I can't say why it fails for you.
    – user30184
    Jan 16, 2020 at 6:56
  • @slalomchip I've answered keeping the OGC specification in mind and the answer is applicable to any WFS not just one supplied by GeoServer, I know that GeoServer is lax in following the standards, but really as we're talking about basic operations of a WFS, let's keep to the standard. Note the standard tells us it must be service=WFS& and not per GeoServer documentation service=wfs&. If the response in the browser to the WFS DescribeFeatureType is a download, then you have the wrong mime type, try outputformat=text/xml;%20subtype=gml/2.1.2& assuming it's supported.
    – nmtoken
    Jan 16, 2020 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.