http://help.dottoro.com/ljqlhagh.php

에서 참조

Creates an XML document object.

Note: The createDocument method is supported in Internet Explorer from version 9, but it creates an HTML document, not an XML document.

Syntax:

object.createDocument (namespaceURI, qualifiedName, docTypeObj);

You can find the related objects in the Supported by objects section below.

Parameters:

namespaceURI Required. String that specifies the namespace URI for the documentElement (root node). qualifiedName Required. String that specifies the name of the documentElement (root node). If an empty string is specified, the new XML document will have no root node. docTypeObj Required. Reference to a doctype object that specifies the document type of the XML document. Use the createDocumentType method to create a doctype object. Set to null if no document type is needed.

Return value:

Returns the newly created XMLDocument object.

http://help.dottoro.com/ljqlhagh.php

에서 참조

Creates an XML document object.

Note: The createDocument method is supported in Internet Explorer from version 9, but it creates an HTML document, not an XML document.

Syntax:

object.createDocument (namespaceURI, qualifiedName, docTypeObj);

You can find the related objects in the Supported by objects section below.

Parameters:

namespaceURI Required. String that specifies the namespace URI for the documentElement (root node). qualifiedName Required. String that specifies the name of the documentElement (root node). If an empty string is specified, the new XML document will have no root node. docTypeObj Required. Reference to a doctype object that specifies the document type of the XML document. Use the createDocumentType method to create a doctype object. Set to null if no document type is needed.

Return value:

Returns the newly created XMLDocument object.

Understanding callback functions in Javascript

Callback functions are extremely important in Javascript. They’re pretty much everywhere. Originally coming from a more traditional C/Java background I had trouble with this (and the whole idea of asynchronous programming), but I’m starting to get the hang of it. Strangely, I haven’t found any good introductions to callback functions online — I mainly found bits of documentation on the call() and apply() functions, or brief code snippits demonstrating their use — so, after learning the hard way I decided to try to write a simple introduction to callbacks myself.

Functions are objects

To understand callback functions you first have to understand regular functions. This might seen like a “duh” thing to say, but functions in Javascript are a bit odd.

Functions in Javascript are actually objects. Specifically, they’re Function objects created with the Function constructor. A Function object contains a string which contains the Javascript code of the function. If you’re coming from a language like C or Java that might seem strange (how can code be a string?!) but it’s actually run-of-the-mill for Javascript. The distinction between code and data is sometimes blurred.

1 // you can create a function by passing the
2 // Function constructor a string of code
3 var func_multiply = new Function("arg1", "arg2", "return arg1 * arg2;");
4 func_multiply(5,10); // => 50

One benefit of this function-as-object concept is that you can pass code to another function in the same way you would pass a regular variable or object (because the code is literally just an object).

Passing a function as a callback

Passing a function as an argument is easy.

01 // define our function with the callback argument
02 function some_function(arg1, arg2, callback) {
03     // this generates a random number between
04     // arg1 and arg2
05     var my_number = Math.ceil(Math.random() *
06         (arg1 - arg2) + arg2);
07     // then we're done, so we'll call the callback and
08     // pass our result
09     callback(my_number);
10 }
11 // call the function
12 some_function(5, 15, function(num) {
13     // this anonymous function will run when the
14     // callback is called
15     console.log("callback called! " + num);
16 });

It might seem silly to go through all that trouble when the value could just be returned normally, but there are situations where that’s impractical and callbacks are necessary.

Don’t block the way

Traditionally functions work by taking input in the form of arguments and returning a value using a return statement (ideally a single return statement at the end of the function: one entry point and one exit point). This makes sense. Functions are essentially mappings between input and output.

Javascript gives us an option to do things a bit differently. Rather than wait around for a function to finish by returning a value, we can use callbacks to do it asynchronously. This is useful for things that take a while to finish, like making an AJAX request, because we aren’t holding up the browser. We can keep on doing other things while waiting for the callback to be called. In fact, very often we are required (or, rather, strongly encouraged) to do things asynchronously in Javascript.

Here’s a more comprehensive example that uses AJAX to load an XML file, and uses the call() function to call a callback function in the context of the requested object (meaning that when we call the this keyword inside the callback function it will refer to the requested object):

01 function some_function2(url, callback) {
02     var httpRequest; // create our XMLHttpRequest object
03     if (window.XMLHttpRequest) {
04         httpRequest = new XMLHttpRequest();
05     } else if (window.ActiveXObject) {
06         // Internet Explorer is stupid
07         httpRequest = new
08             ActiveXObject("Microsoft.XMLHTTP");
09     }
10   
11     httpRequest.onreadystatechange = function() {
12         // inline function to check the status
13         // of our request
14         // this is called on every state change
15         if (httpRequest.readyState === 4 &&
16                 httpRequest.status === 200) {
17             callback.call(httpRequest.responseXML);
18             // call the callback function
19         }
20     };
21     httpRequest.open('GET', url);
22     httpRequest.send();
23 }
24 // call the function
25 some_function2("text.xml", function() {
26     console.log(this);
27 });
28 console.log("this will run before the above callback");

In this example we create the httpRequest object and load an XML file. The typical paradigm of returning a value at the bottom of the function no longer works here. Our request is handled asynchronously, meaning that we start the request and tell it to call our function when it finishes.

We’re using two anonymous functions here. It’s important to remember that we could just as easily be using named functions, but for sake of brevity they’re just written inline. The first anonymous function is run every time there’s a state change in our httpRequest object. We ignore it until the state is 4 (meaning it’s done) and the status is 200 (meaning it was successful). In the real world you’d want to check if the request failed, but we’re assuming the file exists and can be loaded by the browser. This anonymous function is assigned to httpRequest.onreadystatechange, so it is not run right away but rather called every time there’s a state change in our request.

When we finally finish our AJAX request, we not only run the callback function but we use the call() function. This is a different way of calling a callback function. The method we used before of just running the function would work fine here, but I thought it would be worth demonstrating the use of the call() function. Alternatively you could use the apply() function (the difference between the two is beyond the scope of this tutorial, but it involves how you pass arguments to the function).

