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

Update URLs to https #915

Merged
merged 1 commit into from
May 10, 2022
Merged

Update URLs to https #915

merged 1 commit into from
May 10, 2022

Conversation

sudo-bmitch
Copy link
Contributor

Fixes #913

I didn't touch the licensing links, and the broken link in the README.md (see #914).

Signed-off-by: Brandon Mitchell git@bmitch.net

Signed-off-by: Brandon Mitchell <git@bmitch.net>
@jdolitsky
Copy link
Member

For CI failure, see #916

Copy link
Member

@vbatts vbatts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧁

@vbatts vbatts merged commit 8685486 into opencontainers:main May 10, 2022
@sudo-bmitch sudo-bmitch deleted the pr-https branch May 10, 2022 20:36
@@ -1,6 +1,6 @@
{
"description": "OpenContainer Image Manifest Specification",
"$schema": "http://json-schema.org/draft-04/schema#",
"$schema": "https://json-schema.org/draft-04/schema#",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this valid? The draft 04 spec defines HTTP and make no mention of HTTPS. This trips up some lookups that downstream libraries do: https://github.com/davishmcclurg/json_schemer/blob/bbfed4ccdcab85c540568effefcbef308c5bb6a4/lib/json_schemer.rb#L34-L37

The move from HTTP to HTTPS happened in draft 2019-09 (aka draft 8), so I think it's safer to only update this to HTTPS if also updating to that draft.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Https support is on the entire webserver, isn't it?

Copy link

@Bo98 Bo98 May 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, it needs to be anyway for newer drafts. But then you can also equally say dropping the # works or having a URL redirect service works.

The $schema isn't just a place you can go download the schema file. It doubles up as an identifier:

The "$schema" keyword is both used as a JSON Schema version
identifier and the location of a resource which is itself a JSON
Schema, which describes any schema written for this particular
version.

http://json-schema.org/draft-04/schema# is explicitly predefined in the draft (as well as here: https://json-schema.org/understanding-json-schema/reference/schema.html, which shows the HTTPS change in 2019-09). Other forms are not defined. While it's not illegal to have different URIs (in fact, this is needed for people to extend the core JSON schema), the whole point of an identifier does diminish if we need to consider the nature of internet protocols, redirects etc, effectively turning this from an offline ID check to an online fetch. I don't think anything deviating from the predefined values should be expected to work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Since I'm not using that field, I'll leave the call up to others if it makes sense to go to a newer draft or revert back to http.

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

Successfully merging this pull request may close these issues.

RFC 2119 broken link
6 participants