Talk:XMLHttpRequest Call
Time your website with
WebWait - from the creator of AjaxPatterns.orgFrom Ajax Patterns
There's an archived version of this pattern available, taken from the Ajax Pattern book draft, showing roughly how it appeared before the page became publicly editable.
Contents |
Ajax/Javascript Programming and Usability in "Ajax Design Patterns" Book |
http://ajaxify.com/run/xmlHtttpRequestCall/sumGet.phtml?figure1=5&figure2=10
Notice the triple 't' in http://ajaxify.com/run/xmlHtttpRequestCall/sumGet.phtml?figure1=5&figure2=10? I just fixed this link in the article, but I think the directory should be renamed (and consequently, the link should be refixed to the old one).
req.overrideMimeType
Enjoyed your concise writing on XMLHttpRequest. Many thanks. One question - I read, I can't remember where now, that "Some Mozillas don't work if response has no XML mime-type header" and thus code similar to the following should be included:
//Some Mozillas don't work if response has no XML mime-type header
if(req.overrideMimeType) {
req.overrideMimeType('text/xml');
}
Wondered what your take was on that. Is this needed?
joe@joepage.com
---
I notice some typos.
1. In the XMLHttpRequest API: A Summary - open(requestMethod, url, async....) Only the first two parameters are *required*.
2. In the Alternatives IFrame XMLHttpRequest offers functionality not available to *IFrame*.
Weerasak
Handling POSTs and Other Request Types - Gecko errors
In Section 5.4 "Handling POSTs and Other Request Types" the final code sample reads:
var xhreq = createxmlhttprequest();
** xhReq.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); **
xhreq.open("post", "sumPostForm.phtml", true);
xhreq.onreadystatechange = function() {
if (xhreq.readystate != 4) { return; }
var serverresponse = xhreq.responsetext;
...
};
** xhreq.send("calculate this sum: 5+6"); **
However this will fail in Gecko based browsers (eg Firefox), leaving an error message similar to the one below:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.setRequestHeader]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://localhost/temp/ajaxtest.html :: FunctionName :: line 60" data: no]
This is because the setRequestHeader must be called only after an open() call. (see relevant comments in the Mozilla source, here [1] )
Simple fix is to modify the code sample to:
var xhreq = createxmlhttprequest();
xhreq.open("post", "sumPostForm.phtml", true);
** xhReq.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); **
xhreq.onreadystatechange = function() {
if (xhreq.readystate != 4) { return; }
var serverresponse = xhreq.responsetext;
...
};
** xhreq.send("calculate this sum: 5+6"); **
May well be worth adding a note mentioning the importance of the ordering of the calls.
GAThrawn 16:23, 3 April 2006 (PDT)
Amazing article.
This is simply a great article, for real people.
HTTP Status Codes
In the section on "Detecting Errors", it is misleading to say, "In most cases, you can assume anything other than 200 is an error situation." Some advanced browsers such as Opera actually use an HTTP mechanism called "Conditional GET". [http://fishbowl.pastiche.org/2002/10/21/http_conditional_get_for_rss_hackers] During a Conditional GET, the client will cache the file, and subsequent requests to the server will only return a header if the file has not been modified. The HTTP status code returned in this situation is 304, and this is akin to 200. The only difference is that you're automagically using an on-disk cached version of the file. Additionally, if you connect through a proxy server that provides local caching, you are also liable to get a status 203. This document and the code should be revised to fix this misinformation, and a link to a reference containing the HTTP status codes should be included. [http://en.wikipedia.org/wiki/List_of_HTTP_status_codes] --Geoffrey Lee 07:46, 31 May 2006 (EDT)
Do any implementations return status 304? 304 (Not modified) is from a conditional request and means the client should use the response entity and headers that it has previously received. But the previously received status is also part of the cached response - so don't implementations of XMLHttpRequest return the cached status code that was received previously, rather than 304, in this case? --Jamie Lokier 04:37, 11 June 2006 (BST)
