Skip to content
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

OSM tiles response error when loaded with Cesium #12402

Closed
giohappy opened this issue Jul 9, 2024 · 4 comments · Fixed by #12403
Closed

OSM tiles response error when loaded with Cesium #12402

giohappy opened this issue Jul 9, 2024 · 4 comments · Fixed by #12403
Assignees
Milestone

Comments

@giohappy
Copy link
Contributor

giohappy commented Jul 9, 2024

On the contrary of MapStore itself, the GeoNode client receives a response error (418 I'm a teapot) for OSM tiles loaded by the Cesium viewer.

After investigating a few combinations of headers, it looks like the two problematic ones are:

  • accept: */* -> apparently this is accepted if the Referrer is also set (don't know why!)
  • missing referrer -> it's ok only if accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8' is set

3D viewer in GeoNode:

  • the referrer is not sent and accept is set to */* -> we get the error

2D viewer in GeoNode:

  • the referrer is not sent BUT accept is set to image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 -> we get the tiles

2D and 3D in MapStore behave the same as GeoNode for the accept header but the referrer in MapStore is set for both cases.
So the problem is the missing Referrer inside the requests from GeoNode + Cesium.

The reason the referrer is not sent is due to different values for the Referrer Policy header set by MapStore and GeoNode:

The quick solutions is to add SECURE_REFERRER_POLICY = 'strict-origin-when-cross-origin' to GeoNode settings.

@giohappy giohappy self-assigned this Jul 9, 2024
@giohappy giohappy added this to the 4.3.1 milestone Jul 9, 2024
@giohappy giohappy transferred this issue from GeoNode/geonode-mapstore-client Jul 9, 2024
giohappy added a commit that referenced this issue Jul 9, 2024
…as default (#12403)

* Referre poicy strict-origin-when-cross-origin as default

* adapt proxy tests to adapt to new referrer policy
github-actions bot pushed a commit that referenced this issue Jul 9, 2024
…as default (#12403)

* Referre poicy strict-origin-when-cross-origin as default

* adapt proxy tests to adapt to new referrer policy

(cherry picked from commit 8bb5eda)
giohappy added a commit that referenced this issue Jul 9, 2024
…as default (#12403) (#12404)

* Referre poicy strict-origin-when-cross-origin as default

* adapt proxy tests to adapt to new referrer policy

(cherry picked from commit 8bb5eda)

Co-authored-by: Giovanni Allegri <[email protected]>
@ridoo
Copy link
Contributor

ridoo commented Jul 9, 2024

An evergreen of nerd history 🫖 ..

Weird behavior, though. Perhaps, the tiles serving backend has HTCPCP enabled, or what?

I see that python's request lib is implementing '418' response code and some SO posts indicate, that such status can be returned even when scheme is not 'coffee://'.

In your tests, the user-agent was set?

@gannebamm gannebamm changed the title OSM tiles response error when loaded with Ceium OSM tiles response error when loaded with Cesium Jul 10, 2024
@giohappy
Copy link
Contributor Author

@ridoo I think OSM simply uses that nerdy return code when either the referrer is missing or that accept header is not fully specified.
We should ask OSM maintainers the reason for this odd combination. The agent is set by the browser's HTTP client libs underlying MS and Cesium.
In my tests this is what is set: user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

@ridoo
Copy link
Contributor

ridoo commented Jul 11, 2024

Hey @giohappy it seems that the missing Referer conflicts with OSM's technical usage-policy:

  • Valid HTTP User-Agent identifying application. Faking another app’s User-Agent WILL get you blocked. Using a library’s default User-Agent is NOT recommended as they may be blocked if another user of the library is misusing it. If a device automatically sends an X-Requested-With header with an application specific Application ID, this will be considered an acceptable substitute for the HTTP User-Agent, although we still recommend setting a valid HTTP User-Agent for the application.
  • When coming from a web page, a valid HTTP Referer. Apps generally do not have a HTTP referer.
  • DO NOT send no-cache headers. (“Cache-Control: no-cache”, “Pragma: no-cache” etc.)
  • Cache Tile downloads locally according to HTTP Expiry Header, alternatively a minimum of 7 days.
  • Recommended: HTTP/2 or HTTP/3 support to allow multiplexed downloads

@giohappy
Copy link
Contributor Author

Yes @ridoo that's why I changed the settings. Now the Referrer is sent as requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants