HTTP Request

사전 지식 - 웹 프로그래밍

인터넷

기본적으로 인터넷은 전 세계에 걸쳐 존재하는 컴퓨터 네트워크다. 컴퓨터 네트워크는 컴퓨터끼리 서로 메시지를 보내는 것을 가능케 한다. 네트워크 하부에 자리 잡은 기술은 대단히 흥미롭지만, 이 책의 주제를 벗어난다. 대개 서버(server)라는 한 컴퓨터가 다른 컴퓨터가 상호작용을 시작하길 기다린다고만 알면 된다. 클라이언트(client)라는 다른 컴퓨터가 서버와의 통신을 시작하면 두 컴퓨터는 서로 데이터를 주고 받을 수 있다. 양쪽이 서로를 이해하려면 이런 데이터 전송은 프로토콜(protocol), 즉 통신 규약의 안내를 받아야만 한다.

인터넷은 다양한 프로토콜을 대상으로 메시지를 전달하는 데 사용된다. 이런 프로토콜은 채팅, 파일 공유 뿐 아니라 악성 코드에 감염된 컴퓨터를 제어하는 등에도 사용된다. 이 책에서 관심을 두는 프로토콜은 월드와이드웹(World Wide Web)에서 사용되는 프로토콜이다. 이를 HTTp(HyperText Transfer Protocol을 중인 말이다)라고 하며, 웹 페이지를 비롯해 웹 페이지와 연결된 파일을 열람하는 데 사용된다.

HTTP 통신에서 서버는 웹 페이지가 저장된 컴퓨터다. 클라이언트는 웹 페이지를 표시할 수 있게 서버에 웹 페이지를 요구하는 컴퓨터이다. 이처럼 페이지를 요구하는 것을 HTTP 요청(request)이라고 한다.


URL

인터넷을 통해 접근할 수 있는 웹 페이지와 다른 자원들은 URL로 식별되며, URL은 Universal Resource Locator를 줄인 말이다. URL의 형태는 다음과 같다.

							http://acc6.its.brooklyn.cuny.edu/~phalsall/texts/taote-v3.html
						

URL은 세 부분으로 구성된다. 첫 번째 부분인 http://는 이 URL에서 HTTP 프로토콜을 사용한다는 것을 나타낸다. 여기서 FTP(file transfer protocol)나 HTTPS(Secure HTTP)같은 다른 프로토콜도 있으며, 이런 프로토콜에서도 URL을 사용한다. 다음 부분인 acc6.its.brooklyn.cuny.edu는 이 페이지를 찾을 수 있는 서버의 이름을 나타낸다. URL의 마지막 부분인 /~phalsall/texts/taote-v3.html은 이 서버상에 존재하는 특정 파일의 이름을 가리킨다.

일반적으로 월드와이드웹에 접근할 때는 브라우저를 이용한다. 브라우저에 URL을 입력하거나 링크를 클릭하고 나면 브라우저가 HTTP 요청을 적절한 서버에 보낸다. 문제가 없다면 서버에서는 브라우저에 파일을 돌려줌으로써 응답하고, 브라우저에서는 받은 파일을 사용자에게 보여준다.

예제에서 본 것과 마찬가지로 서버에서 받은 파일은 HTML 문서라면 해당 파일은 웹 페이지로 표시된다. HTML에 관련해서는 5장에서 간략하게 살펴봤는데, 5장에서 HTML에 스타일 정보를 담거나 이미지 파일을 참조할 수 있다는 사실을 배웠다. 7장에서는 HTML 페이지에도 script 태그를 포함해 자바스크립트 코드가 담긴 파일을 불러올 수 있다고 언급했다. HTML 문서를 보여줄 때 브라우저는 자동으로 페이지에서 사용하는 모든 스크립트와 이미지 파일을 가져와 문서에 그것들을 추가할 수 있게 만든다.


서버 측 프로그래밍

종종 URL이 구체적인 파일을 가리키기도 하지만 웹 서버기 단순히 파일을 찾아 그것을 클라이언트로 보내는 것보다 좀 더 복잡한 일을 하게 만들 수도 있다. 예를 들어 서버는 이 파일을 먼저 전처리(preprocess)할 수도 있다. 또는 파일이 전혀 없고 URL이 오면 해당 URL에 대한 문서를 생성하는 프로그램만 있을 수도 있다.

