맨위로가기

XMLHttpRequest

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

XMLHttpRequest는 웹 페이지에서 서버로 데이터를 전송하고 서버로부터 데이터를 수신하기 위한 API이다. 마이크로소프트가 1999년 Internet Explorer 5에서 ActiveX 객체로 처음 구현했으며, 이후 여러 브라우저에서 사실상 표준으로 채택되었다. XMLHttpRequest는 요청을 보내고 응답을 처리하는 다양한 메서드, 이벤트 핸들러, 프로퍼티를 제공하며, GET, POST 방식의 요청을 지원한다. 동일 출처 정책으로 인해 크로스 도메인 요청에 제한이 있지만, JSONP, CORS 등을 통해 이를 우회할 수 있다. 롱 폴링 기술을 사용하여 서버에서 데이터를 실시간으로 수신할 수 있으며, ECMAScript 2015 (ES6) 이후에는 Promise 기반의 Fetch API가 XMLHttpRequest를 대체하는 방법으로 사용되고 있다.

더 읽어볼만한 페이지

  • 마이크로소프트 이니셔티브 - 차세대 보안 컴퓨팅 기반
    차세대 보안 컴퓨팅 기반(NGSCB)은 마이크로소프트가 설계한 하드웨어 및 소프트웨어 보안 아키텍처로, 개인 정보 보호, 보안 강화, 디지털 권리 관리를 목표로 커튼 메모리, 신뢰 플랫폼 모듈(TPM), Nexus 보안 커널을 활용하는 특징을 가지나, 다양한 비판에 직면하여 윈도우 비스타의 BitLocker 드라이브 암호화 기능으로 일부 축소 구현되었다.
  • 마이크로소프트 이니셔티브 - 마이크로소프트 이매진
    마이크로소프트 이매진은 학생들에게 마이크로소프트의 개발 도구, 소프트웨어, 클라우드 서비스 및 학습 자료를 제공하는 프로그램으로, 원래 드림스파크라는 이름으로 시작되었으며 학생 인증을 통해 무료로 이용 가능하다.
  • XML - 오피스 오픈 XML
    오피스 오픈 XML은 마이크로소프트에서 개발한 XML 기반의 파일 포맷으로, 문서, 스프레드시트, 프레젠테이션 등의 사무용 전자 문서를 표현하기 위해 사용되며 마이크로소프트 오피스 2007부터 기본 파일 형식으로 채택되어 ECMA 인터내셔널 및 ISO/IEC 국제 표준으로도 표준화되었다.
  • XML - 자원 기술 프레임워크
    자원 기술 프레임워크(RDF)는 웹 상의 메타데이터를 표현하기 위한 표준 모델로, URI 기반의 리소스와 트리플 구조의 속성을 사용하여 정보 자원 간의 관계를 명확하게 기술하며, 시맨틱 웹 구축의 핵심 기술로서 다양한 분야에서 활용된다.
  • 자바스크립트 - HTML
    HTML은 웹 페이지 제작을 위한 표준 마크업 언어로서, 팀 버너스리가 제안하고 구현한 후 인터넷 발전과 함께 널리 사용되며, SGML에 기반하여 하이퍼텍스트 기능으로 다양한 콘텐츠를 표현하고 연결하며, W3C와 WHATWG에서 표준화를 진행하고 최신 버전은 HTML Living Standard이다.
  • 자바스크립트 - 비주얼 스튜디오
    비주얼 스튜디오는 마이크로소프트가 개발한 통합 개발 환경(IDE)으로, 다양한 프로그래밍 언어와 플랫폼을 지원하며 소프트웨어 개발에 필요한 도구와 기능을 제공한다.
XMLHttpRequest
개요
종류Web API
설명웹 브라우저와 웹 서버 간에 데이터를 전송하는 데 사용됨
기술적 세부 사항
특징지속성
압축
HTTPS
QUIC
요청 방식OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
PATCH
헤더 필드쿠키
ETag
위치
리퍼러
DNT
XFF
상태 코드301 Moved Permanently
302 Found
303 See Other
403 Forbidden
404 Not Found
451 Unavailable For Legal Reasons
보안 접근 제어 방식기본 접근 인증
다이제스트 접근 인증
보안 취약점
보안 취약점 종류HTTP 헤더 주입
HTTP 요청 스머글링
HTTP 응답 분할
HTTP 파라미터 오염
추가 정보
관련 기술HTML
JSON
YAML
XMLHttpRequest
ASM.JS
WASM
WebGL

2. 역사

XMLHttpRequest 오브젝트의 개념은 마이크로소프트가 마이크로소프트 익스체인지 서버 2000용 아웃룩 웹 액세스를 개발하면서 만들었다.[26][3] 이 개념은 MSXML의 두 번째 버전에 구현되었고, 1999년 3월 인터넷 익스플로러 5.0에 포함되었다.[26][27][28][17] 초기에는 `ActiveXObject("Msxml2.XMLHTTP")` 및 `ActiveXObject("Microsoft.XMLHTTP")` 식별자를 사용했다.[4]

