Provide the ability to serve the Spec over `http`

[coiouhkc]

Reason/Context

Initial discussion - https://asyncapi.slack.com/archives/C0230UAM6R3/p1697557159905629.

As of now the spec uses http in $ref but the site internally redirects to https, which breaks at least one Java generator (see https://github.com/joelittlejohn/jsonschema2pojo/issues/1509).

Generally, in certain cases the automated upgrade from http to https is discouraged (see https://stackoverflow.com/questions/1884230/httpurlconnection-doesnt-follow-redirect-from-http-to-https for a sample discussion).

Description

Support serving the spec via http for all $refs using http without the necessity to redirect.

[github-actions[bot]]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[AbhishekCS3459]

@coiouhkc I want to work on this issue but I don't have the access to slack account.

[smoya]

I want to clarify some topics here.

Redirecting from an http to an https location is common and kinda standard technique.

Redirecting (301) from http to https is a well known technique, accepted and widely supported by most HTTP clients (i.e. get, curl... but also most of language implementations). It is, in fact, the very first time I see an issue with a redirection of this kind being reported as not compliant.

OWASP TLS protection cheatsheet mentions and recommends this redirection as a mechanism to ensure you serve all content over HTTPS which is recommended and encourage by them.

Another critical example of how accepted this redirect is, is the HSTS IETF doc, which describes how the [HSTS](https://www.troyhunt.com/understanding-http-strict-transport/ specification considers a host should behave when receiving a request over a non-secure transport:

If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect, such as status code 301

The way AsyncAPI serves the JSON Schema documents

At this moment, all JSON Schema docs are being served under https://asyncapi.com/definitions and https://asyncapi.com/schema-store. I.e. https://asyncapi.com/definitions/2.6.0.json. In short, those files are served right directly from our statically website hosted in Netlify. Netlify does an automatic redirect of all the requests made from http to https and can't be disabled; it is part of their commitment to make the website a more secure place.

Scope of this issue

In my opinion, it is definitely an issue in the client being used by the https://github.com/joelittlejohn/jsonschema2pojo library, which seems to be some native Java library as stated by @coiouhkc here.

My concern here is more focused on what is the real impact of this issue. Are there any other libraries affected or it is only this particular one?

cc @derberg @jonaslagoni as you were in the original slack thread as well

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[AnimeshKumar923]

still valid? @smoya @derberg @jonaslagoni

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart: