Hosting in and Proxying to IIS

[pinkfloydx33]

I'm having some issues with YARP and IIS and I'm wondering if anyone has run into something like this before, or might be able to advise that this is unsupported.

I'm running the YARP project inside of IIS (via the aspnetcore module). The downstream clusters are also hosted in IIS (one on the same machine, the others elsewhere). According to the logs, proxying itself is working successfully. However in the browser I get intermittent failures with protocol errors, specifically net::ERR_HTTP2_PROTOCOL_ERROR.

When first configuring this setup I was getting similar issues across the board (not intermittently), which seemed to be fixed by disabling dynamic compression on the YARP IIS application. I've tried running in/out of process. I've disabled compression and expanded request limits in IIS and disabled/enabled response buffering in YARP but nothing seems to resolve this.

So far as the logs are concerned, everything is fine which is making this difficult to diagnose. Everything runs flawlessly if we run YARP as a console application instead, which is what has convinced me that IIS-to-IIS is somehow the culprit.

Is there anything special that needs to be done when going IIS-to-IIS?

[Tratcher]

It should just work on IIS though we don't test it much. We have fixed a few bugs in YARP and AspNetCore specific to IIS. What versions of YARP and AspNetCore are you using?

Can you show us any customizations you've added in the proxy such as manipulating the headers or body?

Are you using http or https between YARP and the backends?

[pinkfloydx33]

Latest available YARP (as of Monday anyways) running on NET6.0. Literally no customizations, essentially just the barebones/sample app. The only transform is the preservation of the Original Host Header, as our backend seems to rely on it.

YARP is listening on HTTPS but forwarding to the backends over HTTP (tried https as well with same results).

It works fine when running as a console app, but the second I stick it in IIS we get these issues. The backend is a combination of Asp.Net and classic ASP, the latter of which I suspect may be playing some part in all this as well.

It may be moot as we've explored an alternative hosting model for our scenario (still with YARP) that seems to be working quite well so far. However there's a chance this new configuration may not work out so having IIS as a backup option would be ideal.

[Tratcher]

Ok. Is there any pattern to which requests fail? Check the browser network tools to see individual requests for resources.

[pinkfloydx33]

When it fails, it seems to be two sets of requests: a bunch of POSTs to one page and a GET to a second.

It's odd, if I check "disable cache" in DevTools it's pretty much guaranteed to happen. Though it doesn't happen while redownloading all the chunks of the angular app (which is where I'd have expected it, if anywhere), only afterwards. There must be something special happening on our end during a fresh session that's contributing to the problem.

I need to do some more investigating as I'm not terribly familiar with the internals of our legacy app, but I believe that the failing pages are part of the Classic-Asp portion of our site.

It's tough considering these same endpoints intermittently work fine in IIS but always work when run as console (even with cache disabled). Honestly I'm just hoping our alternative solution pans out as it's not really worth putting in too much effort, especially considering all of this is a temporary solution to help us while we migrate our app to a new server. If the issue is related to classic-asp as I suspect, then I doubt we'd be willing to risk modifying it anyways.

Thanks for your help. I'm going to consider this resolved for now. If I figure anything out I'll report back.

[davidfowl]

If you can reproduce try to capture verbose logs and see if anything suspicious shows up.

[Prasadnair]

We recently attempted to deploy a Web API with YARP, hosting it on two IIS web servers behind a load balancer. Additionally, we have two downstream APIs hosted on separate servers, each behind its own load balancer. Everything works fine when testing the YARP integration through Visual Studio, but it fails after deployment to IIS. We're facing some confusion regarding hosting a YARP-integrated application in IIS.

while executing the command dotnet yarp.dll from command prompt, we are receiving the below error
Hosting failed to start
System.Net.Sockets.SocketException (10013): An attempt was made to access a socket in a way forbidden by its access permissions.
at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportOptions.CreateDefaultBoundListenSocket(EndPoint endpoint)
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.TransportManager.BindAsync(EndPoint endPoint, ConnectionDelegate connectionDelegate, EndpointConfig endpointConfig, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass28_0`1.<g__OnBind|0>d.MoveNext()

Program. cs class has the below lines of code
// YARP Reverse Proxy
builder.Services.AddReverseProxy()
.LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));

//middleware
app.MapReverseProxy();

ReverseProxy settings.

"Kestrel": {
"Endpoints": {
"Https": {
"Url": "https://*:443"
}
}
},
"ReverseProxy": {
"ForwardedHeaders": {
"Enabled": true,
"ForwardLimit": 3
},
"Routes": {
"ssoRoute": {
"ClusterId": "token-api",
"Match": {
"Path": "/externalapi/{plugin}/authenticate/{**remainder}"
},
"Transforms": [
{
"PathPattern": "/internalapi/auth/{**remainder}"
}
]
}
},
"Clusters": {
"token-api": {
"Destinations": {
"token-destination": {
"Address": "https://downstreamURL.com"
}
}
}

 }

}
}

It would be really appreciated if you could provide some suggestions.