4장 XML 스키마(Schema)

출처 - http://linuxism.tistory.com/911

function setCaretPosition(ctrl, pos)
{
    if(ctrl.setSelectionRange)
    {
        ctrl.focus();
        ctrl.setSelectionRange(pos,pos);
    }
    else if (ctrl.createTextRange)
    {
        var range = ctrl.createTextRange();
        range.collapse(true);
        range.moveEnd('character', pos);
        range.moveStart('character', pos);
        range.select();
    }
}

Internet Explorer 10 및 JavaScript를 사용하는 Windows 스토어 앱은 새로운 표준에 대한 지원을 확장하고 일반적인 개발자 시나리오를 손쉽게 지원할 수 있도록 XMLHttpRequest 개체의 몇 가지 고급 기능을 제공합니다. 여기에는 다음과 같은 기능이 포함됩니다.

• 플러그 인을 사용하지 않고 이미지, 동영상 및 오디오와 같은 이진 파일을 다운로드 및 업로드합니다.
• 플러그 인을 사용하지 않고 멀티미디어 콘텐츠 스트리밍을 다운로드합니다.
• XMLHttpRequest 작업 상태를 더 잘 관찰합니다.
• 다른 브라우저와의 상호 운용성을 개선합니다.

이러한 변경 내용은 다음 섹션에서 자세히 설명합니다.

• 이진 개체 업로드 및 다운로드
• Comet 스트리밍 지원
• 고급 이벤트 지원
• XMLHttpRequest에 대한 CORS(Cross-Origin Resource Sharing)
• 관련 항목

이진 개체 업로드 및 다운로드

Internet Explorer 10에서는 XMLHttpRequest를 확장하여 이진 데이터를 지원합니다. 부분적으로 이 작업을 위해 파일 API 사양의 BLOB 인터페이스 지원을 추가합니다.

XMLHttpRequest 개체의 responseType 속성을 "blob"로 설정하면 요청과 관련된 데이터가 이진 데이터로 처리됩니다. 이 경우 다운로드 요청(예: GET)의 응답 속성 값에 영향을 줍니다.

다음 예제는 XMLHttpRequest를 사용하여 이미지를 BLOB 개체로 다운로드한 다음 그 결과를 웹 페이지의 이미지 요소에 할당하는 방법을 보여 줍니다.

