'XHR handling behavior between port 443 and non-standard port
UPDATE:
It appears the problem is triggered when port 443 is explicitly specified. If I leave it out, no errors. For example:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Loader Test</title>
<script type="text/javascript" src="https://127.0.0.1/myapp/_vVERSION/dojo/dojo-release-1.16.3/dojo/dojo.js"></script>
<script type="text/javascript">
dojo.registerModulePath("myapp", "https://127.0.0.1/myapp/_vVERSION/myapp");
// The following should create the myapp object/namespace -->
dojo.require("myapp.bootstrap");
myapp.webContext = "https://127.0.0.1/myapp/_vVERSION/";
</script>
</head>
<body>
HELLO WORLD!
</body>
</html>
So, for whatever reason, if :443 is added to the URLs, an error occurs trying to set myapp.webContext.
ORIGINAL POST BELOW:
I am on a project that has a legacy code base that uses the non-AMD Dojo Toolkit method for loading modules. The application runs in Tomcat, and I am testing out running it as an app server behind an Apache httpd reverse proxy (gateway) with SSL and authentication enabled.
When I set the gateway port to a non-standard value (e.g. 4443), everything appears to load and work fine. However, if the gateway port is 443, I get javascript errors that indicate that dojo.require() statements are happening async vs sync, so errors occur in code that tries to reference objects from the required modules.
I have condensed things down to simple test page that recreats the problem (which occurs in Chrome and Firefox):
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Loader Test</title>
<script type="text/javascript" src="https://127.0.0.1:4443/myapp/_vVERSION/dojo/dojo-release-1.16.3/dojo/dojo.js"></script>
<script type="text/javascript">
dojo.registerModulePath("myapp", "https://127.0.0.1:4443/myapp/_vVERSION/myapp");
// The following should create the myapp object/namespace -->
dojo.require("myapp.bootstrap");
myapp.webContext = "https://127.0.0.1:4443/myapp/_vVERSION/";
</script>
</head>
<body>
HELLO WORLD!
</body>
</html>
The above works with no problems. However, if I change Apache httpd configuration to use the standard https port of 443, and change the 4443 to 443 in the above, I get an error when trying to set myapp.webContext. When using the Network profiler in the browser debugger, it shows the request to the myapp.bootstrap as Pending, not loaded yet. If I configure the debugger to not pause on exceptions, the Network tab shows the module eventually gets loaded.
The use of absolute pathnames in the application is to ensure proper loading of resources and link resolution. This was required a long time ago due to problems in IE, and a configuration setting is supported to indicate the base URL for all hrefs (for cases when running behind a gateway).
As a test, I redid the sample to use all relative pathnames, and the page appears to load with no errors when using port 443. Unfortunately, the real application is quite large, so changing it to always use relative pathnames is not a viable solution at this time.
My gut is telling me the browsers are behaving differently with XHR requests that involve standard ports (e.g. 443) and use absolute URLs. Can anyone confirm this? And if so, why they behave that way?
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|