So after some more thinking, I think the default behavior of leaving PathBase blank is fine... in most cases, when you intend to put the SF reverse proxy behind yet another load balancer which itself has no prefix. But if you want to use the reverse proxy itself directly, then it doesn't quite work.
PathBase not updated
yield return new ServiceInstanceListener(serviceContext => new KestrelCommunicationListener( serviceContext, (url, listener) => new WebHostBuilder() .UseKestrel() .ConfigureServices(services => services.AddTransient(provider => scope.Resolve<webstartup>())) .UseContentRoot(Directory.GetCurrentDirectory()) .UseStartup<webstartup>() .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseReverseProxyIntegration) .Build())); </webstartup></webstartup>
I would expect UseServiceFabricIntegration (and the eventual ServiceFabricReverseProxyMiddleware it inserts) to set up PathBase correctly. However, its always empty. So, path ends up being /foo/bar.... and components end up referring to the incorrect path.
- weixin_39954908 5月前点赞 评论 复制链接分享
Thanks I will close this issue then.点赞 评论 复制链接分享
- weixin_39954908 5月前
I wasn't really quite done.... Sorry about that. The whole "in most cases" thing needed to be expanded upon.
UseReverseProxyIntegrationstrips out the /AppName/SvcName components of the path just fine. But, it doesn't make them available from that point on. So, when further steps try to compose a URL, they end up directing to the wrong place.
UseUniqueServiceUrlwill then add a new PathBase: with /partitionId/replicaId.
But there's no combination that seems to preserve /AppName/SvcName, for both reverse proxy and unique service urls for stateless single instance services.
The "it works in most cases" would mean using the reverse proxy, behind a load balancer, where each service is getting it's own root URL anyways.
I'll add a new issue, since I now have a more specific ask.点赞 评论 复制链接分享
UseReverseProxyIntegration doesn't strip out /AppName/SvcName, it would be done by the ReverseProxy so by the time call comes to these middlewares, the path will not have it. All this ReverseProxy middleware does is adds a specific header to response for 4o4 from the service.
example: lets say a service with name fabric:/MyApp/MyService is deployed, it has a route called api/values With UseUniqueServiceUrl, url for the endoiint reported to SF runtime is ( http://machinename:port/partitionId/repilcaId/guid
To call it directly, client will resolve the service partition and send the request as http://machinename:port/partitionId/repilcaId/guid/api/values which would come to the ServiceFabricMiddleware and after adjusting the path and pathbase, call will end up at /api/values route.
To call it with ReverseProxy, call will be made as: http://:Port/MyApp/MyService/api/values?PartitionKey=&PartitionKind= ReverseProxy (not the ReverseProxyMiddleware) will resolve the service for the specified partition and send the request to http://machinename:port/partitionId/repilcaId/guid/api/values which would come to the ServiceFabricMiddleware and after adjusting the path and pathbase, call will end up at /api/values route
So it doesn't seem like an issue, I hope that answers your question.点赞 评论 复制链接分享
Thanks . Sure, lets track on the new issue which you opened a little while ago, closing this one.点赞 评论 复制链接分享