The neat thing about using call() is that we set the context in which the function is executed. This means that when we use the this keyword inside our callback function it refers to whatever we passed as the first argument for call(). In this case, when we refer to this inside our anonymous callback function we are referring to the responseXML from the AJAX request.

Finally, the second console.log statement will run before the first, because the callback isn’t executed until the request is over, and until that happens the rest of the code goes right on ahead and keeps running.

Wrapping it up

Hopefully now you should understand callbacks well enough to use them in your own code. I still find it hard to structure code that is based around callbacks (it ends up looking like spaghetti… my mind is too accustomed to regular structured programming), but they’re a very powerful tool and one of the most interesting parts of the Javascript language.

Understanding callback functions in Javascript

Callback functions are extremely important in Javascript. They’re pretty much everywhere. Originally coming from a more traditional C/Java background I had trouble with this (and the whole idea of asynchronous programming), but I’m starting to get the hang of it. Strangely, I haven’t found any good introductions to callback functions online — I mainly found bits of documentation on the call() and apply() functions, or brief code snippits demonstrating their use — so, after learning the hard way I decided to try to write a simple introduction to callbacks myself.

Functions are objects

To understand callback functions you first have to understand regular functions. This might seen like a “duh” thing to say, but functions in Javascript are a bit odd.

Functions in Javascript are actually objects. Specifically, they’re Function objects created with the Function constructor. A Function object contains a string which contains the Javascript code of the function. If you’re coming from a language like C or Java that might seem strange (how can code be a string?!) but it’s actually run-of-the-mill for Javascript. The distinction between code and data is sometimes blurred.

1 // you can create a function by passing the
2 // Function constructor a string of code
3 var func_multiply = new Function("arg1", "arg2", "return arg1 * arg2;");
4 func_multiply(5,10); // => 50

One benefit of this function-as-object concept is that you can pass code to another function in the same way you would pass a regular variable or object (because the code is literally just an object).

Passing a function as a callback

Passing a function as an argument is easy.

01 // define our function with the callback argument
02 function some_function(arg1, arg2, callback) {
03     // this generates a random number between
04     // arg1 and arg2
05     var my_number = Math.ceil(Math.random() *
06         (arg1 - arg2) + arg2);
07     // then we're done, so we'll call the callback and
08     // pass our result
09     callback(my_number);
10 }
11 // call the function
12 some_function(5, 15, function(num) {
13     // this anonymous function will run when the
14     // callback is called
15     console.log("callback called! " + num);
16 });

It might seem silly to go through all that trouble when the value could just be returned normally, but there are situations where that’s impractical and callbacks are necessary.

Don’t block the way

Traditionally functions work by taking input in the form of arguments and returning a value using a return statement (ideally a single return statement at the end of the function: one entry point and one exit point). This makes sense. Functions are essentially mappings between input and output.

Javascript gives us an option to do things a bit differently. Rather than wait around for a function to finish by returning a value, we can use callbacks to do it asynchronously. This is useful for things that take a while to finish, like making an AJAX request, because we aren’t holding up the browser. We can keep on doing other things while waiting for the callback to be called. In fact, very often we are required (or, rather, strongly encouraged) to do things asynchronously in Javascript.

Here’s a more comprehensive example that uses AJAX to load an XML file, and uses the call() function to call a callback function in the context of the requested object (meaning that when we call the this keyword inside the callback function it will refer to the requested object):

01 function some_function2(url, callback) {
02     var httpRequest; // create our XMLHttpRequest object
03     if (window.XMLHttpRequest) {
04         httpRequest = new XMLHttpRequest();
05     } else if (window.ActiveXObject) {
06         // Internet Explorer is stupid
07         httpRequest = new
08             ActiveXObject("Microsoft.XMLHTTP");
09     }
10   
11     httpRequest.onreadystatechange = function() {
12         // inline function to check the status
13         // of our request
14         // this is called on every state change
15         if (httpRequest.readyState === 4 &&
16                 httpRequest.status === 200) {
17             callback.call(httpRequest.responseXML);
18             // call the callback function
19         }
20     };
21     httpRequest.open('GET', url);
22     httpRequest.send();
23 }
24 // call the function
25 some_function2("text.xml", function() {
26     console.log(this);
27 });
28 console.log("this will run before the above callback");

In this example we create the httpRequest object and load an XML file. The typical paradigm of returning a value at the bottom of the function no longer works here. Our request is handled asynchronously, meaning that we start the request and tell it to call our function when it finishes.

We’re using two anonymous functions here. It’s important to remember that we could just as easily be using named functions, but for sake of brevity they’re just written inline. The first anonymous function is run every time there’s a state change in our httpRequest object. We ignore it until the state is 4 (meaning it’s done) and the status is 200 (meaning it was successful). In the real world you’d want to check if the request failed, but we’re assuming the file exists and can be loaded by the browser. This anonymous function is assigned to httpRequest.onreadystatechange, so it is not run right away but rather called every time there’s a state change in our request.

When we finally finish our AJAX request, we not only run the callback function but we use the call() function. This is a different way of calling a callback function. The method we used before of just running the function would work fine here, but I thought it would be worth demonstrating the use of the call() function. Alternatively you could use the apply() function (the difference between the two is beyond the scope of this tutorial, but it involves how you pass arguments to the function).

The neat thing about using call() is that we set the context in which the function is executed. This means that when we use the this keyword inside our callback function it refers to whatever we passed as the first argument for call(). In this case, when we refer to this inside our anonymous callback function we are referring to the responseXML from the AJAX request.

Finally, the second console.log statement will run before the first, because the callback isn’t executed until the request is over, and until that happens the rest of the code goes right on ahead and keeps running.

Wrapping it up

Hopefully now you should understand callbacks well enough to use them in your own code. I still find it hard to structure code that is based around callbacks (it ends up looking like spaghetti… my mind is too accustomed to regular structured programming), but they’re a very powerful tool and one of the most interesting parts of the Javascript language.

