-
Notifications
You must be signed in to change notification settings - Fork 270
Description
In ASP.NET Core, there are two types named HttpValidationProblemDetails
and HttpProblemDetails
that developers can use to return the responses that comply with the ProblemDetails RFC.
The type names are used as the schema IDs in the default implementation of our OpenAPI generation.
This presents an issue with the current logic of the ReferenceV3
property which has a special case around IDs that start with HTTP.
OpenAPI.NET/src/Microsoft.OpenApi/Models/OpenApiReference.cs
Lines 77 to 107 in a457935
public string ReferenceV3 | |
{ | |
get | |
{ | |
if (IsExternal) | |
{ | |
return GetExternalReferenceV3(); | |
} | |
if (!Type.HasValue) | |
{ | |
throw new ArgumentNullException(nameof(Type)); | |
} | |
if (Type == ReferenceType.Tag) | |
{ | |
return Id; | |
} | |
if (Type == ReferenceType.SecurityScheme) | |
{ | |
return Id; | |
} | |
if (Id.StartsWith("http", StringComparison.OrdinalIgnoreCase)) | |
{ | |
return Id; | |
} | |
return "#/components/" + Type.Value.GetDisplayName() + "/" + Id; | |
} | |
} |
The end result being that schema references for these types do not get generated correctly.
We should switch to a more resilient URL check for this case to avoid mishandling schema IDs that are intentionally beginning with Http.
cc: @mikekistler the distinguished bug finder