Bug report #15258: WMS/WMTS don't like special character in requests by 2.16 Nødebo - QGIS Application - QGIS Issue Tracking

Bug report #15258

WMS/WMTS don't like special character in requests by 2.16 Nødebo

Added by Klas Karlsson over 8 years ago. Updated over 8 years ago.

Status:	Closed
Priority:	Severe/Regression
Assignee:	-
Category:	Web Services clients/WMS
Affected QGIS version:	2.16.1	Regression?:	No
Operating System:		Easy fix?:	No
Pull Request or Patch supplied:	No	Resolution:
Crashes QGIS or corrupts data:	No	Copied to github as #:	23194

Description

I have a WMTS service I use to connect to in QGIS, but after update to 2.16 this service does not work.

Attached is XML for the connection.

lm.xml (434 Bytes) Klas Karlsson, 2016-07-11 09:27 AM

fiddler_output.png - HTTP headers and responses from Fiddler, comparing QGIS 2.14.4 and 2.16.0 (37.2 KB) Mattias Spangmyr, 2016-07-29 02:13 AM

Associated revisions

Revision bce5ed52
Added by Jürgen Fischer over 8 years ago

exclude release name from version string (fixes #15258)

(cherry picked from commit 1391aad2f713a796b0ac3d0c22bec6c1c7ada3bb)

History

#1 Updated by Klas Karlsson over 8 years ago

I've tried with multiple Linux (Ubuntu) versions with same result.

The only Windows 10 computer I've tried will add the layer, but will give a lot of errors after a few zoom/pan operations.

The layer works fine on 2.14.4 LTR!

#2 Updated by Klas Karlsson over 8 years ago

Now I've tried a few other WMTS services and most seem to work so, what has changed in 2.16 that makes my particular layer stop working?

Working: http://opencache.statkart.no/gatekeeper/gk/gk.open_wmts?Version=1.0.0&service=wmts&request=getcapabilities
Not working: https://api.lantmateriet.se/open/topowebb-ccby/v1/wmts/token/b33b7fec47e14eb6e02539ad1a24cae2/?service=wmts&request=getcapabilities

Is it the https?

#3 Updated by Giovanni Manghi over 8 years ago

Category set to Web Services clients/WMS
Priority changed from Normal to Severe/Regression

#4 Updated by Giovanni Manghi over 8 years ago

Affected QGIS version changed from master to 2.16.0

#5 Updated by Klas Karlsson over 8 years ago

I have installed QGIS 2.17 (master) on a clean Xubuntu VM and the WMTS works great (can not trace any fix though)!

"Purging" the install and re-installing 2.16 will enable the service to some extent, but the problem resembles Windows behavior where "tileRequest" is invalid resulting in white tiles.

#6 Updated by Giovanni Manghi over 8 years ago

Status changed from Open to Feedback

Have you tried to clear the cache in the QGIS general options?

#7 Updated by Klas Karlsson over 8 years ago

No change after cleared cache. It is still impossible to add my WMTS layer in QGIS 2.16.

I haven't gone through the process of updating to master, purging, reinstalling, though. Shouldn't be necessary.

Something tells me any shown tiles will be blank too, if the cache is cleared.

New info though: A clean 2.16 install on Windows gives the same problem as on Linux, the WMTS layer can not be added (no cache I guess).

#8 Updated by Klas Karlsson over 8 years ago

Went back to Windows computer with "semi working" WMTS and cleared cache... Now it is not accepting the WMTS from "Lantmäteriet" at all.

Still, the Norwegian WMTS works... And as far as I can see the only difference is "https" in the Swedish service.

Can I collect some logs somehow to find a possible solution?

#9 Updated by Giovanni Manghi over 8 years ago

Status changed from Feedback to Open

#10 Updated by Mattias Spangmyr over 8 years ago

File fiddler_output.png added

I also experienced this issue with the same WMS source as Klas Karlsson, also only on 2.16.0.

When comparing the GetCapabilities-requests between 2.16.0 and 2.14.4 with Fiddler the only difference I found was the "User-Agent" in the HTTP header. In 2.14.4 it's given as "Mozilla/5.0 QGIS/2.14.4-Essen" while in the new version it's "Mozilla/5.0 QGIS/2.16.0-Nødebo".

If I "fiddle" with the request and change the header's User-Agent to "Mozilla/5.0 QGIS/2.16.0-Nodebo" the request is accepted with the expected response.

My guess is that the WMS provider in this case does not allow exotic characters in the HTTP header. This would explain why the same WMS suddenly works again in 2.17 with no apparent fixes.