https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest/Using_XMLHttpRequest

에서 참조

XMLHttpRequest makes sending HTTP requests very easy.  You simply create an instance of the object, open a URL, and send the request.  The HTTP status of the result, as well as the result’s contents, are available in the request object when the transaction is completed. This page outlines some of the common and even slightly obscure use cases for this powerful JavaScript object.

Types of requests

A request made via XMLHttpRequest can fetch the data in one of two ways, asynchronously or synchronously. The type of request is dictated by the optional async property that is set on the XMLHttpRequest .open() method. If this property is set to false, then the XMLHttpRequest will be processed synchronously, otherwise the process will be done asynchronously. A detailed discussion and demonstrations of these two types of requests can be found on the synchronous and asynchronous requests page.

Handling responses

There are several types of response attributes defined by the W3C specification for XMLHttpRequest.  These tell the client making the XMLHttpRequest important information about the status of the response. For many use cases this is as straightforward as the following example:

1
2
3
4
5
6
7
8
var request = new XMLHttpRequest();
request.open('GET', 'http://www.mozilla.org', false);
request.send(); // because of "false" above, will block until the request is done 
                // and status is available. Not recommended, however it works for simple cases.
  
if (request.status === 200) {
  console.log(request.responseText);
}

There are some situations where the contents of a remote response from an XMLHttpRequest may not be handled as easily as the case above. A few of these cases where dealing with reponseXML and responseText involves some manipulation and analysis are outlined in the following sections.

Analyzing and manipulating the responseXML property

If you use XMLHttpRequest to get the content of a remote XML document, the responseXML property will be a DOM Object containing a parsed XML document, which can be hard to manipulate and analyze. There are four primary ways of analyzing this XML document:

  1. Using XPath to address (point to) parts of it.
  2. Using JXON to convert it into a JavaScript Object tree.
  3. Manually Parsing and serializing XML to strings or objects.
  4. Using XMLSerializer to serialize DOM trees to strings or to files.
  5. RegExp can be used if you always know the content of the XML document beforehand. You might want to remove line breaks, if you use RegExp to scan with regard to linebreaks. However, this method is a “last resort” since if the XML code changes slightly, the method will likely fail.

Analyzing and manipulating a responseText property containing an HTML document

Note: The W3C XMLHttpRequest specification has added HTML parsing support to XMLHttpRequest, which originally supported only XML parsing. This feature allows Web apps to obtain an HTML resource as a parsed DOM using XMLHttpRequest.responseXML property. Read the article about HTML in XMLHttpRequest for details.

If you use XMLHttpRequest to get the content of a remote HTML webpage, the responseText property is a string containing a “soup” of all the HTML tags, which can be hard to manipulate and analyze. There are three primary ways of analyzing this HTML soup string:

  1. Safely parsing with nsIScriptableUnescapeHTML will quickly convert the HTML string into DOM, while stripping out JavaScript and other advanced elements, including the <head> of the webpage.
  2. RegExp can be used if you always know the content of the HTML responseText beforehand. You might want to remove line breaks, if you use RegExp to scan with regard to linebreaks. However, this method is a “last resort” since if the HTML code changes slightly, the method will likely fail.
  3. Using a hidden chrome or content-level iframe to load up the webpage can also be done to then manipulate it as DOM, however there are security risks to giving remote code this level of privileged access, which can cause issues for the review of your addon. For example, if a webpage executes the common “document.location = redirecttothispage.html” command on load, this will get interpreted as changing the browser chrome location (document.location in an extension) as opposed to the webpage location (content.document.location in an extension), thus destroying all browser components. Alternatively, and somewhat safer, a responseText string attained through a XMLHttpRequest can be analyzed using RegExp to remove potential JavaScript problems, then loaded into the hidden iframe that you have set up:
document.getElementById("hiddenXULiframe").contentWindow.document.body.innerHTML = req.responseText

Using FormData objects

The FormData object lets you compile a set of key/value pairs to send using XMLHttpRequest. Its primarily intended for use in sending form data, but can be used independently from forms in order to transmit keyed data. The transmitted data is in the same format that the form’s submit() method would use to send the data if the form’s encoding type were set to “multipart/form-data”. FormData objects can be utilized in a number of ways with an XMLHttpRequest. For examples and explanations of how one can utilize FormData with XMLHttpRequests see the Using FormData Objects page.

Handling binary data

Although XMLHttpRequest is most commonly used to send and receive textual data, it can be used to send and receive binary content. There are several well tested methods for coercing the response of an XMLHttpRequest into sending binary data. These involve utilizing the .overrideMimeType() method on the XMLHttpRequest object and is a workable solution.

1
2
3
4
5
var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
// retrieve data unprocessed as a binary string
xhr.overrideMimeType("text/plain; charset=x-user-defined");
/* ... */

The XMLHttpRequest Level 2 Specification adds new responseType attributes which make sending and receiving binary data much easier.

1
2
3
4
5
6
7
8
var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
xhr.responseType = "arraybuffer"
xhr.onload = function(e) {
  var arraybuffer = xhr.response; // not responseText
  /* ... */
}
xhr.send();

For more examples check out the Sending and Receiving Binary Data page

Monitoring progress

XMLHttpRequest provides the ability to listen to various events that can occur while the request is being processed. This includes periodic progress notifications, error notifications, and so forth.

Support for DOM progress event monitoring of XMLHttpRequest transfers follows the Web API specification for progress events.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
var req = new XMLHttpRequest();
  
req.addEventListener("progress", updateProgress, false);
req.addEventListener("load", transferComplete, false);
req.addEventListener("error", transferFailed, false);
req.addEventListener("abort", transferCanceled, false);
  
req.open();
  
...
  
// progress on transfers from the server to the client (downloads)
function updateProgress(evt) {
  if (evt.lengthComputable) {
    var percentComplete = evt.loaded / evt.total;
    ...
  } else {
    // Unable to compute progress information since the total size is unknown
  }
}
  
function transferComplete(evt) {
  alert("The transfer is complete.");
}
  
function transferFailed(evt) {
  alert("An error occurred while transferring the file.");
}
  
function transferCanceled(evt) {
  alert("The transfer has been canceled by the user.");
}

Lines 3-6 add event listeners for the various events that are sent while performing a data transfer using XMLHttpRequest

Note: You need to add the event listeners before calling open() on the request.  Otherwise the progress events will not fire.

The progress event handler, specified by the updateProgress() function in this example, receives the total number of bytes to transfer as well as the number of bytes transferred so far in the event’s total and loaded fields.  However, if the lengthComputable field is false, the total length is not known and will be zero.

Progress events exist for both download and upload transfers. The download events are fired on the XMLHttpRequest object itself, as shown in the above sample. The upload events are fired on the XMLHttpRequest.upload object, as shown below:

1
2
3
4
5
6
7
8
var req = new XMLHttpRequest();
  
req.upload.addEventListener("progress", updateProgress, false);
req.upload.addEventListener("load", transferComplete, false);
req.upload.addEventListener("error", transferFailed, false);
req.upload.addEventListener("abort", transferCanceled, false);
  
req.open();
Note: Progress events are not available for the file: protocol.
Gecko 9.0 note

(Firefox 9.0 / Thunderbird 9.0 / SeaMonkey 2.6)

Starting in Gecko 9.0 (Firefox 9.0 / Thunderbird 9.0 / SeaMonkey 2.6), progress events can now be relied upon to come in for every chunk of data received, including the last chunk in cases in which the last packet is received and the connection closed before the progress event is fired. In this case, the progress event is automatically fired when the load event occurs for that packet. This lets you now reliably monitor progress by only watching the “progress” event.

Gecko 12.0 note

(Firefox 12.0 / Thunderbird 12.0 / SeaMonkey 2.9)

If your progress event is called with a responseType of “moz-blob”, the value of response is a Blob containing the data received so far.

One can also detect all three load-ending conditions (abort, load, or error) using the loadend event:

1
2
3
4
5
req.addEventListener("loadend", loadEnd, false);
  
function loadEnd(evt) {
  alert("The transfer finished (although we don't know if it succeeded or not).");
}

Note that there’s no way to be certain from the information received by the loadend event as to which condition caused the operation to terminate; however, you can use this to handle tasks that need to be performed in all end-of-transfer scenarios.

Cross-site XMLHttpRequest

Modern browsers support cross-site requests by implementing the web applications working group’s Access Control for Cross-Site Requests standard.  As long as the server is configured to allow requests from your web application’s origin, XMLHttpRequest will work.  Otherwise, an INVALID_ACCESS_ERR exception is thrown.

Bypassing the cache

Normally, XMLHttpRequest tries to retrieve content from the cache, if it’s available.  To bypass this, do the following:

1
2
3
4
var req = new XMLHttpRequest();
req.open('GET', url, false);
req.channel.loadFlags |= Components.interfaces.nsIRequest.LOAD_BYPASS_CACHE;
req.send(null);
Note: This approach will only work in Gecko-based software, as the channel attribute is Gecko-specific.

An alternate, cross-browser compatible approach is to append a timestamp to the URL, being sure to include a “?" or ”&“ as appropriate.  For example:

http://foo.com/bar.html

becomes

http://foo.com/bar.html?12345

and

http://foo.com/bar.html?foobar=baz

becomes

http://foo.com/bar.html?foobar=baz&12345

Since the local cache is indexed by URL, this causes every request to be unique, thereby bypassing the cache.

You can automatically adjust URLs using the following code:

1
2
3
var req = new XMLHttpRequest();
req.open("GET", url += ((/?/).test(url) ? "&" : "?") + (new Date()).getTime(), false);
req.send(null); 

Security

Firefox 3 note

Versions of Firefox prior to Firefox 3 allowed you to set the preference capability.policy.<policyname>.XMLHttpRequest.open</policyname> to allAccess to give specific sites cross-site access.  This is no longer supported.

Firefox 5 note

Versions of Firefox prior to Firefox 5 could use netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); to request cross-site access. This is no longer supported, even though it produces no warning and permission dialog is still presented.

The recommended way to enable cross-site scripting is to use the Access-Control-Allow-Origin HTTP header in the response to the XMLHttpRequest.

XMLHttpRequests being stopped

If you end up with an XMLHttpRequest having status=0 and statusText=null, it means that the request was not allowed to be performed. It was UNSENT. A likely cause for this is when the XMLHttpRequest origin (at the creation of the XMLHttpRequest) has changed when the XMLHttpRequest is then open(). This case can happen for example when one has an XMLHttpRequest that gets fired on an onunload event for a window: the XMLHttpRequest gets in fact created when the window to be closed is still there, and then the request is sent (ie open()) when this window has lost its focus and potentially different window has gained focus. The way to avoid this problem is to set a listener on the new window "activate” event that gets set when the old window has its “unload” event fired.

Downloading JSON and JavaScript from extensions

For security reasons, extensions should never use eval() to parse JSON or JavaScript code downloaded from the web.  See Downloading JSON and JavaScript in extensions for details.

Using XMLHttpRequest from JavaScript modules / XPCOM components

Instantiating XMLHttpRequest from a JavaScript module or an XPCOM component works a little differently; it can’t be instantiated using the XMLHttpRequest() constructor. The constructor is not defined inside components and the code results in an error. The best way to work around this is to use the XPCOM component constructor.

1
2
const XMLHttpRequest = Components.Constructor("@mozilla.org/xmlextras/xmlhttprequest;1");
var req = XMLHttpRequest();

Unfortunately in versions of Gecko prior to Gecko 16 there is a bug which can cause requests created this way to be cancelled for no reason.  If you need your code to work on Gecko 15 or earlier, you can get the XMLHttpRequest constructor from the hidden DOM window like so.

1
2
3
4
const { XMLHttpRequest } = Components.classes["@mozilla.org/appshell/appShellService;1"]
                                     .getService(Components.interfaces.nsIAppShellService)
                                     .hiddenDOMWindow;
var req = XMLHttpRequest();

See also

  1. MDC AJAX introduction
  2. HTTP access control
  3. How to check the security state of an XMLHTTPRequest over SSL
  4. XMLHttpRequest – REST and the Rich User Experience
  5. Microsoft documentation
  6. Apple developers’ reference
  7. “Using the XMLHttpRequest Object” (jibbering.com)
  8. The XMLHttpRequest Object: W3C Specification
  9. Web Progress Events specification
  10. Reading Ogg files with JavaScript (Chris Double)

https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest/Using_XMLHttpRequest

에서 참조

XMLHttpRequest makes sending HTTP requests very easy.  You simply create an instance of the object, open a URL, and send the request.  The HTTP status of the result, as well as the result’s contents, are available in the request object when the transaction is completed. This page outlines some of the common and even slightly obscure use cases for this powerful JavaScript object.

Types of requests

A request made via XMLHttpRequest can fetch the data in one of two ways, asynchronously or synchronously. The type of request is dictated by the optional async property that is set on the XMLHttpRequest .open() method. If this property is set to false, then the XMLHttpRequest will be processed synchronously, otherwise the process will be done asynchronously. A detailed discussion and demonstrations of these two types of requests can be found on the synchronous and asynchronous requests page.

Handling responses

There are several types of response attributes defined by the W3C specification for XMLHttpRequest.  These tell the client making the XMLHttpRequest important information about the status of the response. For many use cases this is as straightforward as the following example:

1
2
3
4
5
6
7
8
var request = new XMLHttpRequest();
request.open('GET', 'http://www.mozilla.org', false);
request.send(); // because of "false" above, will block until the request is done 
                // and status is available. Not recommended, however it works for simple cases.
  
if (request.status === 200) {
  console.log(request.responseText);
}

There are some situations where the contents of a remote response from an XMLHttpRequest may not be handled as easily as the case above. A few of these cases where dealing with reponseXML and responseText involves some manipulation and analysis are outlined in the following sections.

Analyzing and manipulating the responseXML property

If you use XMLHttpRequest to get the content of a remote XML document, the responseXML property will be a DOM Object containing a parsed XML document, which can be hard to manipulate and analyze. There are four primary ways of analyzing this XML document:

  1. Using XPath to address (point to) parts of it.
  2. Using JXON to convert it into a JavaScript Object tree.
  3. Manually Parsing and serializing XML to strings or objects.
  4. Using XMLSerializer to serialize DOM trees to strings or to files.
  5. RegExp can be used if you always know the content of the XML document beforehand. You might want to remove line breaks, if you use RegExp to scan with regard to linebreaks. However, this method is a “last resort” since if the XML code changes slightly, the method will likely fail.

Analyzing and manipulating a responseText property containing an HTML document

Note: The W3C XMLHttpRequest specification has added HTML parsing support to XMLHttpRequest, which originally supported only XML parsing. This feature allows Web apps to obtain an HTML resource as a parsed DOM using XMLHttpRequest.responseXML property. Read the article about HTML in XMLHttpRequest for details.

If you use XMLHttpRequest to get the content of a remote HTML webpage, the responseText property is a string containing a “soup” of all the HTML tags, which can be hard to manipulate and analyze. There are three primary ways of analyzing this HTML soup string:

  1. Safely parsing with nsIScriptableUnescapeHTML will quickly convert the HTML string into DOM, while stripping out JavaScript and other advanced elements, including the <head> of the webpage.
  2. RegExp can be used if you always know the content of the HTML responseText beforehand. You might want to remove line breaks, if you use RegExp to scan with regard to linebreaks. However, this method is a “last resort” since if the HTML code changes slightly, the method will likely fail.
  3. Using a hidden chrome or content-level iframe to load up the webpage can also be done to then manipulate it as DOM, however there are security risks to giving remote code this level of privileged access, which can cause issues for the review of your addon. For example, if a webpage executes the common “document.location = redirecttothispage.html” command on load, this will get interpreted as changing the browser chrome location (document.location in an extension) as opposed to the webpage location (content.document.location in an extension), thus destroying all browser components. Alternatively, and somewhat safer, a responseText string attained through a XMLHttpRequest can be analyzed using RegExp to remove potential JavaScript problems, then loaded into the hidden iframe that you have set up:
document.getElementById("hiddenXULiframe").contentWindow.document.body.innerHTML = req.responseText

Using FormData objects

The FormData object lets you compile a set of key/value pairs to send using XMLHttpRequest. Its primarily intended for use in sending form data, but can be used independently from forms in order to transmit keyed data. The transmitted data is in the same format that the form’s submit() method would use to send the data if the form’s encoding type were set to “multipart/form-data”. FormData objects can be utilized in a number of ways with an XMLHttpRequest. For examples and explanations of how one can utilize FormData with XMLHttpRequests see the Using FormData Objects page.

Handling binary data

Although XMLHttpRequest is most commonly used to send and receive textual data, it can be used to send and receive binary content. There are several well tested methods for coercing the response of an XMLHttpRequest into sending binary data. These involve utilizing the .overrideMimeType() method on the XMLHttpRequest object and is a workable solution.

1
2
3
4
5
var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
// retrieve data unprocessed as a binary string
xhr.overrideMimeType("text/plain; charset=x-user-defined");
/* ... */

The XMLHttpRequest Level 2 Specification adds new responseType attributes which make sending and receiving binary data much easier.

1
2
3
4
5
6
7
8
var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
xhr.responseType = "arraybuffer"
xhr.onload = function(e) {
  var arraybuffer = xhr.response; // not responseText
  /* ... */
}
xhr.send();

For more examples check out the Sending and Receiving Binary Data page

Monitoring progress

XMLHttpRequest provides the ability to listen to various events that can occur while the request is being processed. This includes periodic progress notifications, error notifications, and so forth.

Support for DOM progress event monitoring of XMLHttpRequest transfers follows the Web API specification for progress events.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
var req = new XMLHttpRequest();
  
