ogcapi-features
ogcapi-features copied to clipboard
opengeospatial
provide schemas.opengis.net via HTTPS?
If I remeber well, the view so far was that HTTPS just adds overhead for fetching resources that are freely available anyhow (that of course assumes that there is little incentive for a third party to exploit this security gap).
In any case, if https is supported in the future, http should still work, too, so that existing links still work (also without a redirect, most XML parsers don't support redirects).
This is somewhat tangential but for the record: The defs server supports both http and https for URI resources - but they are not currently assumed to be the same (i.e. the content needs to be one or the other).. I could entail an owl:sameAs statement and upgrade the API logic, or do something funky in the redirects to always look for the http version so i dont think there is a barrier from the defs sever end to a policy that http and https resources are equivalent and accessible by either protocol... but I feel that we should be consistent across the OGC infrastructure if we do this and have a formal policy to support whatever choice.
The lack of https support is actively impacting at least one project, the pygeoapi project. You can see details in in this issue: https://github.com/geopython/pygeoapi/issues/312 . Basically, the swagger UI makes a client-side call to get the openAPI definition at http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/ogcapi-features-1.yaml and that leads to browsers blocking the call due to mixed content.
You can see the mixed content issue on the pygeoAPI demo swagger page here: https://demo.pygeoapi.io/master/openapi?f=html#/obs/get_collections_obs_items
Any thoughts on this issue? Agreed that both http and https should be supported. We (pygeoapi) continue to have breakages when deploying via https.
@kstegemoller - Any update on your thoughts for providing the schemas.opengis.net resources also via HTTPS in addition to HTTP? The last comments show that there is a need.
In terms of the relationship between the two resources, in my opinion, they should be considered the same resource within schemas.opengis.net and probably also for everything under the definitions server. Why not simply add a rel="canonical" HTTP header with the href pointing to the HTTP URI in the HTTPS response? This should also help to avoid duplicate content in search engines, etc.
@ghobona @kstegemoller is there a more applicable repo to track this issue (given this is beyond ogcapi-features)?
@tomkralidis Thanks for making us aware of this thread.
I will discuss some possible options with the OGC Infrastructure Office and let you know once we identify a way forward.
Thanks very much @ghobona. While we are at it, where's a good place to ask for another change to schemas.opengis.net (here or another repo)?
The problem as I see it is when this is implemented people are going to reference https schemas while older schema/XML will reference the http URLs. While the content would be the same, as far as I know, parsers would not see as the same. Since namespaces are tied to a single schema location, it seems like this might generate more issues than it solves. Does anyone else view this as a problem or I missing something important?
The proposed solution to use Canonical http reference seems like the best option but I don't know how this will work with schema and parsers and reality.
Good points. If clients are doing XML validation in the browser this will be an issue (e.g. absolute xs:import's in http://schemas.opengis.net/cat/csw/3.0/record.xsd) and will result in mixed content issues all over again.
For rel="canonical" setup, perhaps we can setup a test HTTPS environment to evaluate further.