-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Cleanup Results helper #34296
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
Cleanup Results helper #34296
Conversation
pranavkm
commented
Jul 12, 2021
- Add Results.Bytes, Results.Stream, and Results.Text overloads.
- Consolidate Physical and Virtual files helpers.
- Use default arguments to consolidate overloads.
- Remove Accepted(Uri?) / Accepted(Uri?, object? value) overload to remove ambiguity with AcceptedAt(string?, object? value);
* Add Results.Bytes, Results.Stream, and Results.Text overloads. * Consolidate Physical and Virtual files helpers. * Use default arguments to consolidate overloads. * Remove Accepted(Uri?) / Accepted(Uri?, object? value) overload to remove ambiguity with AcceptedAt(string?, object? value);
static Microsoft.AspNetCore.Http.Results.AcceptedAtRoute(string? routeName) -> Microsoft.AspNetCore.Http.IResult! | ||
static Microsoft.AspNetCore.Http.Results.AcceptedAtRoute(string? routeName, object? routeValues) -> Microsoft.AspNetCore.Http.IResult! | ||
static Microsoft.AspNetCore.Http.Results.AcceptedAtRoute(string? routeName, object? routeValues, object? value) -> Microsoft.AspNetCore.Http.IResult! | ||
static Microsoft.AspNetCore.Http.Results.Accepted(string? uri = null, object? value = null) -> Microsoft.AspNetCore.Http.IResult! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about Accepted(System.Uri! uri)? Are we saying just use Uri.ToString()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally like less overloads for now. If people really want this, we can add the overload later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They can call ToString 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uri.AbsoulteUri, never use ToString
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current code does AbsoluteUri and other strange things for non-absolute uris: https://github.com/dotnet/aspnetcore/blob/main/src/Mvc/Mvc.Core/src/AcceptedResult.cs#L56-L63. But yeah, people could just write that code.
static Microsoft.AspNetCore.Http.Results.Content(string! content, string! contentType) -> Microsoft.AspNetCore.Http.IResult! | ||
static Microsoft.AspNetCore.Http.Results.Content(string! content, string! contentType, System.Text.Encoding! contentEncoding) -> Microsoft.AspNetCore.Http.IResult! | ||
static Microsoft.AspNetCore.Http.Results.Content(string! content, Microsoft.Net.Http.Headers.MediaTypeHeaderValue! contentType) -> Microsoft.AspNetCore.Http.IResult! | ||
static Microsoft.AspNetCore.Http.Results.Content(string! content, string? contentType = null, System.Text.Encoding? contentEncoding = null) -> Microsoft.AspNetCore.Http.IResult! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we feel about just keeping Text and removing the Content overloads?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly, I don't have a strong sense for how commonly this result type is used. That said, the reasons to keep it would be compat with MVC (portability / muscle memory) which might be enough of a tipping point.
|
||
/// <summary> | ||
/// Writes the <paramref name="content"/> string to the HTTP response. | ||
/// <para> | ||
/// This is an alias for <see cref="Text(string, string?, Encoding?)"/>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were going to ignore precedence and only have Text/Stream?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When tests pass.
return new ContentResult | ||
{ | ||
Content = content, | ||
ContentType = mediaTypeHeaderValue?.ToString() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we ToString after Parsing? Validation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We kinda only want the string representation to set the response header. The parsing allows us to overwrite any existing encoding with the value specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should
UnprocessableEntity
/Ok
/NotFound
etc should haven one overload? Seems like you still have 2 method each here. - Are Forbid/SignIn/SignOut usable with optional parameters and param arrays?
- Do we need a status code option for Text/Bytes/Stream?
- Should
Bytes
beMemory<byte>
instead ofbyte[]
? - Should content type be optional and assume application/octet-stream for
Bytes
/Stream/File
? - I think we need an overload of Stream that gives you access to the underlying response body. This is the old PushStreamContent from WebAPI. The scenario that comes up alot in MVC controllers is proxying a download from a blob backend. In these scenarios you want to use one of [these APIs](https://docs.microsoft.com/en-us/dotnet/api/azure.storage.blobs.specialized.blobbaseclient.downloadtoasync?view=azure-dotnet#azure-storage-blobs-specialized-blobbaseclient-downloadtoasync(system-io-stream-system-threading-can) that lets you download the blob to a Stream. The scenario is that you have a thing that's not a Stream itself but it can has a method to copy to a Stream.
app.MapGet("/blob", (BlobServiceClient client) =>
{
BlobClient blob = client.GetBlobContainerClient("container").GetBlobClient("blob");
return Results.Stream((stream, cancellationToken) => blob.DownloadToAsync(stream, cancellationToken), fileDownloadName: fileName));
});
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
@@ -55,6 +54,10 @@ public Task ExecuteAsync(HttpContext httpContext) | |||
} | |||
|
|||
OnFormatting(httpContext); | |||
if (Value is null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this go earlier?
{ | ||
var logger = httpContext.RequestServices.GetRequiredService<ILogger<FileStreamResult>>(); | ||
using (FileStream) | ||
await using (FileStream) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah hah! That was the bug!
I don't think so. I think 200 responses are the 99% case, and you can manually set the status on the HttpResponse if you want to |
I don't get why this PR is making the blazor wasm tests fail:
|
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
Seems like it was this #34317 |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |