-
Notifications
You must be signed in to change notification settings - Fork 866
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
Conversation
|
||
## 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()`. |
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 is it GetRequiredProxyFeature? What is required about it?
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.
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. |
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.
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?
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.
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.
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