req.addEventListener("progress", updateProgress, false);
req.addEventListener("load", transferComplete, false);
req.addEventListener("error", transferFailed, false);
req.addEventListener("abort", transferCanceled, false);
  
req.open();
  
...
  
// progress on transfers from the server to the client (downloads)
function updateProgress(evt) {
  if (evt.lengthComputable) {
    var percentComplete = evt.loaded / evt.total;
    ...
  } else {
    // Unable to compute progress information since the total size is unknown
  }
}
  
function transferComplete(evt) {
  alert("The transfer is complete.");
}
  
function transferFailed(evt) {
  alert("An error occurred while transferring the file.");
}
  
function transferCanceled(evt) {
  alert("The transfer has been canceled by the user.");
}

Lines 3-6 add event listeners for the various events that are sent while performing a data transfer using XMLHttpRequest

Note: You need to add the event listeners before calling open() on the request.  Otherwise the progress events will not fire.

The progress event handler, specified by the updateProgress() function in this example, receives the total number of bytes to transfer as well as the number of bytes transferred so far in the event’s total and loaded fields.  However, if the lengthComputable field is false, the total length is not known and will be zero.

Progress events exist for both download and upload transfers. The download events are fired on the XMLHttpRequest object itself, as shown in the above sample. The upload events are fired on the XMLHttpRequest.upload object, as shown below:

1
2
3
4
5
6
7
8
var req = new XMLHttpRequest();
  
req.upload.addEventListener("progress", updateProgress, false);
req.upload.addEventListener("load", transferComplete, false);
req.upload.addEventListener("error", transferFailed, false);
req.upload.addEventListener("abort", transferCanceled, false);
  
req.open();
Note: Progress events are not available for the file: protocol.
Gecko 9.0 note

(Firefox 9.0 / Thunderbird 9.0 / SeaMonkey 2.6)

Starting in Gecko 9.0 (Firefox 9.0 / Thunderbird 9.0 / SeaMonkey 2.6), progress events can now be relied upon to come in for every chunk of data received, including the last chunk in cases in which the last packet is received and the connection closed before the progress event is fired. In this case, the progress event is automatically fired when the load event occurs for that packet. This lets you now reliably monitor progress by only watching the “progress” event.

Gecko 12.0 note

(Firefox 12.0 / Thunderbird 12.0 / SeaMonkey 2.9)

If your progress event is called with a responseType of “moz-blob”, the value of response is a Blob containing the data received so far.

One can also detect all three load-ending conditions (abort, load, or error) using the loadend event:

1
2
3
4
5
req.addEventListener("loadend", loadEnd, false);
  
function loadEnd(evt) {
  alert("The transfer finished (although we don't know if it succeeded or not).");
}

Note that there’s no way to be certain from the information received by the loadend event as to which condition caused the operation to terminate; however, you can use this to handle tasks that need to be performed in all end-of-transfer scenarios.

Cross-site XMLHttpRequest

Modern browsers support cross-site requests by implementing the web applications working group’s Access Control for Cross-Site Requests standard.  As long as the server is configured to allow requests from your web application’s origin, XMLHttpRequest will work.  Otherwise, an INVALID_ACCESS_ERR exception is thrown.

Bypassing the cache

Normally, XMLHttpRequest tries to retrieve content from the cache, if it’s available.  To bypass this, do the following:

1
2
3
4
var req = new XMLHttpRequest();
req.open('GET', url, false);
req.channel.loadFlags |= Components.interfaces.nsIRequest.LOAD_BYPASS_CACHE;
req.send(null);
Note: This approach will only work in Gecko-based software, as the channel attribute is Gecko-specific.

An alternate, cross-browser compatible approach is to append a timestamp to the URL, being sure to include a “?" or ”&“ as appropriate.  For example:

http://foo.com/bar.html

becomes

http://foo.com/bar.html?12345

and

http://foo.com/bar.html?foobar=baz

becomes

http://foo.com/bar.html?foobar=baz&12345

Since the local cache is indexed by URL, this causes every request to be unique, thereby bypassing the cache.

You can automatically adjust URLs using the following code:

1
2
3
var req = new XMLHttpRequest();
req.open("GET", url += ((/?/).test(url) ? "&" : "?") + (new Date()).getTime(), false);
req.send(null); 

Security

Firefox 3 note

Versions of Firefox prior to Firefox 3 allowed you to set the preference capability.policy.<policyname>.XMLHttpRequest.open</policyname> to allAccess to give specific sites cross-site access.  This is no longer supported.

Firefox 5 note

Versions of Firefox prior to Firefox 5 could use netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); to request cross-site access. This is no longer supported, even though it produces no warning and permission dialog is still presented.

The recommended way to enable cross-site scripting is to use the Access-Control-Allow-Origin HTTP header in the response to the XMLHttpRequest.

XMLHttpRequests being stopped

If you end up with an XMLHttpRequest having status=0 and statusText=null, it means that the request was not allowed to be performed. It was UNSENT. A likely cause for this is when the XMLHttpRequest origin (at the creation of the XMLHttpRequest) has changed when the XMLHttpRequest is then open(). This case can happen for example when one has an XMLHttpRequest that gets fired on an onunload event for a window: the XMLHttpRequest gets in fact created when the window to be closed is still there, and then the request is sent (ie open()) when this window has lost its focus and potentially different window has gained focus. The way to avoid this problem is to set a listener on the new window "activate” event that gets set when the old window has its “unload” event fired.

Downloading JSON and JavaScript from extensions

For security reasons, extensions should never use eval() to parse JSON or JavaScript code downloaded from the web.  See Downloading JSON and JavaScript in extensions for details.

Using XMLHttpRequest from JavaScript modules / XPCOM components

Instantiating XMLHttpRequest from a JavaScript module or an XPCOM component works a little differently; it can’t be instantiated using the XMLHttpRequest() constructor. The constructor is not defined inside components and the code results in an error. The best way to work around this is to use the XPCOM component constructor.

