Skip to content

Note relative URL-reference resolution ambiguity #4130

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Oct 14, 2024
Merged

Note relative URL-reference resolution ambiguity #4130

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1640363
Note relative URL-reference resolution ambiguity
handrews Oct 10, 2024
5cb6de9
Improve wording from review feedback
handrews Oct 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions versions/3.0.4.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -232,10 +232,15 @@ OpenAPI Description authors SHOULD consider how text using such extensions will
### Relative References in URLs

Unless specified otherwise, all fields that are URLs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).

Relative references are resolved using the URLs defined in the [Server Object](#server-object) as a Base URI.

Relative references used in `$ref` are processed as per [JSON Reference](https://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03), using the URL of the current document as the base URI. See also the [Reference Object](#reference-object).

The wording above is intended to distinguish between API URLs (which use the Server Object to determine the base URI or the prefix for the URL path template), and OAD URLs (which use the current document's base URI per RFC3986).
However, only `$ref` was mentioned explicitly in versions 3.0.0 through 3.0.3 of this specification, leaving the behavior of the following fields ambiguous: the `operationRef` field of the [Link Object](#link-object), the URI form of the `mapping` field of the [Discriminator Object](#discriminator-object), the `externalValue` field of the [Example Object](#example-object), and the `url` fields of the [External Documentation](#external-documentation-object), [Contact](#contact-object), and [License](#license-object) Objects.
Therefore, which of the above two rules is used for each of these fields is _implementation-defined_, although it is RECOMMENDED to use the `$ref` process for all of them for compatibility with future versions of this specification.

Copy link
Contributor

Choose a reason for hiding this comment

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

How about this slightly more concise wording:

Suggested change
The wording above is intended to distinguish between API URLs (which use the Server Object to determine the base URI or the prefix for the URL path template), and OAD URLs (which use the current document's base URI per RFC3986).
However, only `$ref` was mentioned explicitly in versions 3.0.0 through 3.0.3 of this specification, leaving the behavior of the following fields ambiguous: the `operationRef` field of the [Link Object](#link-object), the URI form of the `mapping` field of the [Discriminator Object](#discriminator-object), the `externalValue` field of the [Example Object](#example-object), and the `url` fields of the [External Documentation](#external-documentation-object), [Contact](#contact-object), and [License](#license-object) Objects.
Therefore, which of the above two rules is used for each of these fields is _implementation-defined_, although it is RECOMMENDED to use the `$ref` process for all of them for compatibility with future versions of this specification.
Resolution of relative references in the `operationRef` field of the [Link Object](#link-object), the URI form of the `mapping` field of the [Discriminator Object](#discriminator-object), the `externalValue` field of the [Example Object](#example-object), and the `url` fields of the [External Documentation](#external-documentation-object), [Contact](#contact-object), and [License](#license-object) Objects is _implementation-defined_. For compatibility with future versions of this specification, It is RECOMMENDED to use the same process as $ref, but MAY instead use the URLs defined in the [Server Object](#server-object) as a Base URI, as either interpretation was possible in previous versions of this specification.

Copy link
Member Author

Choose a reason for hiding this comment

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

@mikekistler I like most of the wording change but want to tweak it a bit further- will update shortly.

Relative references in CommonMark hyperlinks are resolved in their rendered context, which might differ from the context of the API description.

### Schema
Expand Down