weixin_39954908
weixin_39954908
2020-12-09 02:15

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.

该提问来源于开源项目:microsoft/service-fabric-aspnetcore

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

5条回答

  • weixin_39954908 weixin_39954908 5月前

    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.

    点赞 评论 复制链接分享
  • weixin_39757212 weixin_39757212 5月前

    Thanks I will close this issue then.

    点赞 评论 复制链接分享
  • weixin_39954908 weixin_39954908 5月前

    I wasn't really quite done.... Sorry about that. The whole "in most cases" thing needed to be expanded upon.

    UseReverseProxyIntegration strips 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.

    Adding in UseUniqueServiceUrl will 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.

    点赞 评论 复制链接分享
  • weixin_39757212 weixin_39757212 5月前

    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.

    点赞 评论 复制链接分享
  • weixin_39757212 weixin_39757212 5月前

    Thanks . Sure, lets track on the new issue which you opened a little while ago, closing this one.

    点赞 评论 复制链接分享

相关推荐