1
2
const XMLHttpRequest = Components.Constructor("@mozilla.org/xmlextras/xmlhttprequest;1");
var req = XMLHttpRequest();

Unfortunately in versions of Gecko prior to Gecko 16 there is a bug which can cause requests created this way to be cancelled for no reason.  If you need your code to work on Gecko 15 or earlier, you can get the XMLHttpRequest constructor from the hidden DOM window like so.

1
2
3
4
const { XMLHttpRequest } = Components.classes["@mozilla.org/appshell/appShellService;1"]
                                     .getService(Components.interfaces.nsIAppShellService)
                                     .hiddenDOMWindow;
var req = XMLHttpRequest();

See also

  1. MDC AJAX introduction
  2. HTTP access control
  3. How to check the security state of an XMLHTTPRequest over SSL
  4. XMLHttpRequest – REST and the Rich User Experience
  5. Microsoft documentation
  6. Apple developers’ reference
  7. “Using the XMLHttpRequest Object” (jibbering.com)
  8. The XMLHttpRequest Object: W3C Specification
  9. Web Progress Events specification
  10. Reading Ogg files with JavaScript (Chris Double)

https://developer.mozilla.org/en-US/docs/AJAX/Getting_Started

에서 참조

 

What’s AJAX?

AJAX stands for Asynchronous JavaScript and XML. In a nutshell, it is the use of the XMLHttpRequest object to communicate with server-side scripts. It can send as well as receive information in a variety of formats, including JSON, XML, HTML, and even text files. AJAX’s most appealing characteristic, however, is its “asynchronous” nature, which means it can do all of this without having to refresh the page. This lets you update portions of a page based upon user events.

The two features in question are that you can:

  • Make requests to the server without reloading the page
  • Receive and work with data from the server

Step 1 – How to make an HTTP request

In order to make an HTTP request to the server using JavaScript, you need an instance of a class that provides this functionality. Such a class was originally introduced in Internet Explorer as an ActiveX object, called XMLHTTP. Then Mozilla, Safari, and other browsers followed, implementing an XMLHttpRequest class that supports the methods and properties of Microsoft’s original ActiveX object.

As a result, in order to create a cross-browser instance (object) of the required class, you can do the following:

1
2
3
4
5
6
var httpRequest;
if (window.XMLHttpRequest) { // Mozilla, Safari, ...
    httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE 8 and older
    httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}
Note: For illustration purposes, the above is a somewhat simplified version of the code to be used for creating an XMLHTTP instance. For a more real-life example, see step 3 of this article.

Next, you need to decide what you want to do after you receive the server response to your request. At this stage, you just need to tell the HTTP request object which JavaScript function will handle processing the response. This is done by setting the onreadystatechange property of the object to the name of the JavaScript function that should be called when the state of the request changes, like this:

httpRequest.onreadystatechange = nameOfTheFunction;

Note that there are no parentheses after the function name and no parameters passed, because you’re simply assigning a reference to the function, rather than actually calling it. Also, instead of giving a function name, you can use the JavaScript technique of defining functions on the fly (called “anonymous functions”) and define the actions that will process the response right away, like this:

1
2
3
httpRequest.onreadystatechange = function(){
    // process the server response
};

Next, after you’ve declared what will happen as soon as you receive the response, you need to actually make the request. You need to call the open() and send() methods of the HTTP request class, like this:

1
2
httpRequest.open('GET', 'http://www.example.org/some.file', true);
httpRequest.send(null);
  • The first parameter of the call to open() is the HTTP request method – GET, POST, HEAD or any other method you want to use and that is supported by your server. Keep the method capitalized as per the HTTP standard; otherwise some browsers (like Firefox) might not process the request. For more information on the possible HTTP request methods you can check the W3C specs.
  • The second parameter is the URL of the page you’re requesting. As a security feature, you cannot call pages on 3rd-party domains. Be sure to use the exact domain name on all of your pages or you will get a “permission denied” error when you call open(). A common pitfall is accessing your site by domain.tld, but attempting to call pages with www.domain.tld. If you really need to send a request to another domain, see HTTP access control.
  • The optional third parameter sets whether the request is asynchronous. If TRUE (the default), the execution of the JavaScript function will continue while the response of the server has not yet arrived. This is the A in AJAX.

The parameter to the send() method can be any data you want to send to the server if POST-ing the request. Form data should be sent in a format that the server can parse easily. This can be as a query string, like:

"name=value&anothername="+encodeURIComponent(myVar)+"&so=on"

or in several other formats, including JSON, SOAP, etc.

Note that if you want to POST data, you may have to set the MIME type of the request. For example, use the following line before calling send() for form data sent as a query string:

1
httpRequest.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');

Step 2 – Handling the server response

Remember that when you were sending the request, you provided the name of a JavaScript function that is designed to handle the response.

1
httpRequest.onreadystatechange = nameOfTheFunction;

Let’s see what this function should do. First, the function needs to check for the state of the request. If the state has the value of 4, that means that the full server response has been received and it’s OK for you to continue processing it.

1
2
3
4
5
if (httpRequest.readyState === 4) {
    // everything is good, the response is received
} else {
    // still not ready
}

The full list of the readyState values is as follows:

  • 0 (uninitialized)
  • 1 (loading)
  • 2 (loaded)
  • 3 (interactive)
  • 4 (complete)

(Source)

The next thing to check is the response code of the HTTP server response. All the possible codes are listed on the W3C site. In the following example, we differentiate between a successful or unsuccessful AJAX call by checking for a  200 OK response code.

1
2
3
4
5
6
7
if (httpRequest.status === 200) {
    // perfect!
} else {
    // there was a problem with the request,
    // for example the response may contain a 404 (Not Found)
    // or 500 (Internal Server Error) response code
}

Now after you’ve checked the state of the request and the HTTP status code of the response, it’s up to you to do whatever you want with the data the server has sent to you. You have two options to access that data:

  • httpRequest.responseText – returns the server response as a string of text
  • httpRequest.responseXML – returns the response as an XMLDocument object you can traverse using the JavaScript DOM functions

