1.1. Specification history

The XMLHttpRequest object was initially defined as part of
the WHATWG’s HTML effort. (Based on Microsoft’s implementation many years prior.)
It moved to the W3C in 2006. Extensions (e.g. progress events and
cross-origin requests) to XMLHttpRequest were developed in a
separate draft (XMLHttpRequest Level 2) until end of 2011, at which point
the two drafts were merged and XMLHttpRequest became a single
entity again from a standards perspective. End of 2012 it moved back to the
WHATWG.

Discussion that led to the current draft can be found in the following mailing list
archives:

2. Conformance

All diagrams, examples, and notes in this specification are
non-normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in the normative parts of this specification are to be
interpreted as described in RFC2119. For readability, these words do
not appear in all uppercase letters in this specification. [RFC2119]

2.1. Extensibility

User agents, Working Groups, and other interested parties are strongly encouraged to discuss new features with the WHATWG
community.

Synchronous XMLHttpRequest outside of workers is
in the process of being removed from the web platform as it has detrimental effects to the end
user’s experience. (This is a long process that takes many years.) Developers must not pass false
for the async argument when current global object is a Window object. User
agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an "InvalidAccessError" DOMException when it occurs.

The open(method, url) and open(method, url, async, username, password) methods, when invoked, must run these steps:

Some simple code demonstrating what happens when setting the same
header twice:

// The following script:var client =new XMLHttpRequest();
client.open('GET','demo.cgi');
client.setRequestHeader('X-Test','one');
client.setRequestHeader('X-Test','two');
client.send();// …results in the following header being sent:// X-Test: one, two

To fire a progress event named e at target, given transmitted and length, means to fire an event named e at target, using ProgressEvent, with the loaded attribute initialized to transmitted, and if length is not 0, with the lengthComputable attribute initialized to true and the total attribute initialized to length.

The suggested type attribute values for use with events using the ProgressEvent interface are summarized in the table below.
Specification editors are free to tune the details to their specific
scenarios, though are strongly encouraged to discuss their usage with the
WHATWG community to ensure input from people familiar with the subject.

Throughout the web platform the error, abort, timeout and load event types have
their bubbles and cancelable attributes initialized to false, so it is suggested that for consistency all events using the ProgressEvent interface do the same.

6.3. Security considerations

For cross-origin requests some kind of opt-in, e.g. the CORS protocol defined in the Fetch Standard, has to be
used before events using the ProgressEvent interface are dispatched as information (e.g. size) would be revealed that cannot be obtained
otherwise. [FETCH]

6.4. Example

In this example XMLHttpRequest, combined with concepts
defined in the sections before, and the HTML progress element are used together to
display the process of fetching a resource.