External seeAlso references are erroneously sent back to the Definitions Server

[ghobona]

Currently external seeAlso references are erroneously sent back to the Definitions Server. This causes an InputError (with 400 status code) because the references are URLs to external resources.

The Definitions Server should be modified to allow external seeAlso references to navigate to those external URLs and not back to the Definitions Server.

[jerstlouis]

Clicking see also on any TileMatrixSet e.g.,

http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid

Results in a 400 Input Error.

The URL that see also links to is e.g.,

https://defs.opengis.net/vocprez/object?uri=http%3A//schemas.opengis.net/tms/1.0/json/examples/GNOSISGlobalGrid.json

The value of the uri query parameter, the external link, is an invalid URI for the definition server.

This makes it impossible for users/developers to manually retrieve a TileMatrixSet definition from the registry.

To correct this error, for external links, the link should directly point to the external See Also link, instead of linking to vocprez/object with a ?uri= pointing to an external link that is an invalid URI.

See also additional comments from Clemens in #197 (comment) .

[cportele]

Copied from #197:

I also get 400 errors for most definitions server requests. In my case the behavior depends on the browser:

Chrome (latest version): When I click on http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid, I get a 307 redirect due to HSTS to https://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid which in turn results in a 303 redirect to http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid which returns 400 Bad Request.

This is what I see in the browser:

Firefox: There is no 307 HSTS redirect and I directly get a 303 redirect to http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid (note: http, not https).

When I try https://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid in Firefox, I also get the 400 error.

[jerstlouis]

I believe the issue reported by @cportele needs to be addressed as well but it is a different issue, not directly related to the external see also link, but similar case of redirection with an invalid uri query parameter, in this case because of the use of https:

• The following (the first redirects the second) also return a 400 for me:
  • https://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid
  • http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid

Because the URIs are defined as http, not https, the uri= query parameter, currently automatically set up with redirection, should never have an https value, even when the definition server is being accessed via https. Avoiding unnecessary re-direction (#109) would also side-step this issue.

[rob-metalinkage]

We have a fix for the seeAlso being pushed through - it will use a local link only if we have information about the link, otherwise support the link - however we need to work on the issue of being allowed to jump to a http link from a https resource...

http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid links to the resource with that identifer

so does

https://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid

except in this case there is no such resource - the URIs are not the same in the baseline architecture of the web...

so the question is what is the requirement for customised handling of "near misses" - or a policy that declares they should be the same (which we need to formally propose and adopt)...

should we find the "close match" and give the user a big alert that they reached this resource via a non-canonical URI ?

the same issue is handling sameAs where an explicit declaration, and also the issue of version negotiation #116

please post this as a NA discussion needing policy determination - we will update infrastructure to meet requirements agreed.

[rob-metalinkage]

Note #116 has been resolved for the name type specification - not the general case - i.e. we dont have rules when to enforce the sameAs beyond "Where the URI of a named resource has an alias," - i.e. is https an automatic alias for http ? and does this apply to versions? There is also no requirement for how the human interface should treat or warn users what is happening.

[rob-metalinkage]

Assigning to Alejandro Villar to explore UI options and to configure entailment as per this requirement where a sameAs is declared.

[cportele]

http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid links to the resource with that identifer

so does

https://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid

except in this case there is no such resource - the URIs are not the same in the baseline architecture of the web...

If there is no resource https://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid, then the HSTS redirects must be deactivated on the server, because HSTS redirects the first URI to the second resource.

[rob-metalinkage]

Can you please identify your http client that is triggering this redirect - this does not happen on Google Chrome or Microsoft Edge for me. It may not be the server but some intermediate proxy?

I have checked apache configuration on the definition server and hsts is not enabled - will check if it is at the top level of the domain.

[cportele]

I am using Google Chrome, Version 105.0.5195.125 (arm64). There is no proxy.

I checked the HSTS information for www.opengis.net in Chrome and based on it looks as if www.opengis.net sent HSTS headers at least on September 14 with an expiry in six months (March 2023):

• dynamic_sts_domain: www.opengis.net
• dynamic_upgrade_mode: FORCE_HTTPS
• dynamic_sts_include_subdomains: true
• dynamic_sts_observed: 1663158971.616693
• dynamic_sts_expiry: 1678883771.616687

I removed the HSTS cache for www.opengis.net and now the error is gone. So, for me the problem is solved, but there may be some issue in the infrastructure.

[rob-metalinkage]

thanks - if we get other reports we might need to look at catching these somehow and warning users. Assigning to Kevin for advice.

[avillar]

Bugfix for seeAlso handling is live in production (see https://defs.opengis.net/vocprez/object?uri=http%3A//www.opengis.net/def/tilematrixset/OGC/1.0/WorldMercatorWGS84Quad)

[jerstlouis]

Thank you @avillar @rob-metalinkage . It is great that this is now fixed!

Please note that different related problems remain:

• https://www.opengis.net/def/tilematrixset/OGC/1.0/WorldMercatorWGS84Quad -- This also (still) results in a 400. When/While a re-direct is needed, I would suggest to re-direct to http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldMercatorWGS84Quad which does not have the issue instead of http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/tilematrixset/OGC/1.0/WorldMercatorWGS84Quad. Should we file a separate issue for this, so that this one can be closed?
• That particular see also ( http://schemas.opengis.net/tms/1.0/json/examples/WorldMercatorWGS84Quad.json ) is not the resource that we would like to link users to, and neither is the newer version of that example. The JSON representation should be sourced from the TileMatrixSet registry GitHub repo, which does not have all of the exact same files, in this case the source would be here. Deprecate v1.0 tile matrix set examples #199 is about deprecating those old examples (where I clarify that actually we should not link to neither the 1.0 or 2.0 examples from the schemas directory), and ingest process for TileMatrixSet registry #203 is about the ingest process from the GitHub repo, but the comments there are focused on SKOS view rather than returning the JSON/XML encodings themselves. Return actual definition in negotiated media type #109 was about returning the definition directly, but is now closed. Possibly Not possible to retrieve TileMatrixSet definitions from definitions server #198 sufficiently covers the scope of this remaining problem.

Thank you.

[ghobona]

Thanks @avillar !