Make IHttpProxy public #455
Conversation
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
(Note, not ready for review, but marking as ready to debug a CI issue). |
|
/azp help |
Supported commands
See additional documentation. |
|
/azp where |
|
Commenter does not have sufficient privileges for PR 455 in repo microsoft/reverse-proxy |
|
/azp list |
|
Commenter does not have sufficient privileges for PR 455 in repo microsoft/reverse-proxy |
|
/azp where |
|
No Azure DevOps organizations are setup to build repository microsoft/reverse-proxy using the Azure Pipelines App. |
|
/azp list |
|
No pipelines found for this repository. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Tratcher
force-pushed
the
tratcher/publicproxy
branch
from
bee024b
to
26bf2fa
Compare
|
(Actually ready for review this time 😁 ) |
|
|
||
| ### Error handling | ||
|
|
||
| IHttpProxy catches exceptions and timeouts from the HTTP client, logs them, and converts them to 5xx status codes or aborts the response. The error details, if any, can be accessed from the [IProxyErrorFeature](xref:Microsoft.ReverseProxy.Service.Proxy.IProxyErrorFeature) as shown above. |
There was a problem hiding this comment.
What if I want to manually retry a failed request?
There was a problem hiding this comment.
If the response hasn't already started then that can be done by calling the ProxyAsync again. The normal error handling code sets the status code but does not otherwise start the response. You may also be able to use Polly?
There was a problem hiding this comment.
If I want to retry a failed request, I do need to buffer the request body and rewind it for retry, right?
There was a problem hiding this comment.
Yes, though requests with bodies are not generally considered retriable as you can't tell if the server processed it. E.g. you wouldn't want to double submit a form.
|
|
||
| The http client may be customized, but the above example is recommended for common proxy scenarios. | ||
|
|
||
| Always use HttpMessageInvoker rather than HttpClient, HttpClient buffers responses by default. Buffering breaks streaming scenarios and increases memory usage and latency. |
There was a problem hiding this comment.
We should also point out that response buffering can make handling partial responses easier since the status code and headers of the proxied response can still be modified at that time. This is necessary if you want the proxy to retry a request in this case.
There was a problem hiding this comment.
We decided in triage to block the use of HttpClient for now, so no need to include any endorsements for it. If we want to support response buffering that can also be done as an explicit feature of HttpProxy or as a DelegatingHandler in a way that does not break streaming scenarios.
Co-authored-by: Stephen Halter <halter73@gmail.com>
Fixes #408 Multiple partners have asked to directly access the IHttpProxy to proxy requests since they handle most of the other aspects themselves (discovery, routing, health checks, etc.). Making it public is easy, but there are some things we want to clean up on the signature first. The main change is removing ProxyTelemetryContext from IHttpProxy.ProxyAsync which has a cascading effect down to StreamCopier.
@MihaZupan The metrics removed from StreamCopier are a good example of something we may want to replace with new diagnostics.
An additional change I hadn't anticipated was needing to make many of the transform classes public, only the base classes were public before.