Note that the steps above are only valid if you used an asynchronous request (third parameter of open() was set to true). If you used an synchronous request you don’t need to specify a function, you can access the data return by the server right after calling send(), because the script will stop and wait for the server answer.

Step 3 – A Simple Example

Let’s put it all together and do a simple HTTP request. Our JavaScript will request an HTML document, test.html, which contains the text “I’m a test.” and then we’ll alert() the contents of the test.html file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<span id="ajaxButton" style="cursor: pointer; text-decoration: underline">
  Make a request
</span>
<script type="text/javascript">
(function() {
  var httpRequest;
  document.getElementById("ajaxButton").onclick = function() { makeRequest('test.html'); };
  
  function makeRequest(url) {
    if (window.XMLHttpRequest) { // Mozilla, Safari, ...
      httpRequest = new XMLHttpRequest();
    } else if (window.ActiveXObject) { // IE
      try {
        httpRequest = new ActiveXObject("Msxml2.XMLHTTP");
     
      catch (e) {
        try {
          httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
       
        catch (e) {}
      }
    }
  
    if (!httpRequest) {
      alert('Giving up 🙁 Cannot create an XMLHTTP instance');
      return false;
    }
    httpRequest.onreadystatechange = alertContents;
    httpRequest.open('GET', url);
    httpRequest.send();
  }
  
  function alertContents() {
    if (httpRequest.readyState === 4) {
      if (httpRequest.status === 200) {
        alert(httpRequest.responseText);
      } else {
        alert('There was a problem with the request.');
      }
    }
  }
})();
</script>

In this example:

  • The user clicks the link “Make a request” in the browser;
  • The event handler calls the makeRequest() function with a parameter – the name test.html of an HTML file in the same directory;
  • The request is made and then (onreadystatechange) the execution is passed to alertContents();
  • alertContents() checks if the response was received and it’s an OK and then alert()s the contents of the test.html file.
Note: If you’re sending a request to a piece of code that will return XML, rather than to a static XML file, you must set some response headers if your page is to work in Internet Explorer in addition to Mozilla. If you do not set header Content-Type: application/xml, IE will throw a JavaScript error, “Object Expected”, after the line where you try to access an XML element. 
Note 2: If you do not set header Cache-Control: no-cache the browser will cache the response and never re-submit the request, making debugging “challenging.” You can also append an always-diferent aditional GET parameter, like the timestamp or a random number (see bypassing the cache)
Note 3: If the httpRequest variable is used globally, competing functions calling makeRequest() may overwrite each other, causing a race condition. Declaring the httpRequest variable local to a closure containing the AJAX functions prevents the race condition.
Note 4: In the event of a communication error (such as the webserver going down), an exception will be thrown in the onreadystatechange method when attempting to access the status field. Make sure that you wrap your if…then statement in a try…catch. (See: bug 238559).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
function alertContents(httpRequest) {
  try {
    if (httpRequest.readyState === 4) {
      if (httpRequest.status === 200) {
        alert(httpRequest.responseText);
      } else {
        alert('There was a problem with the request.');
      }
    }
  }
  catch( e ) {
    alert('Caught Exception: ' + e.description);
  }
}

Step 4 – Working with the XML response

In the previous example, after the response to the HTTP request was received we used the responseText property of the request object, which contained the contents of the test.html file. Now let’s try the responseXML property.

First off, let’s create a valid XML document that we’ll request later on. The document (test.xml) contains the following:

1
2
3
4
<?xml version="1.0" ?>
<root>
    I'm a test.
</root>

In the script we only need to change the request line to:

1
2
3
...
onclick="makeRequest('test.xml')">
...

Then in alertContents(), we need to replace the line alert(httpRequest.responseText); with:

1
2
3
var xmldoc = httpRequest.responseXML;
var root_node = xmldoc.getElementsByTagName('root').item(0);
alert(root_node.firstChild.data);

This code takes the XMLDocument object given by responseXML and uses DOM methods to access some of the data contained in the XML document. You can see the test.xml here and the updated test script here.

Step 5 – Working with data

Finally, let’s send some data to the server and receive a response. Our JavaScript will request a dynamic page this time, test.php, which will take the data we send and return a “computed” string – “Hello, [user data]!” – which we’ll alert().

First we’ll add a text box to our HTML so the user can enter their name:

1
2
3
4
5
6
<label>Your name: 
  <input type="text" id="ajaxTextbox" />
</label>
<span id="ajaxButton" style="cursor: pointer; text-decoration: underline">
  Make a request
</span>

We’ll also add a line to our event handler to get the user’s data from the text box and send it to the makeRequest() function along with the URL of our server-side script:

1
2
3
4
  document.getElementById("ajaxButton").onclick = function() { 
      var userName = document.getElementById("ajaxTextbox").value;
      makeRequest('test.php',userName); 
  };

We need to modify makeRequest() to accept the user data and pass it along to the server. We’ll change the request method from GET to POST, and include our data as a parameter in the call to httpRequest.send():

1
2
3
4
5
6
7
8
9
  function makeRequest(url, userName) {
  
    ...
  
    httpRequest.onreadystatechange = alertContents;
    httpRequest.open('POST', url);
    httpRequest.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    httpRequest.send('userName=' + encodeURIComponent(userName));
  }

The function alertContents() can be written the same way it was in Step 3 to alert our computed string, if that’s all the server returns. However, let’s say the server is going to return both the computed string and the original user data. So if our user typed “Jane” in the text box, the server’s response would look like this:

{"userData":"Jane","computedString":"Hi, Jane!"}

To use this data within alertContents(), we can’t just alert the responseText, we have to parse it and alert computedString, the property we want:

1
2
3
4
5
6
7
8
9
function alertContents() {
    if (httpRequest.readyState === 4) {
      if (httpRequest.status === 200) {
        var response = JSON.parse(httpRequest.responseText);
        alert(response.computedString);
    } else {
      alert('There was a problem with the request.');
    }
}