-
Notifications
You must be signed in to change notification settings - Fork 838
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
URL Rewriting doesn't work together with Yarp Proxy Forwarding #2532
Comments
Can you enable Debug logs? That should give you a hint as to which/when routing decisions were taken. |
Yes, sure, I tried to enable logging debug entries for the referenced packages. After I found this article: Diagnosing YARP-based proxies I applied to log RewriteMiddleware entries as well as "Forwarder Telemetry" data:
These log entries mean that the request to "https://192.168.102.9:7159/cache/211108_0636182/img/logo.png" was successfully rewritten to "https://192.168.102.9:7159/img/logo.png" but Yarp proxy still tries to forward it via a used fallback rule. Disabling Yarp Proxy fixes url rewriting rule processing. I also noticed that StaticFilesMiddleware ignores to process rewritten "logo.png" request in a case if Yarp proxy is initialized.
If Yarp Proxy is enabled and I request this url - "https://192.168.102.9:7159/img/logo.png" - the response is well - i.e. image is transfered to my browser as needed. I can only say that Yarp Proxy Forwarder prevents rewritten requests to be handled by the proxy host app. |
The more interesting logs here would be from E.g. if I try something similar to your setup:
It would be really useful if you could narrow down your problem to a runnable example we can test. Re: |
I tried this one configuration. "LogLevel": { The log entries below means that something wrong with the Routing after as URL was overridden. https://192.168.102.9:7159/img/logo.png info: Microsoft.AspNetCore.Hosting.Diagnostics[1] https://192.168.102.9:7159/cache/211108_0636182/img/logo.png info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
Yes, sure will try to create a sample soon. |
That sounds like #1712 (comment) |
Here is services initialization on my side:
Here is middlewares initialization:
Actually, w/o registering "app.UseRouting();" after static middleware, requested static resource are not handled at all. I see one important difference between your sample log entries and I posted above:
It means, that my Blazor static SSR app provides just one routing candidate to match instead of 4 in your sample. MihaZupan, please, can you provide any information on what I can further check? |
Implemented a sample to reproduce the describes issue. Please check it here: BlazorAppUrlRewritingTest Blazor app has 2 image html elements defined on a home page.
The first is loaded well, but the second is forwarded to the legacy app url base (https://localhost/) The console log is the same I posted above:
In case if a forward configuration is changed to filter a virtual directory, the overridden request is processed well:
|
Sorry for the delay. I don't think this is a YARP specific issue: The rewrite middleware seems to force a call to the routing middleware immediately if the path changed. So in your case:
I think we should forward this issue to aspnetcore repo? |
Triage: Let's move it to ASP.NET Core repo. |
Describe the bug
I reproduced it with the Blazor static SSR app.
I've been migrating an old ASP.Net WebForms app to Blazor static SSR.
Using Yarp to proxy not migrated page requests to the ASP.Net WebForms app.
Rewritten URLs to the new Blazor static SSR app are trying to be proxied to the old ASP.Net Webforms app.
To Reproduce
Here is an app initialization code I use:
RewriteCachedStaticFilePathRequests - a simple rule to remove the virtual cache folder for the static resource urls:
something like:
https://localhost:7159/cache/211108_0636182/img/logo.png
to
https://localhost:7159/img/logo.png
Forwarding Proxy configuration is:
Url Rewriter doesn't work correct if Yarp proxing is enabled.
It seems that Url is rewritten correct but the Forwarding Proxy still decided to send this rewritten request to the old app.
I figured out that if Match Path is set to: "/{**catch-all}" URL Rewriting doesn't work as expected. Setting it to the "/AppVDir/{**catch-all}" fixes the issue. Really, it works only in the development environment only in this case.
Further technical details
.Net 8, Yarp.ReverseProxy 2.1.0
The text was updated successfully, but these errors were encountered: