지난 포스트에서는 CORS에 대해서 (아직 지원하지 않는 브라우져가 많다고 지레 짐작하고) 용어만 언급하고 넘어갔다.
최근에 올라온 "Methods of communication"이라는 글에 걸린 링크를 통해 지금 당장이라도 쓸 수 있음을 확인하고, 몇 자 적어보려고 한다.
Ajax에는 Same Origin Policy라는 원칙이 있다. 말 그대로, 현재 브라우져에 보여지고 있는 HTML을 내려준 웹서버(Origin)에게만 Ajax 요청을 보낼 수 있다.
MS가 XMLHttpRequest를 처음 만들 때만 해도 이런 제약은 당연한 것처럼 보였지만, 지금에 와서는 OpenAPI를 통한 매시업(Mashup)이 활성화되는 데 가장 큰 장애물이 되었다. 매시업이 아니더라도 여러 개의 도메인을 사용해야 하는 대규모 사이트를 개발할 때도 골치거리였다. Same Origin Policy를 우회하는 방법으로 JSONP, IFRAME IO, CrossDomain Proxy 등이 고안되었지만, 보안성이 취약하다거나, 동기 호출이 안되거나, 주고 받는 데이터 형식이 제한되거나, 직관적이지 못하거나(dirty hack), ... 등의 문제점 때문에 표준화되기엔 무리가 있었다.
(중략) 한 참 뒤에야 W3C는 (MS의 IE가 제공하는 방식을 수용하여) 크로스도메인간에도 Ajax요청을 주고 받을 수 있는 방법을 표준화 했는데, 그것이 바로 CORS다.
CORS를 한 마디로 요약하면, "요청을 받은 웹서버가 허락하면 크로스도메인이라도 Ajax로 통신할 수 있다"라는 정책이다. 기술적으로는 크로스도메인에 위치한 웹서버가 응답에 적절한 Access-Control-Allow-류의 헤더를 보냄으로써 크로스도메인 Ajax를 허용 수 있다.
말이 뺑뺑도는 느낌인데, 예를 들어 보자(코드를 줄이기 위해 jQuery를 사용했지만 XMLHttpRequest를 직접 사용해도 마찬가지다). Ajax 요청을 보내는 one.html을 내려 준 a.com이 오리진 웹서버다. 이 요청을 받는 b.com이 크로스도메인 웹서버다. a.com에서 b.com으로... 그래서 크로스-도메인이다.
대충 그려보면 이런 식인데, b.com은 크로스도메인이므로 Ajax 통신이 불가능하지만, CORS를 적용하면 가능하다:
http://a.com/one.html
http://b.com/another.php
보다시피, Ajax 클라이언트 측에는 추가적으로 할 일이 없고, 서버 측에서 할 일도 많지 않다. 웹서버(b.com)이 응답에 Access-Control-Allow-Origin헤더를 통해 모든 Origin(*)에서 오는 요청을 허락했으므로 다른 도메인(요청을 보낸 one.html을 내려 준 a.com)과 Ajax로 통신을 할 수 있다. 플래시에 익숙한 개발자라면 crossdomain.xml 을 떠오를 것이다. 맞다. 사실상 똑같다.
CORS는 FF 3.5+, 사파리 4+, 크롬 등의 대부분의 현대적인 브라우져에서 지원한다. IE의 경우엔 IE8부터 지원하는데, XMLHttpRequest대신 XDomainRequest객체를 사용해야 한다. 즉, 거의 다 된다! IE6,7만 무시하면... oTL
CORS 표준에 따르면 Origin외에도 HTTP 인증 여부, HTTP 메소드(GET, POST, ...), 특정 헤더 존재 유무 등의 다양한 기준으로 접근을 허용(preflight request)할 수 있는데, IE8은 이 스펙을 지원하지 않는다. -_-; CORS가 IE의 비표준 확장에 근거해서 만들어졌다는 점을 생각해보면.. 개그도 이런 개그가... -_-; IE9은... 아직 확인해보지 못했다.
클라이언트 대신 서버 측에서 뭔가를 해야 한다는 것은 장점인 동시에 단점인데, 기존의 수많은 OpenAPI들을 활용하고 싶어도 제공자들이 CORS를 적용하기 전까지는 무용지물... -_- OpenAPI를 제공하고 있거나, 제공할 계획이라면 JSONP 뿐 아니라 CORS도 고려해야 할 듯...
처음 언급된지 십년이 다 된 "Web as a Platform"이 실감나는 요즘이다. 팀 버너스 리가 원하던 원치않던... 웹은 점점 플랫폼으로 진화(혹은 변신)하고 있다. 별것 아닌 CORS도 이런 관점에서 보면 조금은 다르게 보일지도...
최근에 올라온 "Methods of communication"이라는 글에 걸린 링크를 통해 지금 당장이라도 쓸 수 있음을 확인하고, 몇 자 적어보려고 한다.
Ajax에는 Same Origin Policy라는 원칙이 있다. 말 그대로, 현재 브라우져에 보여지고 있는 HTML을 내려준 웹서버(Origin)에게만 Ajax 요청을 보낼 수 있다.
MS가 XMLHttpRequest를 처음 만들 때만 해도 이런 제약은 당연한 것처럼 보였지만, 지금에 와서는 OpenAPI를 통한 매시업(Mashup)이 활성화되는 데 가장 큰 장애물이 되었다. 매시업이 아니더라도 여러 개의 도메인을 사용해야 하는 대규모 사이트를 개발할 때도 골치거리였다. Same Origin Policy를 우회하는 방법으로 JSONP, IFRAME IO, CrossDomain Proxy 등이 고안되었지만, 보안성이 취약하다거나, 동기 호출이 안되거나, 주고 받는 데이터 형식이 제한되거나, 직관적이지 못하거나(dirty hack), ... 등의 문제점 때문에 표준화되기엔 무리가 있었다.
(중략) 한 참 뒤에야 W3C는 (MS의 IE가 제공하는 방식을 수용하여) 크로스도메인간에도 Ajax요청을 주고 받을 수 있는 방법을 표준화 했는데, 그것이 바로 CORS다.
CORS를 한 마디로 요약하면, "요청을 받은 웹서버가 허락하면 크로스도메인이라도 Ajax로 통신할 수 있다"라는 정책이다. 기술적으로는 크로스도메인에 위치한 웹서버가 응답에 적절한 Access-Control-Allow-류의 헤더를 보냄으로써 크로스도메인 Ajax를 허용 수 있다.
말이 뺑뺑도는 느낌인데, 예를 들어 보자(코드를 줄이기 위해 jQuery를 사용했지만 XMLHttpRequest를 직접 사용해도 마찬가지다). Ajax 요청을 보내는 one.html을 내려 준 a.com이 오리진 웹서버다. 이 요청을 받는 b.com이 크로스도메인 웹서버다. a.com에서 b.com으로... 그래서 크로스-도메인이다.
대충 그려보면 이런 식인데, b.com은 크로스도메인이므로 Ajax 통신이 불가능하지만, CORS를 적용하면 가능하다:
http://a.com/one.html
...
$.get('http://b.com/another.php', function(data) {
alert(data);
})
$.get('http://b.com/another.php', function(data) {
alert(data);
})
http://b.com/another.php
...
<?php header('Access-Control-Allow-Origin:*'); ?>
...
<?php header('Access-Control-Allow-Origin:*'); ?>
...
보다시피, Ajax 클라이언트 측에는 추가적으로 할 일이 없고, 서버 측에서 할 일도 많지 않다. 웹서버(b.com)이 응답에 Access-Control-Allow-Origin헤더를 통해 모든 Origin(*)에서 오는 요청을 허락했으므로 다른 도메인(요청을 보낸 one.html을 내려 준 a.com)과 Ajax로 통신을 할 수 있다. 플래시에 익숙한 개발자라면 crossdomain.xml 을 떠오를 것이다. 맞다. 사실상 똑같다.
CORS는 FF 3.5+, 사파리 4+, 크롬 등의 대부분의 현대적인 브라우져에서 지원한다. IE의 경우엔 IE8부터 지원하는데, XMLHttpRequest대신 XDomainRequest객체를 사용해야 한다. 즉, 거의 다 된다! IE6,7만 무시하면... oTL
CORS 표준에 따르면 Origin외에도 HTTP 인증 여부, HTTP 메소드(GET, POST, ...), 특정 헤더 존재 유무 등의 다양한 기준으로 접근을 허용(preflight request)할 수 있는데, IE8은 이 스펙을 지원하지 않는다. -_-; CORS가 IE의 비표준 확장에 근거해서 만들어졌다는 점을 생각해보면.. 개그도 이런 개그가... -_-; IE9은... 아직 확인해보지 못했다.
클라이언트 대신 서버 측에서 뭔가를 해야 한다는 것은 장점인 동시에 단점인데, 기존의 수많은 OpenAPI들을 활용하고 싶어도 제공자들이 CORS를 적용하기 전까지는 무용지물... -_- OpenAPI를 제공하고 있거나, 제공할 계획이라면 JSONP 뿐 아니라 CORS도 고려해야 할 듯...
처음 언급된지 십년이 다 된 "Web as a Platform"이 실감나는 요즘이다. 팀 버너스 리가 원하던 원치않던... 웹은 점점 플랫폼으로 진화(혹은 변신)하고 있다. 별것 아닌 CORS도 이런 관점에서 보면 조금은 다르게 보일지도...
'hacking > web' 카테고리의 다른 글
| 단일 페이지 인터페이스 웹/앱 개발 (1) | 2011/06/30 |
|---|---|
| xui.js - 모바일 html5 웹앱을 위한 초경량 자바스크립트 라이브러리 (0) | 2011/04/08 |
| CORS(Cross-Origin Resource Sharing)을 활용한 크로스도메인 Ajax (4) | 2011/03/29 |
| 앱스프레소 확장 API를 사용한 AJAX (6) | 2011/03/24 |
| 웹킷 CSS 애니메이션으로 스타워즈 오프닝 크롤 구현하기 (0) | 2011/03/14 |
| 웹에서 아이폰스러운 Carousel 구현하기 (0) | 2011/03/13 |