문서를 변환하거나 생성하는 프로그램을 이용하면 좀 더 수준 높은 웹 페이지를 만들 수 있다. 파일은 그냥 파일이고 정적이며, 상호작용이 없다. 각 요청에 대해 실행되는 프로그램이 있다면 그 결과로 만들어지는 페이지를 사용자의 로그인 여부나 구체적인 선호 설정을 토대로 각 사용자에 맞출 수 있다. 이렇게 되면 웹 페이지의 콘텐츠를 관리하기가 훨씬 쉬워진다. 즉, 뭔가 새로운 것이 생길 때마다 새 HTML 파일을 웹사이트에 추가하는 게 아니라 새 문서를 어떤 중앙 저장소(보통 데이터베이스)에 추가하고 웹 페이지를 생성하는 프로그램에서는 중앙 저장소에서 그런 문서를 찾아 클라이언트에 문서를 어떻게 보여줄지 판단한다.

이런 웹 프로그래밍을 서버 측 프로그래밍이라고 한다. 서버 측 프로그래밍은 사용자에게 문서를 보내기 전에 문서에 영향을 미친다. 어떤 경우에는 페이지를 보내고 난 후에 사용자가 페이지를 보고 있을 대 실행되는 프로그래밍도 유용할 때가 있다. 이를 클라이언트 측 프로그래밍이라고 하며, 이렇게 부르는 이유는 프로그랭이 클라이언트의 컴퓨터에서 실행되기 때문이다. 자바스크립트는 클라이언트 측 웹 프로그래밍에 사용할 목적으로 만들어졌다.


클라이언트 측 프로그래밍

클라이언트 측에서 프로그램을 실행하면 문제가 발생할 소지가 다분하다. 현재 방문 중인 페이지에 어떤 종류의 프로그램이 실행될지 미리 알기란 불가능하다. 해당 페이지에서 여러분의 컴퓨터에 들어 있는 정보를 다른 컴퓨터로 보내거나, 뭔가를 망가뜨리거나 여러분의 시스템에 침투할 수 있다면 웹 서핑이 위험해질 것이다.

이런 문제를 방지하고자 브라우저에서는 자바스크립트 프로그램에서 할 수 있는 일을 엄격하게 제한한다. 자바스크립트 프로그램에서는 컴퓨터상의 파일을 살펴보거나 해당 자바스크립트 프로그램이 들어 있는 웹 페이지와 관계되지 않은 것은 아무것도 변경할 수 없다. 이처럼 프로그래밍 환경을 격리하는 것을 샌드박싱(sandboxing)이라고 한다. 프로그램이 유용할 만한 여지를 충분히 주면서 해를 끼치지 않을 정도로 제한하기란 결코 쉬운 일이 아니다. 수개월 마다 일부 자바스크립트 프로그래머들은 그런 제약을 피하는 새로운 방법을 고안해 내서 뭔가 해를 끼치거나 사생활을 침해하는 뭔가를 하기도 한다. 브라우저를 책임지는 사람들은 자신들이 작성한 프로그램을 수정해서 이런 기법을 불가능하게 만들어 다음 문제가 발견되기 전까지 다시 아무런 문제가 없게 만든다.



HTTP 프로토콜

간단한 HTTP 요청의 모습은 다음과 같다.

							GET  /files/data.txt HTTP/1.1
							Host: eloquentjavascript.net
							User-Agent: My Imaginary Browser
						

이 요천은 eloquentjavascript.net에 있는 서버에서 files/data.txt 파일을 요구한다. 더불어 이 요청에서는 1.1 버전의 HTTP 프로토콜을 사용한다고 명시한다. 1.0 버전도 여전히 사용되고 있으며, 약간 다른 식으로 동작한다. Host와 User-Agent 줄을 헤더(header)라고 한다. 헤더는 다음과 같은 패턴을 따른다. 즉, 헤더에 포함된 정보를 구분하는 단어로 시작해 콜론(:)이 나온 다음 실제 정보가 나온다. User-Agent 헤더는 어떤 프로그램을 써서 요청을 만들어내는지 서버에 알려준다. 다른 종류의 헤더도 함께 보내곤 하는데, 이를테면 클라이언트가 이해할 수 있는 문서의 종류나 클라이언트가 선호하는 언어와 같은 것을 명시하기도 한다.

앞에서 보여준 요청을 전달하면 서버에서는 다음과 같은 응답을 보낼지도 모른다.

							HTTP/1.1 200 OK
							Last-Modified: Mon, 23 Jul 2007 08:41:56 GMT
							Content-Length: 40
							Content-Type: text/plain

							data.txt 의 내용
						

첫 줄은 HTTP 프로토콜의 버전을 나타내며, 이어서 요청의 상태가 나온다. 이 경우 상태 코드는 200이며, "좋아, 특별한 일은 아무것도 일어나지 않았고, 지금 파일을 보내줄게."라는 의미다. 여거엔 몇 가지 헤더가 더 이어지는데, (이 경우) 마지막으로 파일이 수정된 시각과 파일의 길이, 파일의 유형(일반 텍스트)을 나타낸다. 헤더가 나오고 나서 빈 줄이 나오고, 파일 자체가 이어진다. 이를 응답 본문(body)이라고 한다.

GET으로 시작하는 요청(클라이언트가 문서를 가져오고 싶다는 것을 나타내는) 외에도 POST라는 단어도 요청과 함께 본문이 보내진다는 것을 가리키는 데 사용할 수 있다. 이러한 메소드(요청이 시작하는 시점의 동사를 뭘로 지정하는냐) 간의 차이점은 9장에서 폼에 관해 다룰 때 간략하게 살펴 봤다. 다른 요청 유형도 있는데, 이를테면 PUT은 문서를 서버에 집어넣고, DELETE는 문서를 삭제하는 역할을 한다. 이러한 요청 유형은 폭넓게 사용되지는 않는데, 일반적으로 브라우저에서는 그러한 요청 유형을 보내는 손쉬운 수단을 제공하지 않기 때문이다. GET은 모든 링크에서 사용되고 POST는 method="post"가 지정된 폼에 사용되지만 PUT과 DELETE에 해당하는 관례는 존재하지 않는다.


XMLHttpRequest API

링크를 클릭하거나 폼을 제출할 때, 또는 일부 다른 방식으로 브라우저가 새로운 페이지로 이동할 때 브라우저는 HTTP 요청을 할 것이며, 요청이 성공하면 새로 불러온 문서를 보여줄 것이다. 일반적인 상황에서 이것은 여러분이 원하는 바이고 전통적으로 웹은 이런 방식을 동작한다. 하지만 때로는 자바스크립트 프로그램에서 페이지를 다시 불러오지 않고도 서버와 통하고 싶을 때가 있다.

이런 식의 작업을 할 수 있으려면 프로그램에서 HTTP 요청 자체를 해야 한다. 오늘날 출시되는 브라우저에서는 이러한 작업을 위한 인터페이스를 제공한다. 새창을 여는 것과 마찬가지로 이 인터페이스에는 스크립트에서 끔찍한 일들을 저지르지 못하게 하는 일부 제한 사항이 있는데, 바로 현재 페이지의 출처와 동일한 도메인에 대해서만 HTTP 요청을 할 수 있다는 점이다. 즉, http://www.evil.org/에 있는 페이지에서는 브라우저로 하여금 http://www.yourbank.com/에 있는 페이지를 가져오게 할 수 없다는 의미다. 이는 http://www.yourbank.com에 여러분이 로그인돼 있을 수도 있으며, 그러한 요청은 은행에서 여러분의 돈을 http://www.evil.org/의 주인에게 이체하게 만들 수도 있기 때문이다.


요청 객체 생성

HTTP 요청을 하는 데 사용되는 객체는 대부분의 브라우저에서 단순히 new XMLHttpRequest()로 생성할 수 있다. 하지만 일부 사람들이 여전히 사용 중인 인터넷 익스플로러 6에서는 new ActiveXObject("Msxml2.XMLHTTP")를 대신 써야 한다. 우리는 이미 비호환성 래퍼를 작성하는 데 익숙하므로 여기서 다시 한번 해보자.

							function requestObject () {
								if (window.XMLHttpRequest) {
									return new XMLHttpRequest();
								}else if (window.ActiveXObject) {
									return new ActiveXObject("Msxml2.XMLHTTP");
								}else {
									throw new error("HTTP 요청 객체를 생성할 수 없습니다.");
								}
							}							
						

이 함수에서는 최신 메소드가 지원되는지 확인하고, 그렇지 않으면 인터넷 익스플로러 메소드를 사용하며, 두 방법 모두 작동하지 않으면 오류를 던진다.


단순 요청

이제 요청 객체가 준비됐으므로 앞에서 보여준 예제와 비슷한 요청을 할 수 있다.

							var request = requestObject();
							request.open("GET", "files/data.txt", false);
							request.send(null);

							//alert(request.responseText);					
						

