-
Notifications
You must be signed in to change notification settings - Fork 839
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
PathPattern transform results in 301 from IIS because it strips trailing slash #2531
Comments
It seems that it's the behavior expected by I can't say I really agree with that... Maybe we should fix that in yarp instead? |
I vote for forwarding it to the YARP developers for analysis-- definitely don't want to break something if that is how it has been operating for a while. My ultimately wish would be to have a flexibility to choose that the forwarding destination to be "Test/" if that is what the implementor needs, and a different way if they need "Test". Right now I'm not sure there is any way to get "Test/" and IIS isn't playing well without the trailing "/". |
Triage:
|
I agree this is buggy, the config clearly calls for the trailing slash. I don't think any of those services are using these transforms so the risk should be minimal. |
Triage: Per @benjaminpetit it is best to fix it in ASP.NET Core -- class |
Describe the bug
If I don't need a PathPattern Transform, YARP passes my request through with a trailing slash and all is well. However, if I insert a PathPattern Transform, even if it is a test transform that shouldn't (if I understand the docs correctly) change anything, YARP strips off the trailing slash, causing IIS to send a 301. Unfortunately, IIS's 301 includes the destination host, and so the browser (chrome v126) starts trying to send packets directly to the destination, which fails.
I googled a lot trying to resolve this, and re-read the docs about config files, routing, and transforms carefully, but never found a solution online. Still, this could quite likely my user error. If so I apologize but maybe the docs could be clarified?
To Reproduce
In the appsettings.json file [this is a release build, not a development build, so not appsettins.development.json]:
Further technical details
NOTE THAT IN THE Proxying to .../lab/requests HTTP/2 ... LINE ABOVE, THERE IS NO TRAILING / AFTER requests
If I comment out the "transforms" line above, everything works. [However in the final I need the transform.] Here's the log:
NOTE THAT IN THE Proxying to .../lab/requests/ HTTP/2 ... LINE ABOVE, THERE is now a TRAILING / AFTER requests
A workaround that works is to insert something like "base-route" below, when I do that, YARP starts including the backslash again:
Log for this is:
Yarp successfully routes the base ../requests/ packets with "base-route" as shown above, and it routes packets to pathes underneath the Requests/ folder using "test-route".
Another worksaround would be to change the "http://protected.debug.website.com/lab/" destination base folder structure to mimic the origination structure, or maybe to manually send a 301 redirection back to the browser for any packets missing the backslash to use the origin https://outwardfacing.debugsite.com host in the 301 (perhaps #1633).
I did try enabling AutoRedirect in HTTPClient (https://www.reddit.com/r/csharp/comments/r0gu1a/yarp_redirecting_instead_of_proxying/) did not completely work, some packets went through OK but some did not.
The text was updated successfully, but these errors were encountered: