From Wikipedia, the free encyclopedia
Jump to: navigation, search

For older discussion on this article dating from 2005-2008, please see Talk:XMLHttpRequest/2005-2008.


Can anyone provide a source for this statement: If the Content-Type request header was not added through setRequestHeader yet, it should automatically be added by a conforming user agent as "application/xml;charset=charset," where charset is the encoding used to encode the document.

It appears that it is not possible to set the charset of the Request Header. It is always set to UTF-8, regardless of the document encoding. —Preceding unsigned comment added by Nepherim (talkcontribs) 18:32, 13 June 2010 (UTC)

Known bugs[edit]

Can anyone provide any reference to show that the IE cache bug descirbed in the 'known bugs' is correct? I have never encountered this problem. --Sleepyhead 10:31, 20 August 2005 (UTC)

Neither have I, there is probably no bug. Taka 14:42, 29 October 2005 (UTC)

I remember having problems with opera caching get requests using this. I appeneded a unixtimestamp to avoid it though.

I've seen this problem with IE6. I think it only happens when you send requests from more than one Javascript function. For example, I'm using Ajax to update dropdowns. Setting one queries the database for values for the second. Setting the second dropdown queries the database for values for the third dropdown. But what might be helpful here is a better description of what non-idempotent operations are. DRogers 23:16, 4 October 2006 (UTC)

I experienced a problem where IE would cache the previous XML response while Firefox would always refresh. In the end simply getting the servlet that returned the XML to add the HTTP header 'Expires: -1' seemed to fix the problem - it now works fine with both browsers. --Stuartallen1972 00:53, 31 October 2007 (UTC)

I have personally observed this bug over many years. I personally verified that it remains in IE7 in February of 2008. DRogers is incorrect, it happens even when you have just one js function. I tried every combination of request header on the client and response header on the server that I could find documetation for and IE still returned the stale page from the cache instead of the fresh page from the server.
I find that most documents fall into one of three categories. A) They never change and the default IE behavior does not hurt and does conserve network capacity so it is left in place. B) The pages change, but data that is out of date does not hurt any one, so the default behavior is left in place to gain the benefits of caching. C) The data does change and stale data has consequences, so the developer, in frustration adds the timestamp to the URL, thereby not only defeating the cache but polluting it with many cached pages that will never be referred to, one for each refresh of the URL. The wasted time, network capacity and local storage are considered a small penalty to pay in exchange for eliminating the possibility of stale data. When the response is tiny, then as a practical matter, this may be true, but after years of serving data that fell in one of those three categories, I encountered for the first time a situation that falls in a 4th category. A response that was critical and large. The typical response of adding a timestamp to the URL was no longer acceptable. My users were going to pay and pay and pay for my sloppiness. Each time they visited or refreshed the page, they were going to reload a large document that in turn had the potential to fill their cache space with documents that would never be referenced. I was finally ready to invest the time to solve the issue instead of bypassing it as I had done for years. As I researched it, I did find it reported in many places on the web, and I did see a few half baked approaches to solving it, and at least one case where a solution was described but not presented ([1]). I pretty much had my solution coded and working before I arrived at this page, where I saw it presented in the most elegant form that I had yet seen.
The discussion of what does or does not belong in Wikipedia is frustrating. The answer is not black and white. I can think of all kinds of code that I would not want to see posted because it would obscure the "encyclopedic" content of the page. In this case, the bug has been around for ever, the solution is simple and elegant; it works perfectly for all 4 categories of data that I mentioned above. It provides all of the benefits of caching and all of the benefits of getting a fresh copy each time and never polluting the user’s cache. Finally, allowing such a code snippet on this page provides the biggest benefit of all which is being vetted by thousands of the most dedicated people in the world, you (and me). That is not possible if we send people elsewhere to find the code or algorithm. This brings me to this point.
Why in the code sample do we send null in the first send and an empty string in the second? I don't think there is functionally difference, you’re going to get to newlines in a row in the data stream sent to the host in either case, but it gives the impression that there is a difference and that the difference is significant which makes an observant reader take off on a wild goose chase. I propose that null be used in both instances, to avoid confusion.
In conclusion, I think that the code samples definitely belong on the page in this case. It is too important; everyone that uses XHR needs to know about the issue and the elegant solution. And everyone will benefit by having it vetted and improved upon and improved upon so that it is the cleanest and most elegant that it can be. -- Gary D. —Preceding unsigned comment added by (talk) 17:17, 1 March 2009 (UTC)

Please keep short IE 5-6 compatibility code[edit]

The article correctly states IE had XHR in versions prior to 7. However, I notice someone has been removing the fact that versions before 7.0 cannot instantiate the now-standard XMLHttpRequest class without workarounds, because the original Microsoft XMLHTTP was not a class of its own, but an ActiveXObject. None of the examples on the page work in IE 5.x-6.x without code somewhat like this, and the info on the page is misleading without it, so please discuss here before removing it again: (talk) 16:17, 27 August 2008 (UTC)

// Make the XMLHttpRequest class available in IE 5.x-6.x:
if( typeof XMLHttpRequest == "undefined" ) XMLHttpRequest = function() {
  try { return new ActiveXObject("Msxml2.XMLHTTP.6.0") } catch(e) {}
  try { return new ActiveXObject("Msxml2.XMLHTTP.3.0") } catch(e) {}
  try { return new ActiveXObject("Msxml2.XMLHTTP") } catch(e) {}
  throw new Error( "This browser does not support XMLHttpRequest." )

I don't think this listing adds encyclopedic value, and removed it. Wikipedia is not a how-to, and should keep the discussion of backwards compatibility to a high level, appropriate for the context. Any readers interested in actual implementation details can find them in the cited sources and external links. --Piet Delport (talk) 14:27, 6 January 2011 (UTC)

Move API ( property function method in other article ?[edit]

methods and properties have no reason to be in a wikipedia article. Resume it to help people discover what it can do ll be more intructive. as a developper find this chapter usefull but not for non programmer. perhaps specific code could be keep ? —Preceding unsigned comment added by (talk) 17:06, 3 September 2008 (UTC)

  • Yes, many have heard the term xmlhttp and come here to discover what it is. Many others (like me) come here to find out how to get xmlhttp to do what it does. You (rightly, imo) object to the immediate plunge into technical content in the opening sentences. So let us prepare a short introductory paragraph for the incognoscenti that will/should answer most of their questions. Example: a high-level understanding of xmlhttp is a small but essential part of understanding web 2.0. So let's tell the lay visitor that in a few sentences and move on to the very-much-needed technical discussion. Like the lead paragraph in a newspaper story: what is it; and why is it? — Preceding unsigned comment added by Pete142 (talkcontribs) 11:15, 10 January 2011 (UTC)
  • sigh* I came here as a programmer to look at the wonderful example and its gone. Gone in the name of arbitrary order for order's sake, it looks like. It wasn't hurting anything. —Preceding unsigned comment added by (talk) 06:02, 2 September 2009 (UTC)
Yeah, we seem to have a 'dumbing-down' brigade who hate code examples in articles - it's happened on XML, SVG, CSS etc etc. Apparently we need more history and media comment. Yet they don't seem to mind almost impenetrable mathematical articles like Negligible function. Media studies is the future (but hopefully, some of us will still remember how the software works) :o) --Nigelj (talk) 16:35, 2 September 2009 (UTC)
  • Well, I guess wikipedia isn't interested in being a handy programmer reference anymore. I'm not convinced this makes wikipedia better, but it's not a huge deal either way. (talk) 05:37, 22 September 2009 (UTC)

Wikipedia links to handy programmer references: it isn't one itself. --Piet Delport (talk) 14:33, 6 January 2011 (UTC)

  • Well, Piet, many believe that Wikipedia has become the resource it is because people have contributed material that interests them, thinking it might interest others as well. How did you conclude that this belief is in error?

I, too, came here looking for xmlhttp info. If there is code too, well, bravo! So much the better! It means I can save thirty minutes. So please: don't remove any code. — Preceding unsigned comment added by Pete142 (talkcontribs) 10:44, 10 January 2011 (UTC)

What's XML-RPC got to do with it ?[edit]

This paragraph seems a bit out of place:

"This type of AJAX architecture should not be confused with (XDR) XDomainRequest which is a lightweight form of the XMLHttpRequest design by Microsoft which doesn't utilize XML-RPC."

because XMLHttpRequest doesn't use XML-RPC either, and it's not mentioned anywhere else in the article or in the citation for that Microsoft API. Perhaps I'm missing something though, so leaving it for someone who knows more about this stuff than me. --Qef (talk) 12:08, 10 July 2009 (UTC)

Correct. XDomainRequest and XMLHttpRequest are for sending requests and receiving responses through protocols (for XMLHttpRequest, specifically the HTTP and HTTPS protocols as defined by W3C). XML-RPC is a way to structure requests and responses using XML for creating language-independent communication between applications through protocols. XMLHttpRequest does not even require XML. The XML in "XMLHttpRequest" is not referring to the request Content-Type or the response Content-Type, only the fact that if the response is an Internet media type for XML, it should be parsed into a DOM Document object automatically. And even if it was an XML response, I don't believe (and could ever imagine) any user agents implemented a version of XMLHttpRequest that searches for and handles XML-RPC in the response automatically, too.
To clarify what XDomainRequest really is, it is a wrapper/object in IE8 which implements the interfaces of the XMLHttpRequest object with additional support for cross-domain requests and progress events. Similar features are planned for the XMLHttpRequest object itself in the level 2 specification, which is still a working draft, as is the level 1 specification still...
Good spot on that, Qef. I'd like to know what the person that wrote that meant by it/was referring to. --Quilokos (talk) 23:28, 10 July 2009 (UTC)


First time I am reading the article and I notice that the "HTTP request" section has been tagged as having no reference. Looking through the history, the revision this has been done is "10:38, 1 October 2010 Mabdul". Although I can understand that two citations aren't much for that amount of text, a better thing to do would have been to look for references where you thought they would have been useful. I've been observing a tendency to flag things instead of contributing. If people have enough knowledge to flag, I'm expecting that they also have enough knowledge to correct things too. Otherwise, what I've learnt today on this article wouldn't have been available to me. There should be a middle ground between flagging and leaving, and contributing. — Preceding unsigned comment added by Amenel (talkcontribs)

I can understand you're opinion and your concerns about only-tagging articles. For my defense I have to say that I'm working on really many articles simultaneous and my watchlist has since a few weeks over 600 pages! (ok, some may redirects I created) In many articles I'm constantly adding more references or expanding these articles. I have not the time to expand this article also. mabdul 14:04, 25 January 2011 (UTC)

The onreadystatechange event listener[edit]

This section contains flawed example code. It would be better to correct the code.


1) the code example shows the send method called before the callback event is defined; and

2) the text following the code discusses the effect of calling the send method before the open method (reversing the first two lines)

It would surely be better to include good code and, if there are inconsistencies between browsers when such code executes, discuss those inconsistencies, rather than the problems that might be caused by poorly written code.

Showing bad coding examples and then discussing what's wrong with them may be appropriate for an article about good and bad coding practices, but it's not appropriate here.

--DMcMPO11AAUK/Talk/Contribs 19:06, 15 April 2011 (UTC)

Neither limited to XML nor HTTP[edit]

The article portrays XMLHttpRequest as supporting http and https and XML and plain text. That's the way XMLHttpRequest was originally, but since then, it has evolved to a more generic scriptable URL fetch mechanism.

These days, at least the development versions of all major browsers support URL schemes beyond http: and https:. In particular, blob: URLs are supported, see for spec.

Response types beyond XML and plain text are supported. These days, HTML, byte buffer and JSON responses are supported, too. See:

I'm not making edits to the article myself, since my edits would probably get reverted as violating some Wikipedia policy against primary sources as I have implemented some of these features for Firefox/Gecko. Hsivonen (talk) 11:32, 5 February 2012 (UTC)