이후 모질라는 2001년에 Mozilla 0.9.7 및 Netscape 7에서 호환되는 내장 객체를 구현했고, Apple은 2004년 사파리 1.2에서, 오페라 소프트웨어는 2005년 오페라 8에서 XMLHttpRequest를 내장 객체로 구현했다.[18][19] 2006년 인터넷 익스플로러 7부터는 `XMLHttpRequest` 식별자를 표준으로 지원하게 되었다.[4][19]

2005년 Ajax가 유명해지면서 XMLHttpRequest는 널리 사용되기 시작했다. 웹 브라우저에서 구현된 사실상의 표준이 되면서, 월드 와이드 웹 컨소시엄(W3C)에서 사양 표준화가 진행되어 [https://www.w3.org/TR/XMLHttpRequest/ XMLHttpRequest Level 1] 및 [https://www.w3.org/TR/XMLHttpRequest2/ XMLHttpRequest Level 2]가 제정되기 시작했다. 2014년 11월 18일, Level 2는 Level 1에 통합되었고, 이후 사양 제정은 WHATWG에서 논의하기로 했다.[20] 현재는 WHATWG의 [https://xhr.spec.whatwg.org/ XMLHttpRequest Living Standard]가 사양으로 취급되고 있다.

2. 1. 마이크로소프트의 기여

XMLHttpRequest 오브젝트의 개념은 원래 마이크로소프트 익스체인지 서버 2000용 아웃룩 웹 액세스의 개발자들이 만들었다.[26] IXMLHTTPRequest라는 인터페이스가 개발되어 이 개념을 사용하는 MSXML의 두 번째 버전에 구현되었다.[26][27] MSXML 라이브러리의 두 번째 버전은 1999년 3월 인터넷 익스플로러 5.0에 포함되었으며, MSXML 라이브러리의 XMLHTTP 래퍼를 사용하여 액티브X를 통해 IXMLHTTPRequest 인터페이스에 접근할 수 있었다.[28]

인터넷 익스플로러 7 (2006년)부터는 `XMLHttpRequest` 식별자를 지원한다.[4] 마이크로소프트는 2006년에 출시된 인터넷 익스플로러 7에서 사용자가 액티브X를 비활성화해도 Ajax 애플리케이션을 이용할 수 있도록 XMLHttpRequest를 내장 객체로 표준 구현했다.[19]

2. 2. 타 브라우저의 도입

모질라는 2001년에 XMLHttpRequest와 호환되는 내장 객체를 Mozilla 0.9.7 및 Netscape 7에서 구현했다.[18] Apple은 2004년 사파리 1.2에서 Mozilla와 유사한 내장 객체를 구현하기 시작했고,[18] 오페라 소프트웨어는 2005년 XMLHttpRequest를 내장 객체로 구현한 오페라 8을 출시했다.[19]

2. 3. 표준화 과정

월드 와이드 웹 컨소시엄(W3C)은 2006년 4월 5일에 ''XMLHttpRequest'' 객체에 대한 ''작업 초안'' 사양을 발표했다.[7] 이 표준은 오페라 소프트웨어의 앤 반 케스테렌과 W3C의 딘 잭슨이 편집했다. 2008년 2월 25일, W3C는 ''작업 초안 레벨 2'' 사양을 발표했다.[8] 레벨 2에서는 이벤트 진행 상황 모니터링, 사이트 간 요청 허용, 바이트 스트림 처리 메서드가 추가되었다. 2011년 말에 레벨 2 사양은 원래 사양에 통합되었다.[9]

2012년 말에 WHATWG가 개발을 인수하여 웹 IDL을 사용하여 리빙 문서를 관리한다.[10] W3C에서 사양 표준화가 진행되어 [https://www.w3.org/TR/XMLHttpRequest/ XMLHttpRequest Level 1] 및 [https://www.w3.org/TR/XMLHttpRequest2/ XMLHttpRequest Level 2]가 제정되기 시작했다. 그 후, 2014년 11월 18일에 Level 2가 폐지되어 Level 1에 통합되었다. 또한, 향후 사양 제정은 WHATWG에서 논의하기로 했다.[20]

그 이후, WHATWG의 [https://xhr.spec.whatwg.org/ XMLHttpRequest Living Standard]가 사양으로 취급되고 있다.

3. 객체 구성

XMLHttpRequest는 요청을 보내는 방법과 응답을 처리하는 방법을 제어하는 다양한 옵션을 제공한다. 사용자 정의 HTTP 헤더를 추가하거나, 서버에 데이터를 업로드할 수 있다. 응답은 JSON 형식으로 바로 사용하거나, 점진적으로 처리할 수 있다. 요청은 조기에 중단하거나 지정된 시간 내에 완료되지 않으면 실패하도록 설정할 수 있다.[11]

XMLHttpRequest 객체는 다음과 같은 주요 구성 요소를 가진다.


  • 메서드: `abort`, `getAllResponseHeaders`, `getResponseHeader`, `open`, `overrideMimeType`, `send`, `setRequestHeader` 등의 메서드를 통해 요청을 제어한다.
  • 이벤트 핸들러: `onloadstart`, `onprogress`, `onabort`, `onerror`, `onload`, `ontimeout`, `onloadend`, `onreadystatechange` 등의 이벤트 핸들러를 통해 요청의 상태 변화에 대응한다.
  • 프로퍼티: `readyState`, `response`, `responseText`, `responseType`, `responseXML`, `status`, `statusText`, `timeout`, `upload`, `withCredentials` 등의 프로퍼티를 통해 요청 및 응답 정보를 확인한다.

3. 1. 메서드


  • abort: 요청을 중단한다.[11]
  • getAllResponseHeaders: 모든 응답 헤더를 가져온다.[11]
  • getResponseHeader: 특정 응답 헤더를 가져온다.[11]
  • open: 요청을 초기화한다.[11]
  • overrideMimeType: 응답의 MIME 타입을 재정의한다.[11]
  • send: 요청을 보낸다.[11]
  • setRequestHeader: 요청 헤더를 설정한다.[11]

3. 2. 이벤트 핸들러


  • onloadstart: 요청이 시작될 때 발생한다.[11]
  • onprogress: 데이터 수신 중에 주기적으로 발생한다.[11]
  • onabort: 요청이 중단될 때 발생한다.[11]
  • onerror: 요청 중 오류가 발생할 때 발생한다.[11]
  • onload: 요청이 성공적으로 완료될 때 발생한다.[11]
  • ontimeout: 요청 시간이 초과될 때 발생한다.[11]
  • onloadend: 요청이 완료(성공 또는 실패)될 때 발생한다.[11]
  • onreadystatechange: readyState 프로퍼티가 변경될 때마다 발생한다.[11]

3. 3. 프로퍼티

XMLHttpRequest 객체의 주요 프로퍼티는 다음과 같다:[11]

프로퍼티설명
readyState요청의 현재 상태를 나타낸다. 가능한 값은 다음과 같다.
response서버로부터 받은 응답 데이터를 포함한다. `responseType`에 따라 데이터 형식이 달라진다.
responseText서버로부터 받은 응답 데이터를 텍스트 형식으로 포함한다.
responseType서버로부터 받을 응답 데이터의 타입을 지정한다. `arraybuffer`, `blob`, `document`, `json`, `text` 등의 값을 사용할 수 있다.
responseXML서버로부터 받은 응답 데이터를 XML 형식으로 포함한다. 응답 데이터가 XML 형식이 아니거나 파싱에 실패하면 `null` 값을 가진다.
status서버로부터 받은 HTTP 응답 상태 코드를 나타낸다. (예: 200, 404, 500 등)
statusText서버로부터 받은 HTTP 응답 상태 메시지를 나타낸다. (예: "OK", "Not Found", "Internal Server Error" 등)
timeout요청이 완료될 때까지 기다리는 최대 시간(밀리초 단위)을 설정한다. 이 시간 안에 응답을 받지 못하면 요청이 자동으로 중단된다.
upload파일 업로드 등의 진행 상황을 추적하는 데 사용되는 객체이다. `onprogress`, `onload`, `onerror` 등의 이벤트 핸들러를 등록하여 업로드 상태를 확인할 수 있다.
withCredentials요청에 인증 정보(쿠키, HTTP 인증 헤더 등)를 포함할지 여부를 설정한다. 기본값은 `false`이다.


4. 사용법

`XMLHttpRequest`를 사용하여 요청을 보내는 일반적인 단계는 다음과 같다.[11]

1. 생성자를 호출하여 `XMLHttpRequest` 객체를 생성한다.

2. `open` 메서드를 호출하여 요청 유형, 관련 리소스, 동기 또는 비동기 작업 여부를 지정한다.

3. 비동기 요청의 경우, 요청 상태가 변경될 때 알림을 받을 리스너를 설정한다.

4. `send` 메서드를 호출하여 요청을 시작한다.

5. 이벤트 리스너에서 상태 변경에 응답한다. 서버가 응답 데이터를 보내면 `responseText` 속성에 캡처된다. 응답 처리가 완료되면 상태가 4("완료")로 변경된다.

`XMLHttpRequest`는 요청 및 응답 처리 방법을 제어하는 다양한 옵션을 제공한다. 사용자 정의 HTTP 헤더를 추가하거나, `send` 호출 시 데이터를 제공하여 서버에 업로드할 수 있다. 응답은 JSON 형식의 JavaScript 객체로 파싱하거나, 전체 텍스트를 기다리지 않고 점진적으로 처리할 수 있다. 요청을 조기에 중단하거나 지정된 시간 내에 완료되지 않으면 실패하도록 설정할 수도 있다.

4. 1. 객체 생성

XMLHttpRequest 객체를 생성하는 방법은 브라우저에 따라 다를 수 있다.

일반적으로 XMLHttpRequest를 사용하여 요청을 보내는 과정은 다음과 같다.[11]

1. 생성자를 호출하여 XMLHttpRequest 객체를 생성한다.

2. `open` 메서드를 호출하여 요청 유형을 지정하고, 관련 리소스를 식별하며, 동기 또는 비동기 작업을 선택한다.

3. 비동기 요청의 경우, 요청 상태가 변경될 때 알림을 받을 리스너를 설정한다.

4. `send` 메서드를 호출하여 요청을 시작한다.

5. 이벤트 리스너에서 상태 변경에 응답한다. 서버가 응답 데이터를 보내면 기본적으로 `responseText` 속성에 캡처된다. 객체가 응답 처리를 중지하면 상태가 4("완료")로 변경된다.

XMLHttpRequest는 요청 및 응답 처리 방법을 제어하는 다양한 옵션을 제공한다. 사용자 정의 HTTP 헤더를 추가하거나, `send` 호출 시 데이터를 제공하여 서버에 업로드할 수 있다. 응답은 JSON 형식의 JavaScript 객체로 파싱하거나, 전체 텍스트를 기다리지 않고 점진적으로 처리할 수 있다. 요청을 조기에 중단하거나 지정된 시간 내에 완료되지 않으면 실패하도록 설정할 수도 있다.

Internet Explorer 5 및 6에서는 ActiveX 객체를 통해서만 XMLHttpRequest를 사용할 수 있다. 따라서 다음과 같은 코드가 사용되기도 한다.

```javascript

var xhr;

if (XMLHttpRequest) {

// 내장 객체가 있으면 그것을 사용

xhr = new XMLHttpRequest();

} else {

// 없으면 ActiveX 객체를 사용

try {

xhr = new ActiveXObject('MSXML2.XMLHTTP.6.0');

} catch (e) {

try {

xhr = new ActiveXObject('MSXML2.XMLHTTP.3.0');

} catch (e) {

try {

xhr = new ActiveXObject('MSXML2.XMLHTTP');

} catch (e) {

alert("ActiveX를 활성화하십시오");

}

}

}

}

```

마이크로소프트 XML 팀은 MSXML 버전 중 6.0을 최적으로, 3.0을 차선으로 권장한다.[21]

가독성과 편리성을 위해 함수화한 아래 코드도 사용된다.

```javascript

function createXMLHttpRequest(){

if(window.XMLHttpRequest){return new XMLHttpRequest()}

if(window.ActiveXObject){

try{return new ActiveXObject("Msxml2.XMLHTTP.6.0")}catch(e){}

try{return new ActiveXObject("Msxml2.XMLHTTP.3.0")}catch(e){}

try{return new ActiveXObject("Microsoft.XMLHTTP")}catch(e){}

}

return false;

};

```

더욱 압축된 코드는 다음과 같다.

```javascript

function createXMLHttpRequest(a,e,i){

if(XMLHttpRequest){return new XMLHttpRequest()}

if(ActiveXObject){a="Msxml2.XMLHTTP.";a=["Microsoft.XMLHTTP",a+"3.0",a+"6.0"];

for(i=3;i--;){try{return new ActiveXObject(a[i])}catch(e){}}

}return !1

};

4. 2. GET 요청

javascript

const request = new XMLHttpRequest();

request.open('GET', '/api/message', true); // 비동기 설정

request.onreadystatechange = listener;

request.send();

function listener() {

// 요청이 완료되었고 성공적인지 확인

if (request.readyState == 4 && request.status == 200) {

console.log(request.responseText); // 텍스트 표시

}

}

```

`XMLHttpRequest`를 사용하여 요청을 보내는 일반적인 단계는 다음과 같다.[11]

1. 생성자를 호출하여 `XMLHttpRequest` 객체를 생성한다.

2. `open` 메서드를 호출하여 요청 유형(GET), 관련 리소스(`/api/message`), 비동기(true) 여부를 지정한다.

3. 비동기 요청의 경우, 요청 상태 변경 시 알림을 받을 리스너(`listener`)를 설정한다.

4. `send` 메서드를 호출하여 요청을 시작한다.

5. 이벤트 리스너에서 상태 변경에 응답한다. 서버 응답 데이터는 `responseText` 속성에 캡처된다. 응답 처리가 완료되면 상태가 4("완료")로 변경된다.

```javascript

xhr.onreadystatechange = function() {

if (xhr.readyState == 4) { // 완료

if (xhr.status == 200) { // OK

alert(xhr.responseText);

} else {

alert("status = " + xhr.status);

}

}

}

xhr.open("GET", "hoge.txt");

xhr.send();

4. 3. POST 요청

`XMLHttpRequest`를 사용하여 POST 방식으로 요청을 보내는 예시는 다음과 같다.

```javascript

xhr.onreadystatechange = function() {

if (xhr.readyState == 4) { // 완료

if (xhr.status == 200) { // OK

alert(xhr.responseText);

} else {

alert("status = " + xhr.status);

}

}

}

xhr.open("POST", "hoge.cgi");

xhr.setRequestHeader("Content-Type" , "application/x-www-form-urlencoded");

xhr.send("a=b&c=d");

```

위 코드에서 `xhr.open("POST", "hoge.cgi")`는 "hoge.cgi"에 POST 요청을 보내도록 설정한다. `xhr.setRequestHeader("Content-Type" , "application/x-www-form-urlencoded")`는 요청의 HTTP 헤더 중 `Content-Type`을 `application/x-www-form-urlencoded`로 설정하여, 서버에 전송되는 데이터가 URL 인코딩된 형식임을 알려준다. `xhr.send("a=b&c=d")`는 "a=b&c=d"라는 데이터를 서버로 전송한다. `xhr.onreadystatechange`는 요청 상태가 바뀔 때마다 호출되는 함수를 설정하며, 요청이 완료되고(readyState == 4) 성공적으로 처리되었을 때(status == 200) 서버로부터 받은 응답(responseText)을 경고창으로 표시한다.[11]

5. 크로스 도메인 요청

동일 출처 정책으로 인해 XMLHttpRequest는 기본적으로 동일 도메인과만 통신할 수 있다. 하지만 웹 개발자가 의도적으로 이 제한을 우회해야 하는 경우가 있는데, 예를 들어 `foo.example.com`에서 `bar.example.com`의 정보를 얻으려고 할 때 하위 도메인을 사용함에도 불구하고 동일 출처 정책에 의해 통신이 실패할 수 있다.

이러한 제한을 해결하기 위해 XMLHttpRequest Level 2에는 서로 다른 도메인과 통신하는 기능이 추가되었다. 파이어폭스 3.5, 구글 크롬, Safari 4 이후 버전부터 이 기능을 사용할 수 있다. 인터넷 익스플로러 8은 비표준인 XDomainRequest를 통해 비슷한 기능을 제공했다.

크로스 도메인을 허용하려면 서버 측 HTTP 응답 헤더에 `Access-Control-Allow-Origin: *` 와 같이 추가 설정이 필요하다. 이 설정은 모든 도메인에서의 접근을 허가한다. W3C의 교차 출처 자원 공유 (CORS) 표준에 이 내용이 규정되어 있다.

파이어폭스에서는 POST 요청 시 text/plain 이외의 Content-Type을 사용하는 경우, OPTIONS 메서드를 사용해 사전 점검을 수행한다.[22]

5. 1. 동일 출처 정책 (Same-Origin Policy)

월드 와이드 웹 초기 개발 당시, 자바스크립트를 사용하여 한 웹 사이트의 정보를 평판이 좋지 않은 다른 웹 사이트의 정보와 교환하여 사용자의 보안을 침해하는 것이 가능하다는 것을 발견했다. 따라서 모든 최신 브라우저는 이러한 공격, 예를 들어 사이트 간 스크립팅을 방지하는 동일 출처 정책을 구현한다. XMLHttpRequest 데이터는 이 보안 정책의 적용을 받지만, 때로는 웹 개발자가 의도적으로 이 제한을 우회하려는 경우가 있다. 예를 들어 foo.example.com에서 생성된 페이지에서 bar.example.com의 정보를 얻기 위해 XMLHttpRequest를 생성하는 것처럼 하위 도메인을 합법적으로 사용할 때 발생하며, 일반적으로 실패한다.

이러한 보안 기능을 우회하기 위한 다양한 대안이 존재하며, 여기에는 JSONP, 교차 출처 자원 공유(CORS) 또는 플래시 또는 실버라이트 (둘 다 현재 지원 중단됨)와 같은 플러그인을 사용한 대안이 포함된다. 교차 출처 XMLHttpRequest는 W3C의 XMLHttpRequest 레벨 2 사양에 지정되어 있다.[12] Internet Explorer는 버전 10까지 CORS를 구현하지 않았다. 이전 두 버전(8 및 9)은 XDomainRequest(XDR) API를 통해 유사한 기능을 제공했다. CORS는 현재 모든 최신 브라우저(데스크톱 및 모바일)에서 지원된다.[13]

CORS 프로토콜에는 여러 가지 제한 사항이 있으며, 두 가지 지원 모델이 있다. "단순" 모델은 사용자 지정 요청 헤더 설정을 허용하지 않으며 쿠키를 생략한다. 또한 HEAD, GET 및 POST HTTP 요청 메서드만 지원하며, POST는 "text/plain", "application/x-www-urlencoded" 및 "multipart/form-data"의 MIME 유형만 허용한다. 처음에는 "text/plain"만 지원되었다.[14] 다른 모델은 "단순하지 않은" 기능 중 하나가 요청될 때 감지하여 해당 기능을 협상하기 위해 서버에 "사전 요청"을 보낸다.[15]

통신은 보안상의 이유로 동일 출처 정책에 의해 제한되며, 기본적으로 XMLHttpRequest는 동일 도메인(정확히는 동일 출처)과만 통신할 수 있다. 그러나 XMLHttpRequest Level 2에는 서로 다른 도메인과 통신하는 기능이 추가되었으며, 구글 크롬 (Firefox 3.5 이후), Safari 4 이후에서 사용할 수 있다. 또한, Internet Explorer 8에는 비표준의 XDomainRequest가 있어, 비슷한 것이 가능하다.

크로스 도메인을 허용하려면, 서버 측의 HTTP 응답 헤더에 추가가 필요하며, 예를 들어, `Access-Control-Allow-Origin: *`라고 쓰면 모든 도메인에서의 접근이 허가된다. Access-Control-Allow-Origin은 Internet Explorer를 포함한 모든 크로스 도메인 지원 브라우저에서 사용할 수 있다. W3C의 사양은, Cross-Origin Resource Sharing에서 규정되어 있다.

또한, Firefox에서는 POST 등에서, text/plain 등 이외의 Content-Type을 크로스 도메인으로 전송하는 경우, OPTIONS를 사용하여 사전 점검이 수행된다[22]。

또한, 브라우저의 확장 기능 등에서는 특별히 제한을 받지 않고 통신을 수행할 수 있는 기능이 마련되어 있는 경우도 있다.

5. 2. 크로스 도메인 요청의 제한

월드 와이드 웹 초기 개발 당시, 자바스크립트를 사용하여 한 웹 사이트의 정보를 평판이 좋지 않은 다른 웹 사이트의 정보와 교환하여 사용자의 보안을 침해하는 것이 가능하다는 점이 발견되었다. 따라서 모든 최신 브라우저는 사이트 간 스크립팅 공격을 방지하는 동일 출처 정책을 구현한다. XMLHttpRequest 데이터는 이 보안 정책의 적용을 받지만, 웹 개발자가 의도적으로 이 제한을 우회하려는 경우가 종종 있다. 예를 들어 `foo.example.com`에서 생성된 페이지에서 `bar.example.com`의 정보를 얻기 위해 XMLHttpRequest를 생성하는 것처럼 하위 도메인을 합법적으로 사용할 때 이러한 상황이 발생하며, 일반적으로는 실패한다.

이러한 보안 기능을 우회하기 위한 다양한 대안이 존재하며, 여기에는 JSONP, 교차 출처 자원 공유(CORS) 등이 있다.[12] Internet Explorer는 버전 10까지 CORS를 구현하지 않았으며, 이전 두 버전(8 및 9)은 XDomainRequest(XDR) API를 통해 유사한 기능을 제공했다. CORS는 현재 모든 최신 브라우저(데스크톱 및 모바일)에서 지원된다.[13]

CORS 프로토콜에는 여러 가지 제한 사항이 있으며, 두 가지 지원 모델이 있다. "단순" 모델은 사용자 지정 요청 헤더 설정을 허용하지 않으며 쿠키를 생략한다. 또한 HEAD, GET 및 POST HTTP 요청 메서드만 지원하며, POST는 "text/plain", "application/x-www-urlencoded" 및 "multipart/form-data"의 MIME 유형만 허용한다. 처음에는 "text/plain"만 지원되었다.[14] 다른 모델은 "단순하지 않은" 기능 중 하나가 요청될 때 이를 감지하여 해당 기능을 협상하기 위해 서버에 "사전 요청"을 보낸다.[15]

보안상의 이유로 통신은 동일 출처 정책에 의해 제한되며, 기본적으로 XMLHttpRequest는 동일 도메인(정확히는 동일 출처)과만 통신할 수 있다. 그러나 XMLHttpRequest Level 2에는 서로 다른 도메인과 통신하는 기능이 추가되었으며, 파이어폭스 3.5 이후, 구글 크롬, Safari 4 이후에서 사용할 수 있다. 또한, 인터넷 익스플로러 8에는 비표준 XDomainRequest가 있어 비슷한 기능이 제공되었다.

크로스 도메인을 허용하려면 서버 측 HTTP 응답 헤더에 추가가 필요하다. 예를 들어 `Access-Control-Allow-Origin: *`라고 쓰면 모든 도메인에서의 접근이 허가된다. Access-Control-Allow-Origin은 Internet Explorer를 포함한 모든 크로스 도메인 지원 브라우저에서 사용할 수 있다. W3C의 사양은 교차 출처 자원 공유에서 규정되어 있다.

또한, 파이어폭스에서는 POST 등에서 text/plain 등 이외의 Content-Type을 크로스 도메인으로 전송하는 경우, OPTIONS를 사용하여 사전 점검이 수행된다.[22]

5. 3. 해결 방법

월드 와이드 웹 초기 개발 당시, 자바스크립트를 사용하여 한 웹 사이트의 정보를 평판이 좋지 않은 다른 웹 사이트의 정보와 교환하여 사용자의 보안을 침해할 수 있다는 점이 발견되었다. 따라서 모든 최신 브라우저는 사이트 간 스크립팅과 같은 공격을 방지하기 위해 동일 출처 정책을 구현한다. XMLHttpRequest 데이터는 이 보안 정책의 적용을 받지만, 웹 개발자가 의도적으로 이 제한을 우회하려는 경우가 있다. 예를 들어, `foo.example.com`에서 생성된 페이지에서 `bar.example.com`의 정보를 얻기 위해 XMLHttpRequest를 생성하는 것처럼 하위 도메인을 합법적으로 사용할 때 발생하며, 일반적으로는 실패한다.

이러한 보안 기능을 우회하기 위한 다양한 대안이 존재하는데, 여기에는 JSONP, 교차 출처 자원 공유(CORS) 등이 포함된다. 교차 출처 XMLHttpRequest는 W3C의 XMLHttpRequest 레벨 2 사양에 지정되어 있다.[12] Internet Explorer는 버전 10까지 CORS를 구현하지 않았지만, 이전 두 버전(8 및 9)은 XDomainRequest(XDR) API를 통해 유사한 기능을 제공했다. CORS는 현재 모든 최신 브라우저(데스크톱 및 모바일)에서 지원된다.[13]

CORS 프로토콜에는 여러 가지 제한 사항이 있으며, 두 가지 지원 모델이 있다. "단순" 모델은 사용자 지정 요청 헤더 설정을 허용하지 않으며 쿠키를 생략한다. 또한 HEAD, GET 및 POST HTTP 요청 메서드만 지원하며, POST는 "text/plain", "application/x-www-urlencoded" 및 "multipart/form-data"의 MIME 유형만 허용한다. 처음에는 "text/plain"만 지원되었다.[14] 다른 모델은 "단순하지 않은" 기능 중 하나가 요청될 때 감지하여 해당 기능을 협상하기 위해 서버에 "사전 요청"을 보낸다.[15]

동일 출처 정책에 의해 통신은 보안상의 이유로 제한되며, 기본적으로 XMLHttpRequest는 동일 도메인(정확히는 동일 출처)과만 통신할 수 있다. 그러나 XMLHttpRequest Level 2에는 서로 다른 도메인과 통신하는 기능이 추가되었으며, Firefox 3.5 이후, 구글 크롬, Safari 4 이후에서 사용할 수 있다. Internet Explorer 8에는 비표준인 XDomainRequest가 있어, 비슷한 것이 가능하다.

크로스 도메인을 허용하려면, 서버 측의 HTTP 응답 헤더에 추가가 필요하며, 예를 들어, `Access-Control-Allow-Origin: *`라고 쓰면 모든 도메인에서의 접근이 허가된다. Access-Control-Allow-Origin은 Internet Explorer를 포함한 모든 크로스 도메인 지원 브라우저에서 사용할 수 있다. W3C의 사양은 Cross-Origin Resource Sharing에서 규정되어 있다.

Firefox에서는 POST 등에서 text/plain 등 이외의 Content-Type을 크로스 도메인으로 전송하는 경우, OPTIONS를 사용하여 사전 점검이 수행된다.[22]

브라우저의 확장 기능 등에서는 특별히 제한을 받지 않고 통신을 수행할 수 있는 기능이 마련되어 있는 경우도 있다.

6. 스트리밍

readyState가 3 (LOADING) 상태에서 기본적으로 수신 중인 통신 내용을 가져올 수 있으므로, 이를 사용하여 수신 스트리밍을 사용할 수 있다. 단, 각 브라우저에는 다음과 같은 제한 사항이 있다[23]。

브라우저제한 사항
Internet ExplorerreadyState가 3인 상태에서는 내용을 가져올 수 없으며, Internet Explorer 8용 XDomainRequest를 사용해야 한다. 또한 처음에 2KB의 더미 데이터를 서버에서 전송해야 한다. Internet Explorer 7 이전 버전에서는 스트리밍을 사용할 수 없다.
Google Chrome버전 6 현재 readyState가 3 상태로 전환하기 위해 Content-Type: application/octet-stream으로 설정하거나 10,240억 이상의 데이터를 서버에서 전송해야 한다[24]。
OperaOpera 이외의 브라우저에서는 브라우저 측에서 데이터를 수신할 때마다 onreadystatechange가 발생하지만, Opera 11.0에서는 발생하지 않으므로, 정기적으로 responseText의 내용을 확인해야 한다.


7. 롱 폴링 (Long Polling)

코멧 구현에 사용되는 롱 폴링은 HTTP 연결을 유지한 상태에서 서버로부터 정보를 전송해야 할 때 처음으로 응답을 반환하는 것을 의미한다. 롱 폴링을 이용할 때는 다음과 같은 사항에 주의해야 한다.


  • 브라우저의 HTTP 연결 타임아웃(30초 등)이 존재하므로, 연결이 끊어지면 다시 연결하는 로직을 구현해야 한다.
  • 서버당 동시 연결 수는 초기 설정에서 제한되어 있다. 인터넷 익스플로러 8 이후 및 기타 주요 브라우저에서는 6개[25], 인터넷 익스플로러 7 이전에서는 2개로 제한된다. 따라서 여러 롱 폴링을 동시에 수행하면 새로운 서버에 연결할 수 없는 문제가 발생할 수 있다. 다이얼 업 연결의 경우, 인터넷 익스플로러 8에서도 동시 연결 수는 2개로 제한된다.
  • HTTP 연결이 종료될 때까지 서버가 종료될 수 없거나, 연결마다 스레드를 생성하여 동시 연결 수가 많으면 메모리 등의 리소스를 대량으로 소비하는 문제가 발생할 수 있다. 따라서 롱 폴링에 대응하는 서버 측 구현 방식이 필요하다. 예를 들어 Java의 경우, Jetty는 독자적인 Continuation 클래스, 아파치 톰캣은 독자적인 CometProcessor 클래스를 제공하며, Servlet 3.0은 HTTPServletRequest에 startAsync()를 제공한다. 이러한 롱 폴링용 API를 활용하는 것이 좋다.


이러한 문제를 근본적으로 해결하기 위해 IETF, W3C 등에서 2011년에 대체 프로토콜인 웹 소켓을 표준화하였다.

8. Fetch API

ECMAScript 2015 (ES6)는 비동기 로직을 단순화하기 위해 프로미스 구조를 추가하였다. 이후 브라우저는 콜백 대신 프로미스를 사용하여 XMLHttpRequest와 동일한 기능을 수행하는 `fetch()` 인터페이스를 구현했다.[16] Fetch는 또한 WHATWG에 의해 표준화되었다.[16]

참조

[1] 서적 Ajax Design Patterns O'Reilly
[2] 서적 Ajax Design Patterns O'Reilly
[3] 웹사이트 Article on the history of XMLHTTP by an original developer http://www.alexhopma[...] Alexhopmann.com 2009-07-14
[4] 서적 Ajax Design Patterns O'Reilly
[5] 웹사이트 Archived news from Mozillazine stating the release date of Safari 1.2 http://weblogs.mozil[...] Weblogs.mozillazine.org 2009-07-14
[6] 웹사이트 Press release stating the release date of Opera 8.0 from the Opera website http://www.opera.com[...] Opera.com 2009-07-14
[7] 웹사이트 Specification of the XMLHttpRequest object from the Level 1 W3C Working Draft released on April 5th, 2006 http://www.w3.org/TR[...] W3.org 2009-07-14
[8] 웹사이트 Specification of the XMLHttpRequest object from the Level 2 W3C Working Draft released on February 25th, 2008 http://www.w3.org/TR[...] W3.org 2009-07-14
[9] 웹사이트 XMLHttpRequest Editor's Draft 5 December 2011 http://dvcs.w3.org/h[...] w3.org 2011-12-05
[10] 간행물 XMLHttpRequest Living Standard https://xhr.spec.wha[...] 2024-04-09
[11] 서적 Ajax: The Definitive Guide
[12] 웹사이트 XMLHttpRequest Level 2 http://www.w3.org/TR[...] 2013-11-14
[13] 웹사이트 Can I use Cross-Origin Resource Sharing? http://caniuse.com/c[...] 2013-11-14
[14] 웹사이트 XDomainRequest - Restrictions, Limitations and Workarounds http://blogs.msdn.co[...] 2013-11-14
[15] 웹사이트 7.1.5 Cross-Origin Request with Preflight http://www.w3.org/TR[...] 2014-04-25
[16] 웹사이트 Fetch Standard https://fetch.spec.w[...]
[17] 뉴스 Outlook Web Access - A catalyst for web evolution https://blogs.techne[...] You Had Me At EHLO... 2005-06-21
[18] 뉴스 Dynamic HTMLとXML：XMLHttpRequestオブジェクト http://developer.app[...] Apple Developer Connection 2005-06-24
[19] 뉴스 IE7 - XMLHttpRequest の標準サポート http://www.exconn.ne[...] ウィンドウズ開発統括部 2006-03-09
[20] 웹사이트 XMLHttpRequest Level 2 W3C Working Group Note https://www.w3.org/T[...]
[21] 웹사이트 Using the right version of MSXML in Internet Explorer http://blogs.msdn.co[...] Microsoft XML Team's WebLog 2010-07-26
[22] 웹사이트 HTTP アクセス制御 (CORS) - HTTP https://developer.mo[...] 2017-03-25
[23] 웹사이트 COMET Streaming in Internet Explorer - EricLaw's IEInternals - Site Home - MSDN Blogs http://blogs.msdn.co[...]
[24] 웹사이트 Issue 2016 - chromium - Chrome stalls XHRs in order to sniff mime-type - Project Hosting on Google Code https://code.google.[...]
[25] 웹사이트 Network - Browserscope http://www.browsersc[...]
[26] 웹인용 Article on the history of XMLHTTP by an original developer http://www.alexhopma[...] Alexhopmann.com 2009-07-14
[27] 웹인용 Specification of the IXMLHTTPRequest interface from the Microsoft Developer Network http://msdn.microsof[...] Msdn.microsoft.com 2009-07-14
[28] 웹인용 Native XMLHTTPRequest object http://blogs.msdn.co[...] Microsoft 2006-01-23


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com