open 메소드는 요청을 구성하는 데 사용된다. 이 경우 data.txt 파일에 대한 GET 요청을 만들기로 한다. 여기서 지어한 URL은 상대 URL이다. 즉 상대 URL에는 http:// 부분이나 서버 이름이 포함돼 있지 않으며, 이것은 현재 문서가 위치한 서버에서 파일을 찾는다는 의미다. 세 번재 매개변수인 false는 잠시 후에 살펴보겠다. open 메소드를 호출하고 나면 실제 요청은 send 메소드로 할 수 있다. 요청이 POST 요청이면 서버로 전달된 데이터(문자열로)를 이 메소드에 전달할 수 있다. GET 요청에 대해서는 null을 전달하기만 하면 된다.

요청을 하고 나면 요청 객체의 responseText 프로퍼티에 받은 문서의 내용이 담긴다. 서버에서 보내준 헤더는 getResponseHeader와 getAllResponseHeaders 함수로 확인할 수 있다. 전자는 특정 헤더를 확인하고, 후자는 모든 헤더가 담긴 문자열을 반환한다. 이러한 메소드는 때때로 문서에 관한 추가 정보를 구할 때 유용하게 사용할 수 있다.

							request.getResponseHeader("Content-Type");		
							
							// "text/plain"
						

이를테면 인증 정보를 제공하거나 서버에 받고 싶은 응답 유형을 지정(이 방법을 알고 싶다면 HTTP에 관한 책을 참고한다 HTTP 헤더 - 참고자료1, HTTP 헤더 - 참고자료2)하는 것 처럼 서버로 보내는 요총에 헤더를 추가하고 싶다면 setRequestHeader 메소드를 이용하면 된다. 이 메소드는 헤더의 이름과 값에 해당하는 두 문자열을 인자로 취한다.

앞의 예제에서 200이었던 응답 코드는 status 프로퍼티에서 확인할 수 있다. 뭔가 문제가 발생하면 이러한 암호와 같은 코드가 그러한 사실을 가리킨다. 예를 들어 404는 요청한 파일이 존재하지 않는다는 의미다. statusText에는 약간 더 이해하기 쉬운 상태 설명이 담겨 있다.

							request.status;
							// 200

							request.statusText;
							// "OK"
						

요청이 성공했는지 확인하고 싶다면 status가 200인지 확인하는 것만으로 충분하다. 하지만 좀 더 정교한 웹 서비스에서는 다양한 성공 코드를 사용할지도 모른다. 예를 들면 '콘텐츠가 없음'을 의미하는 204는 서버가 요청을 성공적으로 받았지만 응답으로 보낼 만한 것이 아무것도 없음을 나타낸다.


비동기 요청

앞에서 보여준 예제에서처럼 요청을 하면 요청이 완료되기 전까지는 send 메소드에 대한 호출이 반환되지 않는다. 이런 방식은 편리한데, send 메소드를 호출한 후 responseText를 사용할 수 있거나 곧바로 responseText를 사용할 수 있다는 뜻이기 때문이다. 하지만 여기엔 문제가 있다. 서버가 느리거나 파일이 크면 요청을 하는 데 시간이 오래 걸릴지도 모른다. 이런 문제가 발생하면 프로그램은 대기하게 되고, 브라우저 전체가 대기하게 된다. 요청이 완료되기 전까지는 사용자는 아무것도 하지 못한다. 빠르고 안정적인 로컬 네트워크에서 실행되는 페이지는 이런 식으로 요청하는 것이 큰 문제가 되지 않을지도 모른다. 하지만 거대하고 신뢰할 수 없는 인터넷상의 페이지는 그렇지 못하다.

open 메소드의 세 번째 인자에 true를 지정하면 요청이 비동기적으로 전달된다. 이것은 send 메소드가 곧바로 반환된다는 것을 의미하고, 그 사이에 요청은 백그라운드에서 진행된다.

							request.open("GET", "files/data/txt", true);
							request.send(null);
						

이렇게 하고 나면 프로그램에서는 요청이 백그라운드에서 진행되는 동안 프로그램의 나머지 부분을 계속 실행할 것이다. send 메소드를 호출한 직후 responseText 프로퍼티를 살펴보면 값이 null일 것이다. 몇 초 후에 다시 살펴보면 요청이 완료됐을 것이며, 프로퍼티에 값이 채워져 있을 것이다.

