When the "CombineScriptsHandler" is registed in the "web.config", and enabled via setting the "CombineScripts" to true on the "ToolkitScriptManager", the handler appears to be getting registered with the full website URL (see attachment) instead of using a relative path like the ones used by "ScriptResource.axd" and "WebResource.axd".
This seems to be causing issues when making use of SSL over a non-standard port (ie. multiple site Windows Azure development server) as the port appears to be getting dropped from the absolute URL.
The handler should work similar to how "ScriptResource.axd" and "WebResource.axd" do in regards to registering itself on the page in order to prevent JavaScript errors due to the combined script not being found due to invalid path.
Comments: This is a big headache because our site sits behind a load balancer and the protocol used by the server does not match what is used by the client via the load balancer. We have HTTP on the IIS server, but client accesses via HTTPS through the load balancer.
This seems to be causing issues when making use of SSL over a non-standard port (ie. multiple site Windows Azure development server) as the port appears to be getting dropped from the absolute URL.
The handler should work similar to how "ScriptResource.axd" and "WebResource.axd" do in regards to registering itself on the page in order to prevent JavaScript errors due to the combined script not being found due to invalid path.
Comments: This is a big headache because our site sits behind a load balancer and the protocol used by the server does not match what is used by the client via the load balancer. We have HTTP on the IIS server, but client accesses via HTTPS through the load balancer.