SwaggerUI throws an error when changing Servers

[ponelat]

SwaggerUI throws error: Uncaught TypeError: Failed to construct 'URL': Invalid base URL
When changing server (from the dropdown)

Steps:

• Load the following API definition: https://gist.github.com/ponelat/71dba4b85b403455e0718383f7cf3bd3
• Change the server from dropdown

Expected:

The server field is changed

Actual:
An Uncaught TypeError is thrown

SwaggerUI demo with definition: https://petstore.swagger.io/?url=https://gist.githubusercontent.com/ponelat/71dba4b85b403455e0718383f7cf3bd3/raw/50737b50e2ee42ebfc5afa7fb5137b588c6ba0cc/server-url-issue.yml#/default/get_something

[char0n]

Right, I can confirm on v4 as well. It crashes the SwaggerUI entirely as there is no error boundary to catch this error. I'm incorporating it for v4 bugfixes.

[mathis-m]

@char0n @ponelat had a quick check on this. Looks like this is the expected behavior, because the spec is invalid!
As OAS states the info.contact.url MUST be in form of an URL.
So just change url: contact to url: /contact:

openapi: 3.0.0
info:
  title: Test API
  version: 1.0.0
  contact:
    name: Contact us
    url: /contact

servers:
  - url: https://api.example.com/foo/bar
  - url: https://api.example.com:{port}/{basePath}
    variables:
      port:
        default: '4443'
      basePath:
        default: v1

paths:
  /something:
    get:
      responses:
        '200':
          description: ok

[char0n]

@mathis-m thanks for having look at it!

Given your findings, it's reasonable to assume that not having a valid URL in info.contact.url will not crash the SwaggerUI while changing server URL.

[mathis-m]

@char0n shall I prepare a PR that catches this case?
What would be. The expected behavior?

[char0n]

@char0n shall I prepare a PR that catches this case? What would be.

Sure, that would be great.

The expected behavior?

First of all I'd say that the minim baseline for expected behavior is to make sure SwaggerUI doesn't crash completely because of this. This can be achieved by using error boundary around the code that causes unexpected failure.

Better solution would be amend the code in a way so that the unexpected failure doesn't happen.

[hkosova]

Looks like this is the expected behavior, because the spec is invalid!
As OAS states the info.contact.url MUST be in form of an URL.
So just change url: contact to url: /contact

contact without a leading / is a perfectly valid relative URL according to RFC 3986. See the path-rootless ABNF and the examples in section 5.4. It's supposed to be resolved relative to the API server URL.

For example

servers:
  - url: https://example.com/foo/bar
info:
  contact:
    url: contact

means that the contact URL is https://example.com/foo/contact.

JavaScript URL constructor supports such URLs:

> new URL("contact", "https://example.com/foo/bar").href
'https://example.com/foo/contact'

[char0n]

@hkosova is right.

The original error is: Uncaught TypeError: Failed to construct 'URL': Invalid base URL

new URL("contact", "https://api.example.com:{port}/{basePath}")

This code throws exactly that error. Possible problem could be that the Server URL is used for resolution before it's variables gets trancluded. But we have to dive deep into code to see what actually causes this error.

[char0n]

This is the next priority for #7341 as it causes SwaggerUI to crash.

[mathis-m]

@char0n your linkedin post reminded me of this issue. I had a quick check and it is obvious that if port is in template syntax it is not possible to parse it in the right way.

[char0n]

Right, so it seems like the bug is what I describe in last paragraph of #7525 (comment)

[char0n]

PR with the bugfix has been issued. Cause of the problem and it's solution have been provided in PR description