HTTP(HyperText Transfer Protocol, 문화어: 초본문전송규약, 하이퍼본문전송규약)는 W3 상에서 정보를 주고받을 수 있는 통신 프로토콜이다. 주로 'HTML 문서를 전송'하는 용도에 쓰인다. TCP를 사용하고 HTTP/3부터는 UDP 및 80번 포트를 사용한다. 1996년 버전 1.0, 그리고 1999년 1.1이 각각 발표되었다.
HTTP는 클라이언트와 서버 사이에 이루어지는 상호 대화를 위한 요청-응답 프로토콜이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지(HTML)나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 나타나는 것이다.
HTTP를 통해 전달되는 자료는 http:로 시작하는 URL(인터넷 주소)로 조회할 수 있다.
하이퍼텍스트라는 용어는 1965년 제너두 프로젝트에서 테드 넬슨이 만들었으며, 제너두 프로젝트는 《As We May Think》(1945년)라는 수필에서 마이크로필름 기반 정보 수신 및 관리 "메멕스" 시스템을 기술한 버니바 부시의 비전(1930년대)에 의해 영감을 받았다. 팀 버너스 리와 그의 팀은 CERN에서 HTML뿐 아니라 웹 브라우저 및 텍스트 기반 웹 브라우저 관련 기술과 더불어 오리지널 HTTP을 발명하였다. 버너스 리는 최초로 "월드와이드웹" 프로젝트를 1989년에 제안하였으며, 이것이 현재의 월드 와이드 웹이다. 이 프로토콜의 최초 버전은 서버로부터 페이지를 요청하는 GET이라는 이름의 하나의 메소드만 있었다.[1] 서버로부터의 응답은 무조건 HTML 문서였다.[2]
문서화된 최초의 HTTP 버전은 HTTP V0.9(1991년)이다. 데이브 레겟은 1995년 HTTP 워킹 그룹(HTTP WG)을 이끌었으며 확장된 조작, 확장된 협상, 더 보강된 메타 정보, 또 추가 메소드와 헤더 필드를 통한 더 효율적인 보안 프로토콜을 갖춘 프로토콜을 확장하기를 바랐다.[3][4] RFC 1945는 공식적으로 1996년 HTTP v1.0을 도입하였다.
HTTP WG는 1995년 12월 새로운 표준을 출간하기로 계획하였으며[5] 당시 개발 중인 RFC 2068(이른바 HTTP-NG)에 기반한 이전 표준 HTTP/1.1에 대한 지원이 1996년 초에 주요 브라우저 개발자들에 의해 빠르게 채택되었다. 1996년 3월, 이전 표준 HTTP/1.1을 지원한 웹 브라우저로 아레나,[6]넷스케이프 2.0,[6] 넷스케이프 내비게이터 골드 2.01,[6]모자이크 2.7, 링크스 2.5, 인터넷 익스플로러 2.0이 있다. 새로운 브라우저의 최종 사용자 채택 속도를 빨랐다. 1996년 3월, 한 웹 호스팅 회사의 보고에 따르면 인터넷 상에서 사용 중인 브라우저 중 40% 이상이 HTTP 1.1과 호환되었다. 같은 웹 호스팅 회사는 1996년 6월 기준으로 서버에 접근하는 모든 브라우저들 가운데 65%가 HTTP/1.1 호환이라고 보고하였다.[7] RFC 2068에 정의된 HTTP/1.1 표준은 공식적으로 1997년 1월에 출시되었다. HTTP/1.1 표준에 대한 개선과 업데이트는 1999년 6월 RFC 2616으로 출시되었다.
2007년에 부분적으로 HTTP/1.1 사양을 개정하고 분명히 하기 위해 HTTPbis 워킹 그룹이 창설되었다. 2014년 6월, WG는 RFC 2616를 obsolete 처리하는, 업데이트된 6 파트 사양을 출시하였다:
클라이언트와 서버 사이의 소통은 평문(ASCII) 메시지로 이루어진다. 클라이언트는 서버로 요청메시지를 전달하며 서버는 응답메시지를 보낸다.
요청 메시지
클라이언트가 서버에게 보내는 요청 메시지는 다음과 같다.
요청 내용
보기) GET /images/logo.gif HTTP/1.1
헤더
보기) Accept-Language: en
빈 줄 (empty line)
기타 메시지를 포함하여 표시된다.
요청 내용과 헤더 필드는 <CR><LF>로 끝나야 한다. 즉, 캐리지 리턴(carriage return) 다음에 라인 피드(line feed)가 와야 한다. 빈 줄(empty line)은 <CR><LF>로 구성되며 그 외 다른 화이트스페이스(whitespace)가 있어서는 안된다.
HTTP/1.1200OKDate:Mon, 23 May 2005 22:38:34 GMTContent-Type:text/html; charset=UTF-8Content-Encoding:UTF-8Content-Length:138Last-Modified:Wed, 08 Jan 2003 23:11:55 GMTServer:Apache/1.3.3.7 (Unix) (Red-Hat/Linux)ETag:"3f80f-1b6-3e1cb03b"Accept-Ranges:bytesConnection:close<html><head><title>An Example Page</title></head><body>
Hello World, this is a very simple HTML document.
</body></html>
↑“HTTP/1.1”. 《Webcom.com Glossary entry》. 2001년 11월 21일에 원본 문서에서 보존된 문서. 2009년 5월 29일에 확인함.
↑이 메시지는 HTTP 1.0에서는‘Moved Temporarily’였다. 그리고 HttpServletResponse의 상수는 SC_FOUND가 아니라 C_MOVED_TEMPORARILY다. 이것은 매우 유용한 헤더인데 이 헤더를 통해 브라우저가 자동적으로 새 URL의 링크를 따라가기 때문이다. 이 상태 코드는 아주 유용하기 때문에 이 상태 코드를 위해 sendRedirect 라는 특별한 메서드가 있다. response.sendRedirect(url)을 사용하는 것은 response.setStatus(response.SC_MOVED_TEMPORARILY)과 response.setHeader("Location", url)를 쓰는 것에 비해 몇 가지 장점이 있다. 첫째, 더 쉽게 사용할 수 있다. 둘째, sendRedirect을 써서 서블릿이 그 링크를 포함한 페이지를 자동으로 만들어 준다(자동으로 redirect를 따라갈 수 없는 오래 된 브라우저에서도 볼 수 있게 해 준다). 마지막으로, sendRedirect에서는 상대 URL이 절대 URL로 해석되기 때문에 상대 URL도 다룰 수 있다. 이 상태 코드는 종종 301번과 혼용된다. 예를 들어 <http://host/~user[깨진 링크(과거 내용 찾기)]> (마지막에 '/'가 빠짐)과 같이 오류가 있는 요청에 대해 어떤 서버는 301을 어떤 서버는 302를 보낸다. 기술적으로 브라우저는 원 요청이 GET이었다면 자동적으로 리다이렉션을 따라 가도록 되어 있다. 더 자세한 사항은 307 헤더를 보라.
↑이 경우, 여러분이 요청한 자원에 접근할 수 있는 권한을 부여받기 위해 서버 운영자에게 요청해야 할 것이다.
↑이것은 일반적으로 적절한 www-authenticate head field를 전송하지 않아서 발생한다.
↑이 자원은 페이지가 될 수도 있고, 클라이언트의 주소 입력란에 명기된 파일일 수도 있다. 아니면 클라이언트가 행당 주소로 들어갈 때 이용되는 또 다른 파일일 수도 있다. 여러분이 접근할 전체 주소를 다시 확인해 보고 웹 서버 운영자에게 여러분이 자원에 접근할 권한이 있는지를 확인해 본다.
↑요청 사항에 필요한 자원은 요청 사항으로 전달된 Acceptheader에 따라 "Not Acceptable"인 내용을 가진 Response 개체만을 만들 수 있다.
↑해당 요청이 수행되도록 프록시 서버에게 인증을 받아야 한다. 프록시 서버로 로그온 한 후에 다시 시도해 본다.
↑현재 자원의 메타-정보가 하나 이상의 자원에 적용되는 것을 막기 위한 클라이언트 선결조건이 의도되었다.
↑만약 서버에서 나중에 다룰 수 있다고 생각되면 Retry-After 헤더를 포함시켜야 한다.
↑요청한 URI가 너무 길어서 서버가 요청 사항의 이행을 거부했다. 이렇게 희귀한 상황은 아래와 같은 경우에만 발생한다. 클라이언트가 긴 탐색용 정보를 가지고 POST 요청을 GET으로 부적절하게 전환했다. 클라이언트가 Redirection 문제를 접하게 되었다. 서버가, 몇몇 서버가 사용하고 있는 요청한 URI를 읽고 처리하는 고정된 길이의 메모리 버퍼를 이용해 보안체계에 들어가려는, 클라이언트에 의한 공격을 받고 있다.
↑서버가 요청사항을 수행하는 데 필요한 기능을 지원하지 않는다. 오류가 발생한 URL을 확인한 후에, 문제가 지속될 경우에는 웹 서버 운영자에게 연락한다.
↑서버의 과부하 상태Gateway나 proxy로 활동하고 있는 서버가 요구 사항을 접수한 upstream 서버로부터 불명확한 답변을 접수 했을 때 발생한다. 만약 문제가 지속된다면 웹 서버 운영자와 상의해 본다.
↑서버는 현재 일시적인 과부하 또는 관리(유지,보수) 때문에 요청을 처리할 수 없다. 이것은 약간의 지연 후 덜게 될 일시적인 상태를 말한다. Retry-After 헤더에 지연의 길이가 표시될 수도 있다. 만약 Retry-After를 받지 못했다면 클라이언트는 500 응답을 위해 하고자 했는 것처럼 응답을 처리해야 한다. 상태코드의 존재는 서버가 과부하가 걸릴때 그것을 사용해야한다는 것을 말하는 것이 아니다. 몇몇 서버는 접속을 거부하는 것을 바랄지도 모른다.
HTTP 상태 코드 문서를 참고하십시오.
