The Same Origin Policy

Because web browsers run on a user's computer, browser manufacturers craft important security restrictions to prevent malicious coders from doing damage to users' machines. The most important security restriction in the JavaScript paradigm is called the same origin policy, which determines the servers a certain page is allowed to communicate with.

An origin is considered a single domain, such as www.wrox.com, accessed through a single protocol, most often HTTP. The same origin policy states that any page loaded from this origin may access, download, and interact with (using JavaScript) any other resource from the same origin. This is what enables the hidden frame technique to work: both frames load a page from the same origin; thus, they are allowed to communicate using JavaScript. If you try to load a frame with a page from another origin, you will not be able to interact with that page or access any scripting features of it. The intent is to prevent malicious programmers from getting your information out of a legitimate web page.

The same origin policy also affects how XMLHttp works. Using XMLHttp, you cannot access any resource that is not from the same origin as the page running the code. This means that, by default, you cannot use a URL beginning with http:// in the open() method; you can use only absolute or relative URLs from within the same domain. If you need to access a URL located in a different origin, you must create a server-side proxy to handle the communication (see Figure 2-4).

Figure 2-4

Using a server-side proxy, the browser makes a request to the web server. The web server then contacts another web server outside of the domain to request the appropriate information. When your web server receives the response, it is forwarded back to the browser. The result is a seamless transmission of external data. You'll be using server-side proxies later in this book.

Cache Control

Whenever you are dealing with repeat calls to the same page, you should be concerned about browser caching. For those unaware, web browsers tend to cache certain resources to improve the speed with which sites are downloaded and displayed. This can result in a tremendous speed increase on frequently visited web sites, but can also cause problems for pages that change frequently. If you are making several Ajax calls, you need to be aware that caching may cause you problems.

The best way to deal with caching is to include a no-cache header on any data being sent from the server to the browser. This can be done using the Cache-Control header, which should be set up as follows:

Cache-Control: no-cache

This tells the browser not to cache the data coming from the specific URL. Instead, the browser always calls a new version from the server instead of a saved version from its own cache.