"몇 초 기다린다."는 setTimeout이나 그와 비슷한 뭔가로 구현할 수도 있겠지만, 더 나은 방법이 있다. 요청 객체에는 readyState 프로퍼티가 있는데, 이 프로퍼티는 요청 객체의 상태를 가리킨다. 이러한 상태의 변환에 반응하려면 요청 객체의 onreadystatuschange 프로퍼티에 함수를 설정하면 된다. 이 함수는 상태가 변경될 때마다 호출될 것이다.

요총 객체는 상태 0에서 시작한다. 요청 객체를 대상으로 open 메소드를 호출하고 나면 상태가 1로 바뀐다. 그러고 나서 send 메소드를 호출하면 상태가 2가 된다. 응답을 읽기 시작하면 상태 3이 되고, 마침내 전체 응답을 읽고 나면 요청이 상태 4에 이른다. 보통 우리는 상태 4에만 관심이 있는데, 이 상태가 요청이 완료됐음을 의미하기 때문이다. 다음 코드는 요청이 완료되길 비동기적으로 대기한 다음 상태코드와 텍스트를 출력한다.

							request.open("GET", "files/data.txt", true);
							request.onreadystatechange = function () {
								if (request.readyState == 4) {
									print(request.status + " " + request.statusText);
								}
							}
							request.send(null);
						

XML 데이터 조회

그럼 요청 객체를 XML HTTP 요청이라고 부르는 이유는 뭘까? 이것은 약간 오해를 불러일으키는 이름이다. XML은 텍스트 형식의 데이터를 저장하는 수단이다. XML에서는 HTML과 같은 태그와 속성을 사용하지만 좀 더 구조적이고 유연하다. 즉, 자체적으로 만든 데이터 형식을 저장하려면 직접 XML 태그의 유형을 정의하면 된다. 이러한 HTTP 요청 객체에는 수신한 XML 문서를 다루기 위한 내장 기능이 일부 포한돼 있는데, 이런 이유로 XML이 이름에 들어 있는 것이다. 하지만 HTTP 요청 객체는 다른 유형의 문서도 처리할 수 있으므로 HttpRequest가 좀 더 적절한 이름일 것이다.

요청 객체로 받은 파일이 XML 문서라면 요청의 responseXML 프로퍼티에 이 문서를 표현한 내용이 담길 것이다. 이러한 내용은 style이나 innerHTML과 같은 HTML에 특화된 기능을 제외하고 10장에서 살펴본 DOM 객체처럼 동작한다. responseXML에는 문서 객체가 담겨 있으며, 해당 객체의 docuemntElement 프로퍼티는 XML 문서의 바깥 태그를 가리킨다. 다음과 같은 문서가 있다고 해보자(files/fruit.xml).

							<fruits>
								<fruit name="banana" color="yellow" />
								<fruit name="lemon" color="yellow" />
								<fruit name="cherry" color="red" />
							</fruits>
						

이 파일은 다음과 같은 방식으로 받을 수 있다.

							request.open("GET", "files/fruit.xml", true);
							request.send(null);
							request.responseXML.documentElement.childNodes.length;
							// 3
						

XML 문서는 서버와 구조적인 정보를 교환할 때 사용할 수 있다. XML 형태(다른 태그 안에 태그가 담긴)는 단순 평문 텍스트로는 표현하기 까다로운 것들을 저장하는 데 아주 적합하다. 하지만 DOM 인터페이스는 정보를 추출하기가 다소 성가시고, XML 문서는 다소 장황한 면이 있다.


JSON 데이터 읽기

XML의 대안으로 자바스크립트 프로그래머들은 자바스크립트 객체 표기법(JSON, Javascript Object Notation)이라는 것을 생각해냈다. JSON은 자바스크립트 값 문법을 이용해 좀 더 최소주의적인 방식으로 구조적인 정보를 표현한다.

JSON 문서는 단 하나의 자바스크립트 객체나 배열이 담긴 파일로, 여기엔 다른 객체, 배열, 문자열, 숫자, 불리언, null 값이 갯수와 상관없이 담긴다. 예를 들어 다음 코드는 fruit.json 파일의 모습을 보여준다.

							{
								"banana": "yellow",
								"lemon": "yellow",
								"cherry": "red"
							}
						

이러한 텍스트 조각은 eval 함수를 이용해 일반 자바스크립트 값으로 변환할 수 있다. eval 함수는 전달된 텍스트를 자바스크립트 프로그램으로 평가한다. 이를테면 eval("1+1")을 실행하면 2가 나온다. 이 경우 실제 배열 객체가 되게끔 JSON 문서에 담긴 배열을 평가하고자 한다.

