Skip to content

OGC API: Feature Creation Request Fails When Location Header is in Lowercase #61729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 of 2 tasks
RexSplode opened this issue May 6, 2025 · 1 comment
Open
1 of 2 tasks
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter!

Comments

@RexSplode
Copy link

What is the bug or the crash?

Hello!

I'm using the OGC API to facilitate communication between a REST API service and QGIS standalone.

During the feature creation process, QGIS sends a request to create a feature, and the service responds with a 204 No Content status along with a Location header containing the URL of the created feature.

However, this response undergoes additional processing by a server middleware, which conforms to HTTP/2 specifications by converting all response headers to lowercase, as stated in RFC 7540 Section 8.1.2.

After this conversion, QGIS displays an error message, indicating that the feature was not created.

Issue in Source Code:
if ( headerKeyValue.first == QByteArray( "Location" ) )

This logic expects the Location header to be camel case, meaning it does not properly handle headers in lowercase, as required by HTTP/2.

Requested Fix:
To ensure compatibility with HTTP/2, please modify the response header handling so that case is ignored when checking for the Location header.

Steps to reproduce the issue

  1. Use HTTP/2 protocol between OGC Server and QGis
  2. Connect QGis to OGC Server
  3. Attempt to create a feature and save it -> see the error in QGis window

Versions

3.34.14

Supported QGIS version

  • I'm running a supported QGIS version according to the roadmap.

New profile

Additional context

No response

@RexSplode RexSplode added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label May 6, 2025
@elpaso
Copy link
Contributor

elpaso commented May 6, 2025

This should probably fix it (not tested):

--- a/src/providers/wfs/oapif/qgsoapifcreatefeaturerequest.cpp
+++ b/src/providers/wfs/oapif/qgsoapifcreatefeaturerequest.cpp
@@ -61,7 +61,7 @@ QString QgsOapifCreateFeatureRequest::createFeature( const QgsOapifSharedData *s
   QString location;
   for ( const auto &headerKeyValue : mResponseHeaders )
   {
-    if ( headerKeyValue.first == QByteArray( "Location" ) )
+    if ( headerKeyValue.first.compare( QByteArray( "Location" ), Qt::CaseSensitivity::CaseInsensitive ) == 0 )
     {
       location = QString::fromUtf8( headerKeyValue.second );
       break;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter!
Projects
None yet
Development

No branches or pull requests

2 participants