Globals.ReportServerUrl does not reflect which binding the client used

[SomeTroglodyte]

• I publish a rdl that simply outputs Globals.ReportServerUrl
• I access the report using a https fqdn to a cname - https://reports.mydomain.tld/Reports/
• Output is http://machinename:80/ReportServer
• By design or by chance, this corresponds to the first binding listed in SSRS configuration manager - however, that manager does not allow any control over the order of bindings
• Having any differences in the webservice bindings vs. the portal bindings leads to the service refusing to work, so the conclusion would be that the portal does talk to the webservice using whatever host/protocol the client came in with
• Thus the Globals.ReportServerUrl variable could likely report an address matching the way the user came in originally - if it wanted to

Effect: Due to other configuration weaknesses, drillthrough links parsing that variable stop working with the newest Chromium. Not entirely a fault of the ReportServerUrl variable, but if it were to return protocol and host matching the client's that problem would be circumvented.