jSON 문서를 eval 함수에 전달하기 전에 그것을 괄호로 감싸야 하는데, 프로그램에서 { 문자로 시작하면 해당 문자가 객체의 시작이 아니라 코드 블럭의 시작으로 해석될 것이기 때문이다. 다음 프로그램은 과일 데이터를 가져온 후 레몬의 색깔을 확인한다.

							request.open("GET", "files/fruit.json", true);
							request.onreadystatechange = function () {
								if (request.readyState == 4) {
									var data = eval("("+ request.responseText + ")");
									print(data["lemon"]);
								}
							}
							request.send(null);
						

텍스트 조각을 대상으로 eval 함수를 실행할 때 염두에 둬야 할 것이 하나 있다. 이렇게 할 경우 코드상에서 원하는 텍스트 조각이라면 어떤 것이든 실핼될 수 있다는 점이다. 자바스크립트에서는 여러분이 소유한 도메인에 대해서만 요청할 수 있게 허용하고, 보통 여러분도 자신이 받는 텍스트의 종류를 정확히 알고 있을 것이므로 이것은 문제가 되지 않는다. 텍스트를 제어할 수 없는 상황에서는 eval 함수를 호출하는 것을 권장하지 않는다. 그러한 겨우 시스템이나 사이트 사용자가 위험에 처할 수도 있다.


기초적인 요청 래퍼

다량의 요청을 할 때는 매번 open, send, onreadystatechange로 이어지는 전체 과정을 되풀이하고 싶지 않을 것이다. 아주 간단한 래퍼를 작성한다면 다음과 같은 모습일 것이다.

							function simpleHttpRequest (url, success, failure) {
								var request = requestObject();
								request.open("GET", url, true);
								request.onreadystatechange = function () {
									if (request.readyState == 4) {
										if (request.status == 200 || !failure) {
											success(request.responseText);
										}else if (failure) {
											failure(request.status, request.statusText);
										}
									}
								};
								request.send(null);
							}
						

이 함수에서는 지정한 URL을 가져와서 두 번째 인자로 지정한 함수를 콘텐츠와 함께 전달한다. 세 번째 인자를 지정할 경우 이 인자는 실패(상태 코드가 200이 아닌)를 나타내는 데 사용된다.

좀 더 복잡한 요청을 할 수 있으려면 이 함수에 메서드(GET 이나 POST)를 명시하는 추가적인 매개변수를 비롯해 데이터로 전송할 선택적인 문자열과 헤더를 추가하는 방법 등을 지정할 수 있어야 한다. 인자가 너무 많으면 7장에서 보여준 것처럼 인자 객체를 사용해야 할 것이다.


HTTP 학습

HTTP는 매우 지능적이고 유연한 프로토콜이다. HTTP를 많이 사용하거나 특히 HTTP 인터페이스(거의 모든 서버 측 웹 프로그래밍에서 생기는)를 설계하게 된다면 먼저 HTTP 프로토콜이 실제로 동작하는 방식을 연구하길 바란다.

이렇게 부탁하는 이유는 HTTP를 다루는 대부분의 프로그래머가 HTTP의 극히 일부만을 이해한 채로 업무에 임하기 때문이다. 나 또한 그랬다. 그러한 프로그래머들은 캐싱(동일한 문서를 반복해서 가져오는 것을 막는 메커니즘)이나 인터넷 미디어 타입(문서의 형식을 식별하는 방법)과 같은 기능을 적절히 이용하는 방법이라든가 심지어 다루는 방법조차 모르며, 그 결과 HTTP의 사용을 '감추려는' 시도 속에서 과도하게 복잡하고 불안정하며 비뚤어진 래퍼를 만들게 된다. 제대로 사용하기만 한다면 HTTP는 대다수의 통신 형태와도 잘 어울리고

HTTP에 관한 참고할 수 있는 다양한 책과 인터넷 참고 자료가 있다. 늘 그렇듯이 아는 게 별로 없는 사람들은 말을 많이 하는 경향이 있으므로 인터넷 게시판과 웹 사이트에 맞춤법이 특린 채로 올려진 조언들은 조심해서 받아들여야 한다. 기술적인 부분에 관심이 많은 사람들에게는 HTTP 표준이 실제로 아주 훌륭하고 도움이 되는 읽을 거리가 많지만 대부분의 표준 문서와 마찬가지로 다소 난해한 측면이 있다. 좀 더 읽기 수월한 참고 자료로는 고얼리(Gourley)와 토티(Totty)가 쓰고 오라일리에서 출간한 [HTTP: The Definitive Guide]가 있다.