Talk:XMLHttpRequest

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

setRequestHeader

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 (talk • contribs) 18:32, 13 June 2010 (UTC)

Known bugs

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 97.88.245.62 (talk) 17:17, 1 March 2009 (UTC)

Please keep short IE 5-6 compatibility code

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: 74.192.58.22 (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 ?

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 92.131.191.80 (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 (talk • contribs) 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 68.127.178.106 (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. 66.68.113.5 (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 (talk • contribs) 10:44, 10 January 2011 (UTC)

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

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)

Referencitis

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 (talk • contribs)

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

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

Specifically:

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

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 http://dev.w3.org/2006/webapi/FileAPI/ for spec.

Response types beyond XML and plain text are supported. These days, HTML, byte buffer and JSON responses are supported, too. See: https://developer.mozilla.org/En/HTML_in_XMLHttpRequest http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html https://bugzilla.mozilla.org/show_bug.cgi?id=707142 http://www.html5rocks.com/en/tutorials/file/xhr2/

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)

Maintenance and rating of JavaScript articles

Concerning editing and maintaining JavaScript-related articles...

Collaboration...

If you are interested in collaborating on JavaScript articles or would like to see where you could help, stop by Wikipedia:WikiProject JavaScript and feel free to add your name to the participants list. Both editors and programmers are welcome.

Where to list JavaScript articles

We've found over 300 JavaScript-related articles so far. If you come across any others, please add them to that list.

Aren't this kind of stuff should be made by special page Category:JavaScript page?82.142.169.244 (talk) 14:00, 4 August 2017 (UTC)

User scripts

The WikiProject is also taking on the organization of the Wikipedia community's user script support pages. If you are interested in helping to organize information on the user scripts (or are curious about what we are up to), let us know!

If you have need for a user script that does not yet exist, or you have a cool idea for a user script or gadget, you can post it at Wikipedia:User scripts/Requests. And if you are a JavaScript programmer, that's a great place to find tasks if you are bored.

How to report JavaScript articles in need of attention

If you come across a JavaScript article desperately in need of editor attention, and it's beyond your ability to handle, you can add it to our list of JavaScript-related articles that need attention.

Rating JavaScript articles

At the top of the talk page of most every JavaScript-related article is a WikiProject JavaScript template where you can record the quality class and importance of the article. Doing so will help the community track the stage of completion and watch the highest priority articles more closely.

Thank you. The Transhumanist 01:15, 12 April 2017 (UTC)

Feature detection outdated

if (window.XMLHttpRequest) ? Really? This is 2020, all major browsers support this feature without polyfills, and very few APIs bother checking. — Preceding unsigned comment added by 172.56.42.63 (talk) 02:18, 27 December 2020 (UTC)

Ajax?

"Particularly, retrieval of data from XHR for the purpose of continually modifying a loaded web page is the underlying concept of Ajax design."

The meaning and significance of that statement in the context is entirely non-obvious. Some overhaul (rewriting) can help. Regards, ... PeterEasthope (talk) 19:00, 20 January 2023 (UTC)

XHR is an API

This really isn't open to dispute. First line of the latest standard: "The XMLHttpRequest object is an API". The object implements an interface. One programs applications using that object that implements that interface. The standard specifies the required behavior of the interface, which in browser JavaScript runtimes is bound to objects created by calls to a constructor. There is no requirement that the objects are instances of a class in JavaScript or any other language. 2601:642:4600:D3B0:9111:FF68:B849:3D9B (talk) 21:00, 8 April 2024 (UTC)

I will add that the description of the methods appears to be written by someone who has never programmed an HTTP request in their life. "The HTTP request method may be GET for typical quantities of data." Nonsense. One does not choose between GET and POST based on the quantity of information sent, but why it is sent: to retrieve a resource, or to create/alter one. "If the request method of POST is invoked, then the web server expects the form data to be read from the standard input stream." That has nothing to do with XMLHttpRequest, and furthermore it isn't true. The data sent in a POST request isn't necessarily "form data", and the server can take it in any manner whatsoever. Taking it on standard input is a particular convention of CGI, a nearly obsolete technology. 2601:642:4600:D3B0:9111:FF68:B849:3D9B (talk) 22:57, 8 April 2024 (UTC)

* Regarding I will add that the description of the methods appears to be written by someone who has never programmed an HTTP request in their life.: Please refrain from personal attacks. Timhowardriley (talk) 07:27, 9 April 2024 (UTC)

* Regarding Nonsense: If you want to drill down on anything specific, then address it in a talk section. Be prepared to support your assertions with reliable sources. Timhowardriley (talk) 07:27, 9 April 2024 (UTC)

I will not refrain from criticizing the inclusion of wanton misinformation in the article. From HTTP 1.1: "The GET method means retrieve whatever information … is identified by the Request-URI." "POST is designed to allow … annotation of existing resources; posting a message …; providing a block of data … to a data-handling process; extending a database through an append operation." For a deeper discussion see Roy Fielding's dissertation on REST. 2601:642:4600:D3B0:9111:FF68:B849:3D9B (talk) 13:54, 9 April 2024 (UTC)

Would you like to explain what you suppose this code would do: request.open( "DELETE", null ); 2601:642:4600:D3B0:9111:FF68:B849:3D9B (talk) 14:13, 9 April 2024 (UTC)

* Regarding what the HTTP 1.1: says: The HTTP 1.1 is confusing. What Michael Mahemoff wrote in "Ajax Design Patterns" (published by O'Reilly) simplified the distinction. Timhowardriley (talk) 14:44, 9 April 2024 (UTC)

* Regarding request.open( "DELETE", null );: Please provide some context. Timhowardriley (talk) 14:44, 9 April 2024 (UTC)

* Regarding I will not refrain from criticizing the inclusion of wanton misinformation in the article.: Please keep the discussion cordial. Timhowardriley (talk) 14:44, 9 April 2024 (UTC)

* Regarding For a deeper discussion see Roy Fielding's dissertation on REST.: If material in this dissertation is germane to the discussion, then quote from it to support an assertion. Timhowardriley (talk) 14:44, 9 April 2024 (UTC)

HTTP 1.1 is a technical standard, and it is definitive. If it's "confusing", the burden is on the reader to demonstrate that. The "context" is that you added that code to the article a year ago. 2601:642:4600:D3B0:9111:FF68:B849:3D9B (talk) 14:50, 9 April 2024 (UTC)

Ruby on Rails was a significant influence in the adoption of REST-based server APIs. From Ruby on Rails for Microsoft Developers by Antonio Cangiano (credentials): "The Golden Rule of web development is that any request that retrieves information should be a GET request, and any request that affects the data stored on the server should use the POST HTTP method." (nb: Rails was introduced when support for PUT and DELETE was inconsistent, and it allows them to be tunneled through POST requests.) "This rule is constantly violated, and it's not uncommon to see publicly accessible links that issue GET requests and have the ability to delete or modify data…. You should avoid this at all costs." Indeed it is often violated, which is why I used to ask people about the difference in job interviews, and why I don't have much tolerance for text here that propagates such error. 2601:642:4600:D3B0:9111:FF68:B849:3D9B (talk) 15:32, 9 April 2024 (UTC)

What sentence in the article are you refuting? What should the sentence be instead? What source are you basing this change on? Timhowardriley (talk) 15:55, 9 April 2024 (UTC)

The same sentence that I quoted above! I don't see a reason that the article should say anything about choosing between GET and POST because XHR sends either just as well and this isn't an article on how to implement a RESTful service. 2601:642:4600:D3B0:9111:FF68:B849:3D9B (talk) 16:02, 9 April 2024 (UTC)