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

Should we allow relative server? #16

Open
dachrillz opened this issue Aug 3, 2022 · 0 comments
Open

Should we allow relative server? #16

dachrillz opened this issue Aug 3, 2022 · 0 comments
Labels
question Further information is requested

Comments

@dachrillz
Copy link
Contributor

dachrillz commented Aug 3, 2022

Currently we allow a server in the open api specification to be a relative path. E.g. https://petstore3.swagger.io/ has such a specification.

However, according to the specification of OpenApi 3 (https://swagger.io/docs/specification/api-host-and-base-path/) the following is stated: "If the server URL is relative, it is resolved against the server where the given OpenApi definition file is hosted..."

I guess we can proceed in three ways,

  1. Allow relative server url. This means that one can verify e.g. the petstore3 OpenApi spec.
  2. Fail if a relative server is passed to the program. This would nudge people to write proper server urls, but could be annoying.
  3. Include an options --spec-source-url so that relative server can be properly expanded.

It probably comes down to how peoeple write their specifications. If relative server urls are common they should be supported in my opinion.

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

No branches or pull requests

1 participant