When developing for the web, it is a recommended best practice to always test your application during development with a web server. This is for two primary reasons. By running a web server, you can approximate a production environment similar to how your application will be served to your users. Also, browsers implement a same-origin policy that is different for quasi-protocols like
file://. Many of Dojo’s modules like
dojo/text, Dijit templates, and
dojox/gfx depend on loading files from the same origin.
The same-origin policy
Web browsers use a security model called the same-origin policy that restricts a page’s ability to communicate between different domains. For standard protocols like
http://, the browser defines two URLs with the same scheme, domain, and port as coming from the same origin. However, for quasi-protocols like
file:///, further restrictions are added so that only files that are in the same or children directories are considered part of the same origin. Some elements like
img, and form posts are exempted; but the same-origin policy always applies to the DOM, cookies,
Without the same-origin policy a web page could:
- Request data from any service using credentials from your cookies
- IFRAMEs could interact with the DOM from another IFRAME
- Images could be loaded onto a canvas and sent anywhere
- XHR requests could load HTML from anywhere and masquerade as that domain
Using a HTTP server helps to align your development environment with your production environment. There are lots of great, easy-to-use servers available for development.
Dojo assumes that all of its content comes from the same-origin. Modules like
dojo/i18n that use XHR requests to load JSON or HTML data can easily fail outside of a HTTP server due to cross-origin issues. Using a server when developing web pages will help avoid going awry of the browser’s security model and allow you to test in an environment similar to production.