var req = new XMLHttpReqest();
xhr.open("GET", "download?name=" + name, true);
xhr.responseType = "blob";
xhr.onreadystatechange = function () {
  if (xhr.readyState == xhr.DONE) {
    var blob = xhr.reponse;
    var image = document.getElementById("my-image");
    image.addEventListener("load", function (evt) {
      URL.revokeObjectURL(evt.target.src);
    }
    image.src = URL.createObjectURL(blob);
  }
}
xhr.send();

다운로드 요청에 대해 responseType 속성을 "ms-stream"으로 설정하면 다음 예제와 같이 콘텐츠를 즉석에서 처리할 수 있습니다.

var req = new XMLHttpReqest();
xhr.open("GET", "download?name=" + name, true);
xhr.responseType = "ms-stream";
xhr.onreadystatechange = function () {
  if (xhr.readyState == xhr.LOADING) {
    var stream = xhr.reponse;
    var video = document.getElementById("my-video");
    video.addEventListener("loadeddata", function (evt) {
      URL.revokeObjectURL(evt.target.src);
    }
    video.src = URL.createObjectURL(stream);
  }
}
xhr.send();

Comet 스트리밍 지원

Internet Explorer 10에서는 다음 예제와 같이 XMLHttpRequest 요청에 대한 응답을 로드하는 동안 responseText 속성을 읽을 수 있도록 하여 multipart HTTP 스트리밍(Comet 스트리밍이라고도 함)을 지원합니다.

xhr.open("GET", url);
xhr.timeout = timeout;
xhr.onreadystatechange = function() {
  if (this.readyState >= 3 && this.status == 200) {
    var content = this.responseText;
    handleContent(content);
  }
}
xhr.send();

이전 Windows Internet Explorer 버전에서는 readyState 속성이 done으로 설정된 경우에만 responseText 속성을 읽을 수 있습니다.

responseText 속성은 현재까지 읽은 응답의 전체 값을 반환합니다. 응답이 수신될 때 개별 응답 패킷을 처리하려면 다음 예제와 같이 progress 이벤트(다음 섹션에 설명됨)를 사용하거나 각 readyStateChange 이벤트 반복의 responseText 길이를 추적할 수 있습니다.

xhr.open("GET", url);
xhr.timeout = timeout;
xhr.onreadystatechange = function() {
  if (typeof this.index == "undefined")
    this.index = 0;
    
  if (this.readyState >= 3 && this.status == 200) {
    var content = this.responseText;
    handleContent( content.substring(this.index) )
    this.index = content.length;
  }
}
xhr.send();

고급 이벤트 지원

Internet Explorer 10에서는 XMLHttpRequest 개체를 확장하여 XMLHttpRequest 수준 2 사양에 지정된 다음 이벤트를 지원합니다.

XMLHttpRequest 개체의 이벤트 처리는 다음 예제와 같이 DOM 이벤트 수준 3 사양 및 진행률 이벤트 사양에 지정된 모델을 따릅니다.

var xhr = new XMLHttpRequest();
var url = "some-url";

xhr.timeout = 5000;
xhr.addEventListener("timeout", handleTimeout(evt), false);

xhr.onprogress = function(evt) {
  handleEvent("data: " + this.responseText);
  // Calculate progress 
  var str = "";
  if (evt.lengthComputable) {
    var percent = 100 * evt.loaded / evt.total;
    str = percent + "%. Current total size: " + this.responseText.length);
  } else {
    str = "Progress unknown. Current total size: " + this.responseText.length;
  }
  updateProgress(str);
}
xhr.open("GET", url);
xhr.send();

XMLHttpRequest에 대한 CORS(Cross-Origin Resource Sharing)

Internet Explorer 10에서는 XMLHttpRequest(XHR) 개체와 관련하여 CORS(Cross-Origin Resource Sharing)를 새롭게 지원합니다. CORS(Cross-Origin Resource Sharing) 사양에 정의된 CORS는 HTTP 헤더를 사용하여 대개 동일한 사이트 출처 정책으로 제한되는 도메인 간 웹 요청을 가능하게 합니다.

기본적으로 동일한 사이트 출처 정책은 웹 사이트가 다른 도메인에 있는 서버의 리소스를 요청하지 못하도록 합니다. 그러나 XMLHttpRequest(XHR) 요청에 대한 CORS를 지원하는 브라우저는 적절한 관리자가 해당 요청을 허용하도록 선택할 경우 다른 도메인의 리소스에 액세스할 수 있습니다.

웹 페이지가 XHR request를 수행하면 Internet Explorer에서 원본 헤더를 대상 서버로 보냅니다. 헤더에는 요청의 프로토콜 체계(http:// 또는 https://) 및 요청하는 웹 페이지의 호스트 이름이 포함됩니다. 대상 서버는 요청을 승인할 경우 Access-Control-Allow-Origin 헤더를 반환하며 요청을 처리할 수 있습니다.

이제 XMLHttpRequest 개체가 XHR 요청에 권한 부여 메커니즘을 포함할 수 있게 하는 withCredentials 속성을 지원합니다. 자세한 내용은 XMLHttpRequest 수준 2 사양을 참조하세요.

다음 예제와 같이 withCredentials 속성을 사용하여 CORS 지원을 검색할 수 있습니다.

var url = "http://contoso.com/services/"
if( window.XMLHttpRequest ) {
  var oReq = new XMLHttpRequest();
  if( oReq.withCredentials == undefined ) {
    oReq.open("GET", url, true);
    oReq.onload = handleResponse();
    oReq.send( null );
  } else {
  // CORS not support.  Handle fallback
  }
} else { 
  // XMLHttpRequest not supported; handle fallback
}

CORS의 실습 데모는 IE 테스트 드라이브의 실습: 사이트 간 업로드(영문)를 참조하세요.

관련 항목

DOM(문서 개체 모델)

개발자용 Internet Explorer 10 가이드

http://www.w3.org/TR/XMLHttpRequest2/#event-xhr-load

XMLHttpRequest Level 2

W3C Working Draft 17 January 2012

This Version:

http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/

Latest Version:

http://www.w3.org/TR/XMLHttpRequest/

Latest Editor Draft:

http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html

Previous Versions:

http://www.w3.org/TR/2011/WD-XMLHttpRequest2-20110816/

http://www.w3.org/TR/2010/WD-XMLHttpRequest2-20100907/

http://www.w3.org/TR/2009/WD-XMLHttpRequest2-20090820/

http://www.w3.org/TR/2008/WD-XMLHttpRequest2-20080930/

http://www.w3.org/TR/2008/WD-XMLHttpRequest2-20080225/

http://www.w3.org/TR/2007/WD-XMLHttpRequest-20071026/

http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070618/

http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/

http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060927/

http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/

http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/

Editor:

Anne van Kesteren (Opera Software ASA) <annevk@opera.com>

Table of Contents

1. 1 Introduction
   1. 1.1 Specification history
2. 2 Conformance
   1. 2.1 Dependencies
   2. 2.2 Extensibility
3. 3 Terminology
4. 4 Interface XMLHttpRequest
   1. 4.1 Origin and base URL
   2. 4.2 Task sources
   3. 4.3 Constructors
   4. 4.4 Garbage collection
   5. 4.5 Event handlers
   6. 4.6 States
   7. 4.7 Request
      1. 4.7.1 The open() method
      2. 4.7.2 The setRequestHeader() method
      3. 4.7.3 The timeout attribute
      4. 4.7.4 The withCredentials attribute
      5. 4.7.5 The upload attribute
      6. 4.7.6 The send() method
      7. 4.7.7 Infrastructure for the send() method
      8. 4.7.8 The abort() method
   8. 4.8 Response
      1. 4.8.1 The status attribute
      2. 4.8.2 The statusText attribute
      3. 4.8.3 The getResponseHeader() method
      4. 4.8.4 The getAllResponseHeaders() method
      5. 4.8.5 Response entity body
      6. 4.8.6 The overrideMimeType() method
      7. 4.8.7 The responseType attribute
      8. 4.8.8 The response attribute
      9. 4.8.9 The responseText attribute
      10. 4.8.10 The responseXML attribute
   9. 4.9 Events summary
5. 5 Interface FormData
   1. 5.1 Constructors
   2. 5.2 The append() method
6. References
   1. Normative references
7. Acknowledgments

1 Introduction

This section is non-normative.

The XMLHttpRequest object is the ECMAScript HTTP API. [ECMASCRIPT]

The name of the object is XMLHttpRequest for compatibility with the Web, though each component of this name is potentially misleading. First, the object supports any text based format, including XML. Second, it can be used to make requests over both HTTP and HTTPS (some implementations support protocols in addition to HTTP and HTTPS, but that functionality is not covered by this specification). Finally, it supports "requests" in a broad sense of the term as it pertains to HTTP; namely all activity involved with HTTP requests or responses for the defined HTTP methods.

function processData(data) {
  // taking care of data
}

function handler() {
  if(this.readyState == this.DONE) {
    if(this.status == 200 &&
       this.responseXML != null &&
       this.responseXML.getElementById('test').textContent) {
      // success!
      processData(this.responseXML.getElementById('test').textContent);
      return;
    }
    // something went wrong
    processData(null);
  }
}

var client = new XMLHttpRequest();
client.onreadystatechange = handler;
client.open("GET", "unicorn.xml");
client.send();

function log(message) {
  var client = new XMLHttpRequest();
  client.open("POST", "/log");
  client.setRequestHeader("Content-Type", "text/plain;charset=UTF-8");
  client.send(message);
}

function fetchStatus(address) {
  var client = new XMLHttpRequest();
  client.onreadystatechange = function() {
    // in case of network errors this might not give reliable results
    if(this.readyState == this.DONE)
      returnStatus(this.status);
  }
  client.open("HEAD", address);
  client.send();
}

1.1 Specification history

The XMLHttpRequest object was initially defined as part of the WHATWG's HTML effort. (Long after Microsoft shipped an implementation.) 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.

Historical discussion can be found in the following mailing list archives:

• whatwg@whatwg.org
• public-webapi@w3.org
• public-appformats@w3.org
• public-webapps@w3.org

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 Dependencies

This specification relies on several underlying specifications.

Cross-Origin Resource Sharing

A conforming user agent must support the algorithms of the Cross-Origin Resource Sharing specification. [CORS]

DOM4

A conforming user agent must support at least the subset of the functionality defined in DOM4 that this specification relies upon, such as various exceptions and EventTarget. [DOM]

File API

A conforming user agent must support at least the subset of the functionality defined in File API that this specification relies upon, such as the Blob and File interfaces. [FILEAPI]

HTML

A conforming user agent must support at least the subset of the functionality defined in HTML that this specification relies upon, such as the basics of the Window object and serializing a Document object. [HTML]

HTTP

A conforming user agent must support some version of the HTTP protocol. Requirements regarding HTTP are made throughout the specification. [HTTP]

Progress Events

A conforming user agent must support the Progress Events specification. [PROGRESSEVENTS]

Typed Array

A conforming user agent must support the ArrayBuffer object. [TYPEDARRAY]

Web IDL

A conforming user agent must also be a conforming implementation of the IDL fragments in this specification, as described in the Web IDL specification. [WEBIDL]

XML

A conforming user agent must be a conforming XML processor that reports violations of namespace well-formedness. [XML] [XMLNS]

2.2 Extensibility

User agents, Working Groups, and other interested parties are strongly encouraged to discuss new features on a relevant public forum, preferably public-webapps@w3.org. If this is for some reason not possible prefix the extension in some way. E.g. if company Foo wants to add a proprietary method bar() it could be named fooBar() to prevent clashes with a potential non-proprietary method bar().

3 Terminology

The term user credentials for the purposes of this specification means cookies, HTTP authentication, and client-side SSL certificates. Specifically it does not refer to proxy authentication or the Origin header. [COOKIES]

To deflate a DOMString into a byte sequence means to create a sequence of bytes such that the nth byte of the sequence is equal to the low-order byte of the nth code point in the original DOMString.

To inflate a byte sequence into a DOMString means to create a DOMString such that the nth code point has 0x00 as the high-order byte and the nth byte of the byte sequence as the low-order byte.

4 Interface XMLHttpRequest

[NoInterfaceObject]
interface XMLHttpRequestEventTarget : EventTarget {
  // event handlers
  [TreatNonCallableAsNull] attribute Function? onloadstart;
  [TreatNonCallableAsNull] attribute Function? onprogress;
  [TreatNonCallableAsNull] attribute Function? onabort;
  [TreatNonCallableAsNull] attribute Function? onerror;
  [TreatNonCallableAsNull] attribute Function? onload;
  [TreatNonCallableAsNull] attribute Function? ontimeout;
  [TreatNonCallableAsNull] attribute Function? onloadend;
};

interface XMLHttpRequestUpload : XMLHttpRequestEventTarget {

};

enum XMLHttpRequestResponseType {
  "",
  "arraybuffer",
  "blob",
  "document",
  "json",
  "text"
}

[Constructor]
interface XMLHttpRequest : XMLHttpRequestEventTarget {
  // event handler
  [TreatNonCallableAsNull] attribute Function? onreadystatechange;

  // states
  const unsigned short UNSENT = 0;
  const unsigned short OPENED = 1;
  const unsigned short HEADERS_RECEIVED = 2;
  const unsigned short LOADING = 3;
  const unsigned short DONE = 4;
  readonly attribute unsigned short readyState;

  // request
  void open(DOMString method, DOMString url, optional boolean async, optional DOMString? user, optional DOMString? password);
  void setRequestHeader(DOMString header, DOMString value);
           attribute unsigned long timeout;
           attribute boolean withCredentials;
  readonly attribute XMLHttpRequestUpload upload;
  void send();
  void send(ArrayBuffer data);
  void send(Blob data);
  void send(Document data);
  void send(DOMString? data);
  void send(FormData data);
  void abort();

  // response
  readonly attribute unsigned short status;
  readonly attribute DOMString statusText;
  DOMString getResponseHeader(DOMString header);
  DOMString getAllResponseHeaders();
  void overrideMimeType(DOMString mime);
           attribute XMLHttpRequestResponseType responseType;
  readonly attribute any response;
  readonly attribute DOMString responseText;
  readonly attribute Document responseXML;
};

[Constructor]
interface AnonXMLHttpRequest : XMLHttpRequest {
};

4.1 Origin and base URL

Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL.

This specification defines their values when the global object is represented by the Window object. When the XMLHttpRequest object is used in other contexts their values will have to be defined as appropriate for that context. That is considered to be out of scope for this specification.

In environments where the global object is represented by the Window object the XMLHttpRequest object has an associated XMLHttpRequest document which is the document associated with the Window object for which the XMLHttpRequest interface object was created.

The XMLHttpRequest document is used to determine the XMLHttpRequest origin and XMLHttpRequest base URL at a later stage.

4.2 Task sources

Each XMLHttpRequest object has its own task source. Namely, the XMLHttpRequest task source.

4.3 Constructors

The XMLHttpRequest object has an associated anonymous flag. If the anonymous flag is set, user credentials and the XMLHttpRequest origin are not exposed when fetching resources. It can only be set to true by using the AnonXMLHttpRequest() constructor.

client = new XMLHttpRequest()

Returns a new XMLHttpRequest object.

client = new AnonXMLHttpRequest()

Returns a new AnonXMLHttpRequest object that has the anonymous flag set.

The XMLHttpRequest() constructor must return a new XMLHttpRequest object.

The AnonXMLHttpRequest() constructor must return a new AnonXMLHttpRequest object with its anonymous flag set.

4.4 Garbage collection

An XMLHttpRequest object must not be garbage collected if its state is OPENED and the send() flag is set, its state is HEADERS_RECEIVED, or its state is LOADING, and one of the following is true:

• It has one or more event listeners registered whose type is readystatechange, progress, abort, error, load, timeout, or loadend.

• The upload complete flag is unset and the associated XMLHttpRequestUpload object has one or more event listeners registered whose type is progress, abort, error, load, timeout, or loadend.

If an XMLHttpRequest object is garbage collected while its connection is still open, the user agent must cancel any instance of the fetch algorithm opened by this object, discarding any tasks queued for them, and discarding any further data received from the network for them.

4.5 Event handlers

The following are the event handlers (and their corresponding event handler event types) that must be supported on objects implementing an interface that inherits from XMLHttpRequestEventTarget as attributes:

The following is the event handler (and its corresponding event handler event type) that must be supported as attribute solely by the XMLHttpRequest object:

4.6 States

client . readyState

Returns the current state.

The XMLHttpRequest object can be in several states. The readyState attribute must return the current state, which must be one of the following values:

UNSENT (numeric value 0)

The object has been constructed.

OPENED (numeric value 1)

The open() method has been successfully invoked. During this state request headers can be set using setRequestHeader() and the request can be made using the send() method.

HEADERS_RECEIVED (numeric value 2)

All redirects (if any) have been followed and all HTTP headers of the final response have been received. Several response members of the object are now available.

LOADING (numeric value 3)

The response entity body is being received.

DONE (numeric value 4)

The data transfer has been completed or something went wrong during the transfer (e.g. infinite redirects).

The send() flag indicates that the send() method has been invoked. It is initially unset and is used during the OPENED state.

The error flag indicates some type of network error or request abortion. It is initially unset and is used during the DONE state.

4.7 Request

The XMLHttpRequest object holds the following request metadata variables:

synchronous flag

Set when fetching is done synchronously. Initially unset.

request method

The HTTP method used in the request.

request URL

The resolved URL used in the request.

request username

The username used in the request or null if there is no username.

request password

The password used in the request or null if there is no password.

author request headers

A list consisting of HTTP header name/value pairs to be used in the request.

request entity body

The entity body used in the request or null if there is no entity body.

upload complete flag

Set when no more events are to be dispatched on the XMLHttpRequestUpload object. Initially unset.

upload events flag

Set when event listeners are registered on the XMLHttpRequestUpload object to determine whether a preflight request is needed. Initially unset.

The XMLHttpRequest object also has an associated XMLHttpRequestUpload object.

4.7.1 The open() method

client . open(method, url, async, user, password)

Sets the request method, request URL, synchronous flag, request username, and request password.

Throws a "SyntaxError" exception if one of the following is true:

• method is not a valid HTTP method.
• url cannot be resolved.
• url contains the "user:password" format in the userinfo production.

Throws a "SecurityError" exception if method is a case-insensitive match for CONNECT, TRACE or TRACK.

Throws an "InvalidAccessError" exception if one of the following is true:

• Either user or password is passed as argument and the origin of url does not match the XMLHttpRequest origin.
• There is an associated XMLHttpRequest document and either the timeout attribute is not zero, the withCredentials attribute is true, or the responseType attribute is not the empty string.

The open(method, url, async, user, password) method must run these steps (unless otherwise indicated):

1. If there is an associated XMLHttpRequest document run these substeps:

   1. If the XMLHttpRequest document is not fully active, throw an "InvalidStateError" exception and terminate the overall set of steps.

   2. Let XMLHttpRequest base URL be the document base URL of the XMLHttpRequest document.

   3. Let XMLHttpRequest origin be the origin of the XMLHttpRequest document and let it be a globally unique identifier if the anonymous flag is set.

2. If any code point in method is higher than U+00FF LATIN SMALL LETTER Y WITH DIAERESIS or after deflating method it does not match the Method token production, throw a "SyntaxError" exception and terminate these steps. Otherwise let method be the result of deflating method.

3. If method is a case-insensitive match for CONNECT, DELETE, GET, HEAD, OPTIONS, POST, PUT, TRACE, or TRACK subtract 0x20 from each byte in the range 0x61 (ASCII a) to 0x7A (ASCII z).

   If it does not match any of the above, it is passed through literally, including in the final request.

4. If method is a case-sensitive match for CONNECT, TRACE, or TRACK, throw a "SecurityError" exception and terminate these steps.

   Allowing these methods poses a security risk. [HTTPVERBSEC]

5. Let url be a URL with character encoding UTF-8.

6. Resolve url relative to the XMLHttpRequest base URL. If the algorithm returns an error, throw a "SyntaxError" exception and terminate these steps.

7. Drop <fragment> from url.

8. If the "user:password" format in the userinfo production is not supported for the relevant <scheme> and url contains this format, throw a "SyntaxError" and terminate these steps.

9. If url contains the "user:password" format let temp user be the user part and temp password be the password part.

10. If url just contains the "user" format let temp user be the user part.

11. Let async be the value of the async argument or true if it was omitted.

    If async is false, there is an associated XMLHttpRequest document and either the timeout attribute value is not zero, the withCredentials attribute value is true, or the responseType attribute value is not the empty string, throw an "InvalidAccessError" exception and terminate these steps.

12. If the user argument was not omitted follow these sub steps:

    1. If user is not null and the origin of url is not same origin with the XMLHttpRequest origin, throw an "InvalidAccessError" exception and terminate the overall set of steps.

    2. Let temp user be user.

    These steps override anything that may have been set by the url argument.

13. If the password argument was not omitted follow these sub steps:

    1. If password is not null and the origin of url is not same origin with the XMLHttpRequest origin, throw an "InvalidAccessError" exception and terminate the overall set of steps.

    2. Let temp password be password.

    These steps override anything that may have been set by the url argument.

14. Terminate the abort() algorithm.

15. Terminate the send() algorithm.

16. The user agent should cancel any network activity for which the object is responsible.

17. If there are any tasks from the object's XMLHttpRequest task source in one of the task queues, then remove them.

18. Set variables associated with the object as follows:

    • Set the request method to method.

    • Set the request URL to url.

    • If async is false, set the synchronous flag.

    • Set the request username to temp user.

    • Set the request password to temp password.

    • Empty the list of author request headers.

    • Unset the send() flag.

    • Set response entity body to null.

19. Change the state to OPENED.

20. Fire an event named readystatechange.

4.7.2 The setRequestHeader() method

client . setRequestHeader(header, value)

Appends an header to the list of author request headers, or if header is already in the list of author request headers, combines its value with value.

Throws an "InvalidStateError" exception if the state is not OPENED or if the send() flag is set.

Throws a "SyntaxError" exception if header is not a valid HTTP header field name or if value is not a valid HTTP header field value.

As indicated in the algorithm below certain headers cannot be set and are left up to the user agent. In addition there are certain other headers the user agent will take control of if they are not set by the author as indicated at the end of the send() method section.

For non same origin requests using the HTTP GET method a preflight request is made when headers other than Accept and Accept-Language are set.

The setRequestHeader(header, value) method must run these steps:

1. If the state is not OPENED, throw an "InvalidStateError" exception and terminate these steps.

2. If the send() flag is set, throw an "InvalidStateError" exception and terminate these steps.

3. If any code point in header is higher than U+00FF LATIN SMALL LETTER Y WITH DIAERESIS or after deflating header it does not match the field-name production, throw a "SyntaxError" exception and terminate these steps. Otherwise let header be the result of deflating header.

4. If any code point in value is higher than U+00FF LATIN SMALL LETTER Y WITH DIAERESIS or after deflating value it does not match the field-value production, throw a "SyntaxError" exception and terminate these steps. Otherwise let value be the result of deflating value.

   The empty string is legal and represents the empty header value.

5. Terminate these steps if header is a case-insensitive match for one of the following headers:

   • Accept-Charset
   • Accept-Encoding
   • Access-Control-Request-Headers
   • Access-Control-Request-Method
   • Connection
   • Content-Length
   • Cookie
   • Cookie2
   • Content-Transfer-Encoding
   • Date
   • Expect
   • Host
   • Keep-Alive
   • Origin
   • Referer
   • TE
   • Trailer
   • Transfer-Encoding
   • Upgrade
   • User-Agent
   • Via

   … or if the start of header is a case-insensitive match for Proxy- or Sec- (including when header is just Proxy- or Sec-).

   The above headers are controlled by the user agent to let it control those aspects of transport. This guarantees data integrity to some extent. Header names starting with Sec- are not allowed to be set to allow new headers to be minted that are guaranteed not to come from XMLHttpRequest.

6. If header is not in the author request headers list append header with its associated value to the list and terminate these steps.

7. If header is in the author request headers list either use multiple headers, combine the values or use a combination of those (section 4.2, RFC 2616). [HTTP]

See also the send() method regarding user agent header handling for caching, authentication, proxies, and cookies.

// 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

4.7.3 The timeout attribute

client . timeout

The amount of milliseconds a request can take before being terminated. Initially zero. Zero means there is no timeout.

When set: throws an "InvalidAccessError" exception if the synchronous flag is set when there is an associated XMLHttpRequest document.

The timeout attribute must return its value. Initially its value must be zero.

Setting the timeout attribute must run these steps:

1. If there is an associated XMLHttpRequest document and the synchronous flag is set, throw an "InvalidAccessError" exception and terminate these steps.

2. Set its value to the new value.

This implies that the timeout attribute can be set while fetching is in progress. If that occurs it will still be measured relative to the start of fetching.

4.7.4 The withCredentials attribute

client . withCredentials

True when user credentials are to be included in a cross-origin request. False when they are to be excluded in a cross-origin request and when cookies are to be ignored in its response. Initially false.

When set: throws an "InvalidStateError" exception if the state is not UNSENT or OPENED, or if the send() flag is set.

When set: throws an "InvalidAccessError" exception if either the synchronous flag is set when there is an associated XMLHttpRequest document or if the anonymous flag is set.

The withCredentials attribute must return its value. Initially its value must be false.

Setting the withCredentials attribute must run these steps:

1. If the state is not UNSENT or OPENED, throw an "InvalidStateError" exception and terminate these steps.

2. If the send() flag is set, throw an "InvalidStateError" exception and terminate these steps.

3. If the anonymous flag is set, throw an "InvalidAccessError" exception and terminate these steps.

4. If there is an associated XMLHttpRequest document and the synchronous flag is set, throw an "InvalidAccessError" exception and terminate these steps.

5. Set the withCredentials attribute's value to the given value.

The withCredentials attribute has no effect when fetching same-origin resources.

4.7.5 The upload attribute

client . upload

Returns the associated XMLHttpRequestUpload object.

The upload attribute must return the associated XMLHttpRequestUpload object.

4.7.6 The send() method

client . send(data)

Initiates the request. The optional argument provides the request entity body. The argument is ignored if request method is GET or HEAD.

Throws an "InvalidStateError" exception if the state is not OPENED or if the send() flag is set.

The send(data) method must run these steps (unless otherwise noted). This algorithm can be terminated by invoking the open() or abort() method. When it is terminated the user agent must terminate the algorithm after finishing the step it is on.

The send() algorithm can only be terminated if the synchronous flag is unset and only after the method call has returned.

1. If the state is not OPENED, throw an "InvalidStateError" exception and terminate these steps.

2. If the send() flag is set, throw an "InvalidStateError" exception and terminate these steps.

3. If the request method is a case-sensitive match for GET or HEAD act as if data is null.

   If the data argument has been omitted or is null, do not include a request entity body and go to the next step.

   Otherwise, let encoding be null, mime type be null, and then follow these rules:

   If data is a ArrayBuffer

   Let the request entity body be the raw data represented by data.

   If data is a Blob

   If the object's type attribute is not the empty string let mime type be its value.

   Let the request entity body be the raw data represented by data.

   If data is a Document

   Let encoding be the preferred MIME name of the character encoding of data. If encoding is UTF-16 change it to UTF-8.

   Let mime type be "application/xml" or "text/html" if Document is an HTML document, followed by ";charset=", followed by encoding.

   Let the request entity body be the result of getting the innerHTML attribute on data converted to Unicode and encoded as encoding. Re-throw any exception this throws.

   In particular, if the document cannot be serialized an "InvalidStateError" exception is thrown.

   Subsequent changes to the Document have no effect on what is transferred.

   If data is a string

   Let encoding be UTF-8.

   Let mime type be "text/plain;charset=UTF-8".

   Let the request entity body be data converted to Unicode and encoded as UTF-8.

   If data is a FormData

   Let the request entity body be the result of running the multipart/form-data encoding algorithm with data as form data set and with UTF-8 as the explicit character encoding.

   Let mime type be the concatenation of "multipart/form-data;", a U+0020 SPACE character, "boundary=", and the multipart/form-data boundary string generated by the multipart/form-data encoding algorithm.

   If a Content-Type header is in author request headers and its value is a valid MIME type that has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the charset parameters of that Content-Type header to encoding.

   If no Content-Type header is in author request headers and mime type is not null, append a Content-Type header with value mime type to author request headers.

4. If the synchronous flag is set, release the storage mutex.

5. If the synchronous flag is unset and one or more event listeners are registered on the XMLHttpRequestUpload object, set the upload events flag.

6. Unset the error flag.

7. Set the upload complete flag if there is no request entity body or if the request entity body is empty.

8. If the synchronous flag is unset, run these substeps:

   1. Set the send() flag.

   2. Fire an event named readystatechange.

      The state does not change. The event is dispatched for historical reasons.

   3. Fire a progress event named loadstart.

   4. If the upload complete flag is unset, fire a progress event named loadstart on the XMLHttpRequestUpload object.

   5. Return the send() method call, but continue running the steps in this algorithm.

9. If the XMLHttpRequest origin and the request URL are same origin

   These are the same-origin request steps.

   Fetch the request URL from origin XMLHttpRequest origin, with the synchronous flag set if the synchronous flag is set, using HTTP method request method, user request username (if non-null) and password request password (if non-null), taking into account the request entity body, list of author request headers and the rules listed at the end of this section.

   If the synchronous flag is set

   While making the request also follow the same-origin request event rules.

   The send() method call will now be returned by virtue of this algorithm ending.

   If the synchronous flag is unset

   Make upload progress notifications.

   Make progress notifications.

   While processing the request, as data becomes available and when the user interferes with the request, queue tasks to update the response entity body and follow the same-origin request event rules.

   Otherwise

   These are the cross-origin request steps.

   Make a cross-origin request, passing these as parameters:

   request URL

   The request URL.

   request method

   The request method.

   author request headers

   The list of author request headers.

   request entity body

   The request entity body.

   source origin

   The XMLHttpRequest origin.

   credentials flag

   The withCredentials attribute's value.

   force preflight flag

   True if the upload events flag is set, or false otherwise.

   Request username and request password are always ignored as part of a cross-origin request; including them would allow a site to perform a distributed password search. However, user agents will include user credentials in the request (if the user has any and if withCredentials is true).

   If the synchronous flag is set

   While making the request also follow the cross-origin request event rules.

   The send() method call will now be returned by virtue of this algorithm ending.

   If the synchronous flag is unset

   While processing the request, as data becomes available and when the end user interferes with the request, queue tasks to update the response entity body and follow the cross-origin request event rules.

If the user agent allows the end user to configure a proxy it should modify the request appropriately; i.e., connect to the proxy host instead of the origin server, modify the Request-Line and send Proxy-Authorization headers as specified.

If the user agent supports HTTP Authentication and Authorization is not in the list of author request headers, it should consider requests originating from the XMLHttpRequest object to be part of the protection space that includes the accessed URIs and send Authorization headers and handle 401 Unauthorized requests appropriately.

If authentication fails, XMLHttpRequest origin and the request URL are same origin, Authorization is not in the list of author request headers, request username is null, and request password is null, user agents should prompt the end user for their username and password.

Otherwise, if authentication fails, user agents must not prompt the end user for their username and password. [HTTPAUTH]

End users are not prompted for various cases so that authors can implement their own user interface.

If the user agent supports HTTP State Management it should persist, discard and send cookies (as received in the Set-Cookie response header, and sent in the Cookie header) as applicable. [COOKIES]

If the user agent implements a HTTP cache it should respect Cache-Control headers in author request headers (e.g. Cache-Control: no-cache bypasses the cache). It must not send Cache-Control or Pragma request headers automatically unless the end user explicitly requests such behavior (e.g. by reloading the page).

For 304 Not Modified responses that are a result of a user agent generated conditional request the user agent must act as if the server gave a 200 OK response with the appropriate content. The user agent must allow author request headers to override automatic cache validation (e.g. If-None-Match or If-Modified-Since), in which case 304 Not Modified responses must be passed through. [HTTP]

If the user agent implements server-driven content-negotiation it must follow these constraints for the Accept and Accept-Language request headers:

• Both headers must not be modified if they are in author request headers.

• If not in author request headers, Accept-Language with an appropriate value should be appended to it.

• If not in author request headers, Accept with value */* must be appended to it.

Responses must have the content-encodings automatically decoded. [HTTP]

Besides the author request headers, user agents should not include additional request headers other than those mentioned above or other than those authors are not allowed to set using setRequestHeader(). This ensures that authors have a predictable API.

4.7.7 Infrastructure for the send() method

The same-origin request event rules are as follows:

If the response has an HTTP status code of 301, 302, 303, or 307

If the redirect violates infinite loop precautions this is a network error.

Otherwise, run these steps:

1. Set the request URL to the URL conveyed by the Location header.

2. If the XMLHttpRequest origin and the origin of request URL are same origin transparently follow the redirect while observing the same-origin request event rules.

3. Otherwise, follow the cross-origin request steps and terminate the steps for this algorithm.

HTTP places requirements on the user agent regarding the preservation of the request method and request entity body during redirects, and also requires end users to be notified of certain kinds of automatic redirections.

If the end user cancels the request

This is an abort error.

If there is a network error

In case of DNS errors, TLS negotiation failure, or other type of network errors, this is a network error. Do not request any kind of end user interaction.

This does not include HTTP responses that indicate some type of error, such as HTTP status code 410.

If timeout is not 0 and since the request started the amount of milliseconds specified by timeout has passed

This is a timeout error.

Once all HTTP headers have been received, the synchronous flag is unset, and the HTTP status code of the response is not 301, 302, 303, or 307

Switch to the HEADERS_RECEIVED state.

Once the first byte (or more) of the response entity body has been received and the synchronous flag is unset

If there is no response entity body and the synchronous flag is unset

Switch to the LOADING state.

Once the whole response entity body has been received

If there is no response entity body and the state is LOADING

If there is no response entity body and the synchronous flag is set

Switch to the DONE state.

The cross-origin request event rules are as follows:

If the cross-origin request status is preflight complete and the synchronous flag is unset

Make upload progress notifications.

If the cross-origin request status is network error

This is a network error.

If the cross-origin request status is abort error

This is an abort error.

If timeout is not 0 and since the request started the amount of milliseconds specified by timeout has passed

This is a timeout error.

Once all HTTP headers have been received, the cross-origin request status is success, and the synchronous flag is unset

Switch to the HEADERS_RECEIVED state.

Make progress notifications.

Once the first byte (or more) of the response entity body has been received, the cross-origin request status is success, and the synchronous flag is unset

If there is no response entity body, the cross-origin request status is success, and the synchronous flag is unset

Switch to the LOADING state.

Once the whole response entity body has been received and the cross-origin request status is success

If there is no response entity body, the cross-origin request status is success, and the state is LOADING

If there is no response entity body, the cross-origin request status is success, and the synchronous flag is set

Switch to the DONE state.

When something is said to be a network error run the request error steps for exception "NetworkError" and event error.

When something is said to be an abort error run the request error steps for exception "AbortError" and event abort.

When something is said to be an timeout error run the request error steps for exception "TimeoutError" and event timeout.

When something is said to be a request error for exception exception and event event run these steps:

1. The user agent should cancel any network activity for which the object is responsible.

2. If there are any tasks from the object's XMLHttpRequest task source in one of the task queues, then remove them.

3. Set the the error flag.

4. Change the state to DONE.

5. If the synchronous flag is set, throw an exception exception and terminate the overall set of steps.

6. Fire an event named readystatechange.

   At this point it is clear that the synchronous flag is unset.

7. If the upload complete flag is unset, follow these substeps:

   1. Set the upload complete flag.

   2. Fire a progress event named event on the XMLHttpRequestUpload object.

   3. Fire a progress event named loadend on the XMLHttpRequestUpload object.

8. Fire a progress event named event.

9. Fire a progress event named loadend.

When it is said to switch to the HEADERS_RECEIVED state run these steps:

1. Change the state to HEADERS_RECEIVED.

2. Fire an event named readystatechange.

When it is said to switch to the LOADING state run these steps:

1. Change the state to LOADING.

2. Fire an event named readystatechange.

When it is said to switch to the DONE state run these steps:

1. If the synchronous flag is set, update the response entity body.

2. Unset the synchronous flag.

3. Change the state to DONE.

4. Fire an event named readystatechange.

5. Fire a progress event named load.

6. Fire a progress event named loadend.

When it is said to make progress notifications, while the download is progressing, queue a task to fire a progress event named progress about every 50ms or for every byte received, whichever is least frequent.

When it is said to make upload progress notifications run these steps:

• While the request entity body is being uploaded and the upload complete flag is unset, queue a task to fire a progress event named progress at the XMLHttpRequestUpload object about every 50ms or for every byte transmitted, whichever is least frequent.

• If the request entity body has been successfully uploaded and the upload complete flag is still unset, queue a task to run these substeps:

  1. Set the upload complete flag.

  2. Fire a progress event named load at the XMLHttpRequestUpload object.

  3. Fire a progress event named loadend at the XMLHttpRequestUpload object.

4.7.8 The abort() method

client . abort()

Cancels any network activity.

The abort() method must run these steps (unless otherwise noted). This algorithm can be terminated by invoking the open() method. When it is terminated the user agent must terminate the algorithm after finishing the step it is on.

The abort() algorithm can only be terminated by invoking open() from an event handler.

1. Terminate the send() algorithm.

2. The user agent should cancel any network activity for which the object is responsible.

3. If there are any tasks from the object's XMLHttpRequest task source in one of the task queues, then remove them.

4. Set the error flag.

5. Unset the synchronous flag.

6. If the state is UNSENT, OPENED with the send() flag being unset, or DONE go to the next step.

   Otherwise run these substeps:

   1. Change the state to DONE.

   2. Unset the send() flag.

   3. Fire an event named readystatechange.

   4. Fire a progress event named abort.

   5. Fire a progress event named loadend.

   6. If the upload complete flag is false run these substeps:

      1. Set the upload complete flag to true.

      2. Fire a progress event named abort on the XMLHttpRequestUpload object.

      3. Fire a progress event named loadend on the XMLHttpRequestUpload object.

7. Change the state to UNSENT.

   No readystatechange event is dispatched.

4.8 Response

4.8.1 The status attribute

client . status

Returns the HTTP status code.

The status attribute must return the result of running these steps:

1. If the state is UNSENT or OPENED, return 0 and terminate these steps.

2. If the error flag is set, return 0 and terminate these steps.

3. Return the HTTP status code.

4.8.2 The statusText attribute

client . statusText

Returns the HTTP status text.

The statusText attribute must return the result of running these steps:

1. If the state is UNSENT or OPENED, return the empty string and terminate these steps.

2. If the error flag is set, return the empty string and terminate these steps.

3. Return the HTTP status text.

4.8.3 The getResponseHeader() method

client . getResponseHeader(header)

Returns the header field value from the response of which the field name matches header, unless the field name is Set-Cookie or Set-Cookie2.

The getResponseHeader(header) method must run these steps:

1. If the state is UNSENT or OPENED, return null and terminate these steps.

2. If the error flag is set, return null and terminate these steps.

3. If any code point in header is higher than U+00FF LATIN SMALL LETTER Y WITH DIAERESIS, return null and terminate these steps.

4. Let header be the result of deflating header.

5. If header is a case-insensitive match for Set-Cookie or Set-Cookie2, return null and terminate these steps.

6. If header is a case-insensitive match for multiple HTTP response headers, return the inflated values of these headers as a single concatenated string separated from each other by a U+002C COMMA U+0020 SPACE character pair and terminate these steps.

7. If header is a case-insensitive match for a single HTTP response header, return the inflated value of that header and terminate these steps.

8. Return null.

The Cross-Origin Resource Sharing specification filters the headers that are exposed by getResponseHeader() for non same-origin requests. [CORS]

var client = new XMLHttpRequest();
client.open("GET", "unicorns-are-teh-awesome.txt", true);
client.send();
client.onreadystatechange = function() {
  if(this.readyState == 2) {
    print(client.getResponseHeader("Content-Type"));
  }
}

text/plain; charset=UTF-8

4.8.4 The getAllResponseHeaders() method

client . getAllResponseHeaders()

Returns all headers from the response, with the exception of those whose field name is Set-Cookie or Set-Cookie2.

The getAllResponseHeaders() method must run these steps:

1. If the state is UNSENT or OPENED, return the empty string and terminate these steps.

2. If the error flag is set, return the empty string and terminate these steps.

3. Return all the HTTP headers, excluding headers that are a case-insensitive match for Set-Cookie or Set-Cookie2, inflated, as a single string, with each header line separated by a U+000D CR U+000A LF pair, excluding the status line, and with each header name and header value separated by a U+003A COLON U+0020 SPACE pair.

The Cross-Origin Resource Sharing specification filters the headers that are exposed by getAllResponseHeaders() for non same-origin requests. [CORS]

var client = new XMLHttpRequest();
client.open("GET", "narwhals-too.txt", true);
client.send();
client.onreadystatechange = function() {
  if(this.readyState == 2) {
    print(this.getAllResponseHeaders());
  }
}

Date: Sun, 24 Oct 2004 04:58:38 GMT
Server: Apache/1.3.31 (Unix)
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain; charset=utf-8

4.8.5 Response entity body

The response MIME type is the MIME type the Content-Type header contains excluding any parameters, or null if the response header can not be parsed or was omitted. The override MIME type is initially null and can get a value if overrideMimeType() is invoked. Final MIME type is the override MIME type unless that is null in which case it is the response MIME type.

The response charset is the value of the charset parameter of the Content-Type header or null if there was no charset parameter or the header could not be parsed or was omitted. The override charset is initially null and can get a value if overrideMimeType() is invoked. Final charset is the override charset unless that is null in which case it is the response charset.

The response entity body is the fragment of the entity body of the response received so far (LOADING) or the complete entity body of the response (DONE). If the response does not have an entity body, the response entity body is null.

The response entity body is updated as part of the send() algorithm.

The arraybuffer response entity body is an ArrayBuffer representing the response entity body. If the arraybuffer response entity body has no value assigned to it let it be the return value of the following algorithm:

1. If the response entity body is null, return an empty ArrayBuffer object and terminate these steps.

2. Return an ArrayBuffer object representing the response entity body.

The blob response entity body is a Blob representing the response entity body. If the blob response entity body has no value assigned to it let it be the return value of the following algorithm:

1. If the response entity body is null, return an empty Blob object and terminate these steps.

2. Return a Blob object representing the response entity body.

The document response entity body is either a document representing the response entity body or null. If it is a document, its origin is the XMLHttpRequest origin. If the document response entity body has no value assigned to it let it be the return value of the following algorithm:

1. If the response entity body is null, return null and terminate these steps.

2. If final MIME type is not null, text/html, text/xml, application/xml, or does not end in +xml, return null and terminate these steps.

3. If responseType is the empty string and final MIME type is text/html, return null and terminate these steps.

   This is restricted to responseType being "document" in order to prevent breaking legacy content.

4. If final MIME type is text/html let, document be a document that represents the response entity body parsed following the rules set forth in the HTML specification for an HTML parser with scripting disabled. [HTML]

5. Otherwise, let document be a document that represents the result of parsing the response entity body following the rules set forth in the XML specifications. If that fails (unsupported character encoding, namespace well-formedness error, etc.), return null and terminate these steps. [XML] [XMLNS]

   Scripts in the resulting document tree will not be executed, resources referenced will not be loaded and no associated XSLT will be applied.

6. Return document.

The JSON response entity body is an ECMAScript value representing the response entity body. The JSON response entity body is the return value of the following algorithm:

1. Let JSON text be the response entity body decoded using UTF-8. Remove one leading U+FEFF BYTE ORDER MARK character, if present.

2. Return the result of invoking the parse function of the JSON object defined in ECMAScript, with JSON text as its only argument, or null if that function throws an exception. [ECMASCRIPT]

The text response entity body is a string representing the response entity body. The text response entity body is the return value of the following algorithm:

1. If the response entity body is null, return the empty string and terminate these steps.

2. Let charset be the final charset.

3. Let mime be the final MIME type.

4. If responseType is the empty string, charset is null, and mime is either null, text/xml, application/xml or ends in +xml, use the rules set forth in the XML specifications to determine the character encoding. Let charset be the determined character encoding. [XML] [XMLNS]

   This is restricted to responseType being the empty string to keep the non-legacy responseType value "text" simple.

5. If charset is null then, for each of the rows in the following table, starting with the first one and going down, if the first bytes of bytes match the bytes given in the first column, then let charset be the encoding given in the cell in the second column of that row. If there is no match charset remains null.

   Bytes in Hexadecimal	Description
   FE FF	UTF-16BE BOM
   FF FE	UTF-16LE BOM
   EF BB BF	UTF-8 BOM

6. If charset is null let charset be UTF-8.

7. Return the result of decoding the response entity body using charset. Replace bytes or sequences of bytes that are not valid according to the charset with a single U+FFFD REPLACEMENT CHARACTER character. Remove one leading U+FEFF BYTE ORDER MARK character, if present.

Authors are strongly encouraged to always encode their resources using UTF-8.

4.8.6 The overrideMimeType() method

client . overrideMimeType(mime)

Sets the Content-Type header for the response to mime.

Throws an "InvalidStateError" exception if the state is LOADING or DONE.

Throws a "SyntaxError" exception if mime is not a valid media type.

The overrideMimeType(mime) method must run these steps:

1. If the state is LOADING or DONE, throw an "InvalidStateError" exception and terminate these steps.

2. If parsing mime analogously to the value of the Content-Type headers fails, throw a "SyntaxError" exception and terminate these steps.

3. If a MIME type is successfully parsed set override MIME type to that MIME type, excluding any parameters.

4. If a charset parameter is successfully parsed set override charset to its value.

4.8.7 The responseType attribute

client . responseType [ = value ]

Returns the response type.

Can be set to change the response type. Values are: the empty string (default), "arraybuffer", "blob", "document", "json", and "text".

When set: throws an "InvalidStateError" exception if the state is LOADING or DONE.

When set: throws an "InvalidAccessError" exception if the synchronous flag is set and there is an associated XMLHttpRequest document.

The responseType attribute must return its value. Initially its value must be the empty string.

Setting the responseType attribute must run these steps:

1. If the state is LOADING or DONE, throw an "InvalidStateError" exception and terminate these steps.

2. If there is an associated XMLHttpRequest document and the synchronous flag is set, throw an "InvalidAccessError" exception and terminate these steps.

3. Set the responseType attribute's value to the given value.

4.8.8 The response attribute

client . response

Returns the response entity body.

The response attribute must return the result of running these steps:

If responseType is the empty string or "text"

1. If the state is not LOADING or DONE, return the empty string and terminate these steps.

2. If the error flag is set, return the empty string and terminate these steps.

3. Return the text response entity body.

Otherwise

1. If the state is not DONE, return null and terminate these steps.

2. If the error flag is set, return null and terminate these steps.

3. If responseType is "arraybuffer"

   Return the arraybuffer response entity body.

   If responseType is "blob"

   Return the blob response entity body.

   If responseType is "document"

   Return the document response entity body.

   If responseType is "json"

   Return the JSON response entity body.

4.8.9 The responseText attribute

client . responseText

Returns the text response entity body.

Throws an "InvalidStateError" exception if responseType is not the empty string or "text".

The responseText attribute must return the result of running these steps:

1. If responseType is not the empty string or "text", throw an "InvalidStateError" exception and terminate these steps.

2. If the state is not LOADING or DONE, return the empty string and terminate these steps.

3. If the error flag is set, return the empty string and terminate these steps.

4. Return the text response entity body.

4.8.10 The responseXML attribute

client . responseXML

Returns the document response entity body.

Throws an "InvalidStateError" exception if responseType is not the empty string or "document".

The responseXML attribute must return the result of running these steps:

1. If responseType is not the empty string or "document", throw an "InvalidStateError" exception and terminate these steps.

2. If the state is not DONE, return null and terminate these steps.

3. If the error flag is set, return null and terminate these steps.

4. Return the document response entity body.

The responseXML attribute has XML in its name for historical reasons. It also returns HTML resources as documents.

4.9 Events summary

This section is non-normative.

The following events are dispatched on XMLHttpRequest and/or XMLHttpRequestUpload objects:

5 Interface FormData

The FormData object represents an ordered collection of entries. Each entry has a name, a value, a type, and optionally a filename (if type is "file").

[Constructor,
 Constructor(HTMLFormElement form)]
interface FormData {
  void append(DOMString name, Blob value, optional DOMString filename);
  void append(DOMString name, DOMString value);
};

5.1 Constructors

fd = new FormData()

Returns a new FormData object.

The FormData() constructor must return a new FormData object.

The FormData(form) constructor must return a new FormData object with as entries the result of constructing the form data set for form.

5.2 The append() method

fd . append(name, value [, filename])

Appends a new name/value-pair to the FormData object, optionally with a filename.

The append(name, value, filename) method must create a new entry with the following parameters set and append it to the end of the collection the FormData object represents:

• Set its name to name.
• Set its value to value.
• Set its type to "text" if value is a string and "file" if it is a Blob.
• If its type is "file" set its filename to "blob".
• If its type is "file" and value is a File whose name attribute is not the empty string, set entry's filename to the attribute's value.
• If the filename parameter is not omitted set entry's filename to filename.

References

Normative references

Acknowledgments

The editor would like to thank Addison Phillips, Ahmed Kamel, Alex Hopmann, Alex Vincent, Alexey Proskuryakov, Asbjørn Ulsberg, Boris Zbarsky, Björn Höhrmann, Cameron McCormack, Chris Marrin, Christophe Jolif, Charles McCathieNevile, Dan Winship, David Andersson, David Flanagan, David Håsäther, David Levin, Dean Jackson, Denis Sureau, Doug Schepers, Douglas Livingstone, Elliotte Harold, Eric Lawrence, Eric Uhrhane, Erik Dahlström, Geoffrey Sneddon, Gideon Cohn, Gorm Haug Eriksen, Håkon Wium Lie, Hallvord R. M. Steen, Henri Sivonen, Huub Schaeks, Ian Davis, Ian Hickson, Ivan Herman, Jarred Nicholls, Jeff Walden, Jens Lindström, Jim Deegan, Jim Ley, Joe Farro, Jonas Sicking, Julian Reschke, 呂康豪 (Kang-Hao Lu), Karl Dubost, Lachlan Hunt, Maciej Stachowiak, Magnus Kristiansen, Marc Hadley, Marcos Caceres, Mark Baker, Mark Birbeck, Mark Nottingham, Mark S. Miller, Martin Hassman, Mohamed Zergaoui, Ms2ger, Odin Hørthe Omdal, Olli Pettay, Pawel Glowacki, Peter Michaux, Philip Taylor, Robin Berjon, Rune Halvorsen, Ruud Steltenpool, Sergiu Dumitriu, Sigbjørn Finne, Simon Pieters, Stewart Brodie, Sunava Dutta, Thomas Roessler, Tom Magliery, Yehuda Katz, and Zhenbin Xu for their contributions to this specification.

Special thanks to the Microsoft employees who first implemented the XMLHttpRequest interface, which was first widely deployed by the Windows Internet Explorer browser.

Special thanks also to the WHATWG for drafting an initial version of this specification in their Web Applications 1.0 document (now renamed to HTML). [HTML]

Thanks also to all those who have helped to improve this specification by sending suggestions and corrections. (Please, keep bugging us with your issues!)

http://www.w3.org/TR/2012/NOTE-XMLHttpRequest1-20120117/#event-handler-attributes

Abstract

The XMLHttpRequest specification defines an API that provides scripted client functionality for transferring data between a client and a server.

Status of this Document

Beware. This specification was last published as a Candidate Recommendation, but it is no longer in active maintenance, contains known errors, and the Web Applications Working Group does not intend to maintain it further. See XMLHttpRequest for the Working Group's latest specification.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the 17 January 2012 Working Group Note of XMLHttpRequest. Please send comments to public-webapps@w3.org (archived) with [XHR-NOTE] at the start of the subject line.

Publication as a W3C Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document is produced by the Web Applications (WebApps) Working Group. The WebApps Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

• 1. Introduction
• 2. Conformance Criteria
  • 2.1. Dependencies
  • 2.2. Terminology
  • 2.3. Extensibility
• 3. The XMLHttpRequest Interface
  • 3.1. Origin and Base URL
  • 3.2. Task Sources
  • 3.3. Constructors
  • 3.4. Event Handler Attributes
  • 3.5. States
  • 3.6. Request
    • 3.6.1. The open() method
    • 3.6.2. The setRequestHeader() method
    • 3.6.3. The send() method
    • 3.6.4. Infrastructure for the send() method
    • 3.6.5. The abort() method
  • 3.7. Response
    • 3.7.1. The status attribute
    • 3.7.2. The statusText attribute
    • 3.7.3. The getResponseHeader() method
    • 3.7.4. The getAllResponseHeaders() method
    • 3.7.5. Response Entity Body
    • 3.7.6. The responseText attribute
    • 3.7.7. The responseXML attribute
• 4. Exceptions
• References
• Acknowledgments

1. Introduction

This section is non-normative.

The XMLHttpRequest object implements an interface exposed by a scripting engine that allows scripts to perform HTTP client functionality, such as submitting form data or loading data from a server. It is the ECMAScript HTTP API.

The name of the object is XMLHttpRequest for compatibility with the Web, though each component of this name is potentially misleading. First, the object supports any text based format, including XML. Second, it can be used to make requests over both HTTP and HTTPS (some implementations support protocols in addition to HTTP and HTTPS, but that functionality is not covered by this specification). Finally, it supports "requests" in a broad sense of the term as it pertains to HTTP; namely all activity involved with HTTP requests or responses for the defined HTTP methods.

function test(data) {
 // taking care of data
}

function handler() {
 if(this.readyState == 4 && this.status == 200) {
  // so far so good
  if(this.responseXML != null && this.responseXML.getElementById('test').firstChild.data)
     // success!
   test(this.responseXML.getElementById('test').firstChild.data);
  else
   test(null);
 } else if (this.readyState == 4 && this.status != 200) {
  // fetched the wrong page or network error...
  test(null);
 }
}

var client = new XMLHttpRequest();
client.onreadystatechange = handler;
client.open("GET", "unicorn.xml");
client.send();

function log(message) {
 var client = new XMLHttpRequest();
 client.open("POST", "/log");
 client.setRequestHeader("Content-Type", "text/plain;charset=UTF-8");
 client.send(message);
}

function fetchStatus(address) {
 var client = new XMLHttpRequest();
 client.onreadystatechange = function() {
  // in case of network errors this might not give reliable results
  if(this.readyState == 4)
   returnStatus(this.status);
 }
 client.open("HEAD", address);
 client.send();
}

2. Conformance Criteria

Everything in this specification is normative except for diagrams, examples, notes and sections marked non-normative.

The key words must, must not, should, should not, and may in this document are to be interpreted as described in RFC 2119. [RFC2119]

This specification defines the following classes of products:

Conforming user agent

A user agent must behave as described in this specification in order to be considered conformant.

If the user agent is not a conforming XML user agent the XML response entity body must (always) be null.

User agents may implement algorithms given in this specification in any way desired, so long as the end result is indistinguishable from the result that would be obtained by the specification's algorithms.

This specification uses both the terms "conforming user agent(s)" and "user agent(s)" to refer to this product class.

Conforming XML user agent

An XML user agent must be a conforming user agent and must be a conforming XML processor that reports violations of namespace well-formedness. [XML]

2.1. Dependencies

This specification relies on several underlying specifications.

DOM

A conforming user agent must support at least the subset of the functionality defined in DOM Events and DOM Core that this specification relies upon, such as various exceptions and EventTarget. [DOM2Events] [DOM3Core]

HTML5

A conforming user agent must support at least the subset of the functionality defined in HTML5 that this specification relies upon, such as the basics of the Window object and serializing a Document object. [HTML5]

The Window Object 1.0 draft is not referenced normatively as it appears to be no longer maintained and HTML5 defines the Window object in more detail. This specification already depends on HTML5 for other reasons so there is not much additional overhead because of this.

HTTP

A conforming user agent must support some version of the HTTP protocol. Requirements regarding HTTP are made throughout the specification. [RFC2616]

Web IDL

A conforming user agent must also be a conforming implementation of the IDL fragments in this specification, as described in the Web IDL specification. [WebIDL]

2.2. Terminology

Convert a DOMString to a sequence of Unicode characters is defined by the Web IDL specification. [WebIDL]

The term user credentials for the purposes of this specification means cookies, HTTP authentication, and client-side SSL certificates. Specifically it does not refer to proxy authentication or the Origin header. [COOKIES]

The terms and algorithms <fragment>, <scheme>, cookie-free Document object, document base URL, document's character encoding, event handler attributes, event handler event type, fetch, fully active, Function, innerHTML, origin, preferred MIME name, resolve a URL, same origin, storage mutex, task, task source, task queues, URL, URL character encoding, queue a task, and valid MIME type are defined by the HTML5 specification. [HTML5]

The term entity body is used as described in RFC 2616. Method token is used as described in section 5.1.1 of RFC 2616. field-name and field-value are used as described in section 4.2 of RFC 2616. [RFC2616]

To deflate a DOMString into a byte sequence means to create a sequence of bytes such that the nth byte of the sequence is equal to the low-order byte of the nth code point in the original DOMString.

To inflate a byte sequence into a DOMString means to create a DOMString such that the nth code point has 0x00 as the high-order byte and the nth byte of the byte sequence as the low-order byte.

userinfo is used as described in section 3.2.1 of RFC 3986. [RFC3986]

To dispatch a readystatechange event means that an event with the name readystatechange, which does not bubble and is not cancelable, and which uses the Event interface, is to be dispatched at the XMLHttpRequest object.

2.3. Extensibility

User agents, Working Groups, and other interested parties are strongly encouraged to discuss extensions on a relevant public forum, preferably public-webapps@w3.org. If this is for some reason not possible prefix the extension in some way and start the prefix with an uppercase letter. E.g. if company Foo wants to add a private method bar() it could be named FooBar() to prevent clashes with a potential future standardized bar().

3. The XMLHttpRequest Interface

The XMLHttpRequest object can be used by scripts to programmatically connect to their originating server via HTTP.

[NoInterfaceObject]
interface XMLHttpRequestEventTarget : EventTarget {
  // for future use
};

[Constructor]
interface XMLHttpRequest : XMLHttpRequestEventTarget {
  // event handler attributes
           attribute Function onreadystatechange;

  // states
  const unsigned short UNSENT = 0;
  const unsigned short OPENED = 1;
  const unsigned short HEADERS_RECEIVED = 2;
  const unsigned short LOADING = 3;
  const unsigned short DONE = 4;
  readonly attribute unsigned short readyState;

  // request
  void open(DOMString method, DOMString url);
  void open(DOMString method, DOMString url, boolean async);
  void open(DOMString method, DOMString url, boolean async, DOMString? user);
  void open(DOMString method, DOMString url, boolean async, DOMString? user, DOMString? password);
  void setRequestHeader(DOMString header, DOMString value);
  void send();
  void send(Document data);
  void send([AllowAny] DOMString? data);
  void abort();

  // response
  readonly attribute unsigned short status;
  readonly attribute DOMString statusText;
  DOMString getResponseHeader(DOMString header);
  DOMString getAllResponseHeaders();
  readonly attribute DOMString responseText;
  readonly attribute Document responseXML;
};

3.1. Origin and Base URL

Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL.

This specification defines their values when the global object is represented by the Window object. When the XMLHttpRequest object is used in other contexts their values will have to be defined as appropriate for that context. That is considered to be out of scope for this specification.

In environments where the global object is represented by the Window object the XMLHttpRequest object has an associated XMLHttpRequest Document which is the Document object associated with the Window object for which the XMLHttpRequest interface object was created.

The XMLHttpRequest Document is used to determine the XMLHttpRequest origin and XMLHttpRequest base URL at a later stage.

3.2. Task Sources

The task source used by this specification is the XMLHttpRequest task source.

3.3. Constructors

client = new XMLHttpRequest()

Returns a new XMLHttpRequest object.

When the XMLHttpRequest() constructor is invoked, the user agent must return a new XMLHttpRequest object.

3.4. Event Handler Attributes

The following is the event handler attribute (and its corresponding event handler event type) that must be supported as DOM attribute by the XMLHttpRequest object:

3.5. States

client . readyState

Returns the current state.

The XMLHttpRequest object can be in several states. The readyState attribute must return the current state, which must be one of the following values:

UNSENT (numeric value 0)

The object has been constructed.

OPENED (numeric value 1)

The open() method has been successfully invoked. During this state request headers can be set using setRequestHeader() and the request can be made using the send() method.

HEADERS_RECEIVED (numeric value 2)

All redirects (if any) have been followed and all HTTP headers of the final response have been received. Several response members of the object are now available.

LOADING (numeric value 3)

The response entity body is being received.

DONE (numeric value 4)

The data transfer has been completed or something went wrong during the transfer (e.g. infinite redirects).

The OPENED state has an associated send() flag that indicates whether the send() method has been invoked. It can be either true or false and has an initial value of false.

The DONE state has an associated error flag that indicates some type of network error or abortion. It can be either true or false and has an initial value of false.

3.6. Request

The XMLHttpRequest object holds the following request metadata variables:

The asynchronous flag

True when fetching is done asychronously. False when fetching is done synchronously.

The request method

The method used in the request.

The request URL

The URL used in the request.

The request username

The username used in the request or null if there is no username.

The request password

The password used in the request or null if there is no password.

The author request headers

A list consisting of HTTP header name/value pairs to be used in the request.

The request entity body

The entity body used in the request.

3.6.1. The open() method

client . open(method, url, async, user, password)

Sets the request method, request URL, asynchronous flag, request username, and request password.

Throws a SYNTAX_ERR exception if one of the following is true:

• method is not a valid HTTP method.
• url cannot be resolved.
• url contains the "user:password" format in the userinfo production.

Throws a SECURITY_ERR exception if method is a case-insensitive match for CONNECT, TRACE or TRACK.

Throws a SECURITY_ERR exception if the origin of url does not match the XMLHttpRequest origin.

Throws a NOT_SUPPORTED_ERR exception if the <scheme> of url is not supported.

When the open(method, url, async, user, password) method is invoked, the user agent must run these steps (unless otherwise indicated):

1. If the XMLHttpRequest object has an associated XMLHttpRequest Document run these substeps:

   1. If the XMLHttpRequest Document is not fully active raise an INVALID_STATE_ERR exception and terminate the overall set of steps.

   2. Let XMLHttpRequest base URL be the document base URL of the XMLHttpRequest Document.

   3. Let XMLHttpRequest origin be the origin of the XMLHttpRequest Document.

2. If any code point in method is higher than U+00FF LATIN SMALL LETTER Y WITH DIAERESIS or after deflating method it does not match the Method token production raise a SYNTAX_ERR exception and terminate these steps. Otherwise let method be the result of deflating method.

3. If method is a case-insensitive match for CONNECT, DELETE, GET, HEAD, OPTIONS, POST, PUT, TRACE, or TRACK subtract 0x20 from each byte in the range 0x61 (ASCII a) to 0x7A (ASCII z).

   If it does not match any of the above, it is passed through literally, including in the final request.

4. If method is a case-sensitive match for CONNECT, TRACE, or TRACK raise a SECURITY_ERR exception and terminate these steps.

   Allowing these methods poses a security risk. [HTTPVERBSEC]

5. Let url be a URL.

6. Let URL character encoding of url be UTF-8.

7. Resolve url relative to the XMLHttpRequest base URL. If the algorithm returns an error raise a SYNTAX_ERR exception and terminate these steps.

8. Drop <fragment> from url.

9. If url contains an unsupported <scheme> raise a NOT_SUPPORTED_ERR and terminate these steps.

10. If the "user:password" format in the userinfo production is not supported for the relevant scheme and url contains this format raise a SYNTAX_ERR and terminate these steps.

11. If url contains the "user:password" format let temp user be the user part and temp password be the password part.

12. If url just contains the "user" format let temp user be the user part.

13. If the origin of url is not same origin with the XMLHttpRequest origin raise a SECURITY_ERR exception and terminate these steps.

14. Let async be the value of the async argument or true if it was omitted.

15. If the user argument was not omitted follow these sub steps:

    1. If user is null let temp user be null.

    2. Otherwise let temp user be user.

    These steps override anything that may have been set by the url argument.

16. If the password argument was not omitted follow these sub steps:

    1. If password is null let temp password be null.

    2. Otherwise let temp password be password.

    These steps override anything that may have been set by the url argument.

17. Abort the send() algorithm.

18. The user agent should cancel any network activity for which the object is responsible.

19. If there are any tasks from the object's XMLHttpRequest task source in one of the task queues, then remove those tasks.

20. Set variables associated with the object as follows:

    • Set the send() flag to false.

    • Set response entity body to null.

    • Empty the list of author request headers.

    • Set the request method to method.

    • Set the request URL to url.

    • Set the request username to temp user.

    • Set the request password to temp password.

    • Set the asynchronous flag to the value of async.

21. Switch the the state to OPENED.

22. Dispatch a readystatechange event.

3.6.2. The setRequestHeader() method

client . setRequestHeader(header, value)

Appends an header to the list of author request headers or if the header is already in the author request headers its value appended to.

Throws an INVALID_STATE_ERR exception if the state is not OPENED or if the send() flag is true.

Throws a SYNTAX_ERR exception if header is not a valid HTTP header field name or if value is not a valid HTTP header field value.

As indicated in the algorithm below certain headers cannot be set and are left up to the user agent. In addition there are certain other headers the user agent will take control of if they are not set by the author as indicated at the end of the send() method section.

When the setRequestHeader(header, value) method is invoked, the user agent must run these steps:

1. If the state is not OPENED raise an INVALID_STATE_ERR exception and terminate these steps.

2. If the send() flag is true raise an INVALID_STATE_ERR exception and terminate these steps.

3. If any code point in header is higher than U+00FF LATIN SMALL LETTER Y WITH DIAERESIS or after deflating header it does not match the field-name production raise a SYNTAX_ERR exception and terminate these steps. Otherwise let header be the result of deflating header.

4. If any code point in value is higher than U+00FF LATIN SMALL LETTER Y WITH DIAERESIS or after deflating value it does not match the field-value production raise a SYNTAX_ERR exception and terminate these steps. Otherwise let value be the result of deflating value.

   The empty string is legal and represents the empty header value.

5. Terminate these steps if header is a case-insensitive match for one of the following headers:

   • Accept-Charset
   • Accept-Encoding
   • Connection
   • Content-Length
   • Cookie
   • Cookie2
   • Content-Transfer-Encoding
   • Date
   • Expect
   • Host
   • Keep-Alive
   • Referer
   • TE
   • Trailer
   • Transfer-Encoding
   • Upgrade
   • User-Agent
   • Via

   … or if the start of header is a case-insensitive match for Proxy- or Sec- (including when header is just Proxy- or Sec-).

   The above headers are controlled by the user agent to let it control those aspects of transport. This guarantees data integrity to some extent. Header names starting with Sec- are not allowed to be set to allow new headers to be minted that are guaranteed not to come from XMLHttpRequest.

6. If header is not in the author request headers list append header with its associated value to the list and terminate these steps.

7. If header is in the author request headers list either use multiple headers, combine the values or use a combination of those (section 4.2, RFC 2616). [RFC2616]

See also the send() method regarding user agent header handling for caching, authentication, proxies, and cookies.

// The following script:
var client = new XMLHttpRequest();
client.open('GET', 'demo.cgi');
client.setRequestHeader('X-Test', 'one');
client.setRequestHeader('X-Test', 'two');
client.send();

// ...would result in the following header being sent:
...
X-Test: one, two
...

3.6.3. The send() method

client . send(data)

Initiates the request. The optional argument provides the request entity body. The argument is ignored if request method is GET or HEAD.

Throws an INVALID_STATE_ERR exception if the state is not OPENED or if the send() flag is true.

When the send(data) method is invoked, the user agent must run the following steps (unless otherwise noted). This algorithm gets aborted when the open() or abort() method is invoked. When the send() algorithm is aborted the user agent must terminate the algorithm after finishing the step it is on.

The send() algorithm can only be aborted when the asynchronous flag is true and only after the method call has returned.

1. If the state is not OPENED raise an INVALID_STATE_ERR exception and terminate these steps.

2. If the send() flag is true raise an INVALID_STATE_ERR exception and terminate these steps.

3. If the request method is a case-sensitive match for GET or HEAD act as if data is null.

   If the data argument has been omitted or is null, do not include a request entity body and go to the next step.

   Otherwise, let encoding be null, mime type be null, and then follow these rules:

   If data is a Document

   Let encoding be the preferred MIME name of the character encoding of data. If encoding is UTF-16 change it to UTF-8.

   Let mime type be "application/xml;charset=" followed by encoding.

   Let the request entity body be the result of getting the innerHTML attribute on data converted to Unicode and encoded as encoding. Re-raise any exception this raises.

   In particular, if the document cannot be serialized an INVALID_STATE_ERR exception is raised.

   Subsequent changes to the Document have no effect on what is submitted.

   If data is a DOMString

   Let encoding be UTF-8.

   Let mime type be "text/plain;charset=UTF-8".

   Let the request entity body be data converted to Unicode and encoded as UTF-8.

   If a Content-Type header is set using setRequestHeader() whose value is a valid MIME type and has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the charset parameters of the Content-Type header to encoding.

   If no Content-Type header has been set using setRequestHeader() and mime type is not null set a Content-Type request header with as value mime type.

4. If the asynchronous flag is false release the storage mutex.

5. Set the error flag to false.

6. If the asynchronous flag is true run these substeps:

   1. Set the send() flag to true.

   2. Dispatch a readystatechange event.

      The state does not change. The event is dispatched for historical reasons.

   3. Return the send() method call, but continue running the steps in this algorithm.

7. Fetch the request URL from origin XMLHttpRequest origin, with the synchronous flag set if the asynchronous flag is false, using HTTP method request method, user request username (if non-null) and password request password (if non-null), taking into account the request entity body, list of author request headers and the rules listed at the end of this section.

   If the asynchronous flag is false

   While making the request also follow the same-origin request event rules.

   The send() method call will now be returned by virtue of this algorithm ending.

   If the asynchronous flag is true

   Make progress notifications.

   Make upload progress notifications.

   While processing the request, as data becomes available and when the user interferes with the request, queue tasks to update the response entity body and follow the same-origin request event rules.

If the user agent allows the end user to configure a proxy it should modify the request appropriately; i.e., connect to the proxy host instead of the origin server, modify the Request-Line and send Proxy-Authorization headers as specified.

If the user agent supports HTTP Authentication and Authorization is not in the list of author request headers, it should consider requests originating from the XMLHttpRequest object to be part of the protection space that includes the accessed URIs and send Authorization headers and handle 401 Unauthorized requests appropriately.

If authentication fails, Authorization is not in the list of author request headers, request username is null, and request password is null, user agents should prompt the end user for their username and password.

If authentication fails, Authorization is not in the list of author request headers, request username is non-null, and request password is non-null, user agents must not prompt the end user for their username and password. [RFC2617]

End users are not prompted if username/password are provided through the open() API so that authors can implement their own user interface.

If the user agent supports HTTP State Management it should persist, discard and send cookies (as received in the Set-Cookie and Set-Cookie2 response headers, and sent in the Cookie header) as applicable. [COOKIES]

If the user agent implements a HTTP cache it should respect Cache-Control request headers set by the setRequestHeader() (e.g., Cache-Control: no-cache bypasses the cache). It must not send Cache-Control or Pragma request headers automatically unless the end user explicitly requests such behavior (e.g. by reloading the page).

For 304 Not Modified responses that are a result of a user agent generated conditional request the user agent must act as if the server gave a 200 OK response with the appropriate content. The user agent must allow setRequestHeader() to override automatic cache validation by setting request headers (e.g. If-None-Match or If-Modified-Since), in which case 304 Not Modified responses must be passed through. [RFC2616]

If the user agent implements server-driven content-negotiation it should set Accept-Encoding and Accept-Charset headers as appropriate. For Accept and Accept-Language the user agent must follow these constraints:

• Both headers must not be modified if they are already set through setRequestHeader().

• If not set through setRequestHeader() Accept-Language should be set as appropriate.

• If not set through setRequestHeader() Accept must be set with as value */*.

Responses must have the content-encodings automatically decoded. [RFC2616]

Besides the author request headers user agents should not include additional request headers other than those mentioned above or other than those authors are not allowed to set using setRequestHeader(). This ensures that authors have a reasonably predictable API.

3.6.4. Infrastructure for the send() method

The same-origin request event rules are as follows:

If the response has an HTTP status code of 301, 302, 303, or 307

If the origin of the URL conveyed by the Location header is same origin with the XMLHttpRequest origin and the redirect does not violate infinite loop precautions, transparently follow the redirect while observing the same-origin request event rules.

Otherwise, this is a network error.

HTTP places requirements on the user agent regarding the preservation of the request method and request entity body during redirects, and also requires end users to be notified of certain kinds of automatic redirections.

If the end user cancels the request

This is an abort error.

If there is a network error

In case of DNS errors, TLS negotiation failure, or other type of network errors, this is a network error. Do not request any kind of end user interaction.

This does not include HTTP responses that indicate some type of error, such as HTTP status code 410.

Once all HTTP headers have been received and the asynchronous flag is true (and this is not an HTTP redirect)

Switch to the HEADERS_RECEIVED state.

Once the first byte (or more) of the response entity body has been received and the asynchronous flag is true

If there is no response entity body and the asynchronous flag is true

Switch to the LOADING state.

Once the whole response entity body has been received

If there is no response entity body and the asynchronous flag is false or the state is LOADING

Switch to the DONE state.

When something is said to be a network error run the request error steps for exception NETWORK_ERR.

When something is said to be an abort error run the request error steps for exception ABORT_ERR.

When something is said to be a request error for exception exception run these steps:

1. The user agent should cancel any network activity for which the object is responsible.

2. If there are any tasks from the object's XMLHttpRequest task source in one of the task queues, then remove those tasks.

3. Set the response entity body to null.

4. Empty the list of author request headers.

5. Set the the error flag to true.

6. Switch the state to DONE.

7. If the asynchronous flag is false raise an exception exception and terminate the overall set of steps.

8. Dispatch a readystatechange event.

   At this point it is clear that the asynchronous flag is true.

9. Terminate the overall algorithm.

A future version of this specification will dispatch an error/abort event here as well. (Depending on the type of error.)

When it is said to switch to the HEADERS_RECEIVED state run these steps:

1. Switch the state to HEADERS_RECEIVED.

2. Dispatch a readystatechange event.

When it is said to switch to the LOADING state run these steps:

1. Switch the state to LOADING.

2. Dispatch a readystatechange event.

When it is said to switch to the DONE state run these steps:

1. If the asynchronous flag is false update the response entity body.

2. Switch the state to DONE.

3. Dispatch a readystatechange event.

3.6.5. The abort() method

client . abort()

Cancels any network activity.

When the abort() method is invoked, the user agent must run these steps (unless otherwise noted):

1. Abort the send() algorithm.

2. The user agent should cancel any network activity for which the object is responsible.

3. If there are any tasks from the object's XMLHttpRequest task source in one of the task queues, then remove those tasks.

4. Set the response entity body to null.

5. Empty the list of author request headers.

6. Set the error flag to true.

7. If the state is UNSENT, OPENED with the send() flag being false, or DONE go to the next step.

   Otherwise run these substeps:

   1. Switch the state to DONE.

   2. Set the send() flag to false.

   3. Dispatch a readystatechange event.

   A future version of this specification will dispatch an abort event here.

8. Switch the state to UNSENT.

   No readystatechange event is dispatched.