-
-
Notifications
You must be signed in to change notification settings - Fork 280
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
[BUG] Server Object field "url" description is inaccurate #274
Comments
Hey @gibson042! Thanks for reporting the bug. I think the problem is actually with the example. It should probably use |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is still relevant, it just lacks a clear path to resolution. |
My suggestions to resolve:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Is there any of you who wants to champion this? 🙂 Or can we consider this issue as |
Can we say that this one is superseded by #547 ? |
Yeah, I should have been clear on #547 that it's actually a proposal to fix this issue. Updating it. Thanks! |
The proposal now moved to RFC 1 stage: #888. Have a look! |
Describe the bug
The AsyncAPI specification says about the Server Object
url
field that it contains a URL and "MAY be relative", but then uses as an example value "development.gigantic-server.com". This is not an (absolute) URL because it lacks a colon-terminated scheme such as "https", but if interpreted as a relative reference then the result will be something like "https://example.com/example-service/asyncapi.json/../development.gigantic-server.com" (specifically because "a relative reference that does not begin with a slash character is termed a relative-path reference" and inherits the authority component and path prefix of its base URI, cf. RFC 3986 section 4.2 and section 5.2.3).To Reproduce
Steps to reproduce the behavior:
url
is a URL and "MAY be relative", but the absence of text allowing it to be a bare host name (or IP address, for that matter) despite the use of an example value that looks like one.Expected behavior
Presumably the intent is to interpret values matching the RFC 1034 section 3.5 preferred name syntax as updated by RFC 1123 section 2.1 (i.e., non-address strings matching the regular expression pattern
^[a-zA-Z0-9]+(-+[a-zA-Z0-9]+)*(\.[a-zA-Z0-9]+(-+[a-zA-Z0-9]+)*)*$
) as the host component of a URL with default scheme and path (e.g., "https://{value}/") and use the relative reference treatment only as a fallback. If so, the description should be updated accordingly.And if there is also a desire to allow not just host names but also IP addresses, that should be documented as well.
Sample document
n/a
Screenshots
n/a
Additional context
n/a
The text was updated successfully, but these errors were encountered: