Skip to content
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

Middleware docs and helper API cleanup #890

Merged
merged 4 commits into from
Apr 7, 2021
Merged

Middleware docs and helper API cleanup #890

merged 4 commits into from
Apr 7, 2021

Conversation

Tratcher
Copy link
Member

@Tratcher Tratcher commented Apr 5, 2021

Fixes #114 - Docs for customizing functionality through ASP.NET middleware.
Fixes #878 - Testing middleware: Re-implements middleware helpers like GetRequiredCluster to fetch their information from the IReverseProxy feature rather than the endpoint, only DestinationInitializerMiddleware accesses the endpoint directly to create the feature. I've also moved these extensions to the same namespace as HttpContext.

cc: @jmezach

@Tratcher Tratcher self-assigned this Apr 5, 2021
@Tratcher Tratcher added this to the YARP 1.0.0-preview11 milestone Apr 5, 2021

## Custom Proxy Middleware

Middlware inside the `MapReverseProxy` pipeline have access to all of the proxy data and state associated with a request (the route, cluster, destinations, etc.) through the [IReverseProxyFeature](xref:Yarp.ReverseProxy.Middleware.IReverseProxyFeature). This is available from `HttpContext.Features` or the extension method `HttpContext.GetRequiredProxyFeature()`.
Copy link
Member

Choose a reason for hiding this comment

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

why is it GetRequiredProxyFeature? What is required about it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Required in this case means if will throw if the feature is missing. It saves having to do null checks afterwards.


Middleware should avoid interacting with the request or response bodies. Bodies are not buffered by default, so interacting with them can prevent them from reaching their destinations. While enabling buffering is possible, it's discouraged as it can add significant memory and latency overhead. Using a wrapped, streaming approach is recommended if the body must be examined or modified. See the [ResponseCompression](https://github.com/dotnet/aspnetcore/blob/24588220006bc164b63293129cc94ac6292250e4/src/Middleware/ResponseCompression/src/ResponseCompressionMiddleware.cs#L55-L73) middleware for an example.

Middleware MUST NOT do any multi-threaded work on an individual request, `HttpContext` and its associated members are not thread safe.
Copy link
Member

Choose a reason for hiding this comment

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

is thread safe the correct term? I wonder if this should say to use async, and only to access the context from the thread the async scheduler has assigned for that unit of work?

Copy link
Member Author

Choose a reason for hiding this comment

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

Thread safe is the lower level concern here. Sync or async, you can still only have one thread at a time working with the HttpContext.

@Tratcher Tratcher merged commit a1730a8 into main Apr 7, 2021
@Tratcher Tratcher deleted the tratcher/middoc branch April 7, 2021 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unit testing with GetRequiredCluster() Proxy can be customized with middleware to enable advanced scenarios
2 participants