HTTP Method

1. HTTP method

∙ HTTP method란 브라우저가 서버로 데이터를 전달하는 방법을 의미한다.

∙ HTTP method는 request header 부분에 명시됨

∙ HTTP method의 종류 : GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS의 7가지

∙ HTTP/1.0에서는 GET, POST, HEAD만 사용되었으며, HTTP/1.1에서 PUT, DELETE, TRACE, OPTIONS가 추가되었다.

 

1. GET

∙ GET method는 서버 상의 확실한 URL에 위치한 정보에 대한 요청이다.

∙ GET 방식은 폼의 자료들을 URL뒤에 붙여 작성한다.

∙ 브라우저는 시각적으로 보여주기 위해 HTML 문서를 검색하는데 GET을 사용한다.

∙ 하이퍼링크 안에 있는 하나의 URL처럼 쌍을 이룬 값을 넣음으로써, 쉽게 검색기가 GET메소드 요청을 실행시킬 수 있다.

(예)<A href="http://../Image.exe?Disc=39000&format=Terse>

∙ <FORM>태그의 method 파라미터가 GET을 지명했을 때는, 다음과 같다.

<FORM method="GET">

<FORM name="Sample" method="GET" action="out.jsp"> <P>GET방식 자료 전송 예<BR><BR> 방문자의 이름을 입력하세요 <INPUT type="text" name="visitor_name" size="20"><BR><BR> <INPUT type="submit" value="서버로 보내기“ name="button1">&nbsp <INPUT type="reset" value="다시 작성“ name="button2"></P> </FORM>

∙ 주어진 폼에서 Submit 버튼을 클릭하면 데이터를 GET 방식으로 전송한다. 아래 결과화면의 주소란을 살펴보자.

  POST 방식과 다른 점은 URL 뒤에 자료가 붙어서 보내진다는 것이다.

  즉, GET 방식으로 전송하는 경우 주소란에 전송하는 자료와 변수이름이 보인다.

http://......./sample_code/out.asp?visitor_name=bluetooth

∙ name=value 쌍은 URL과 "?" 마크 뒤에 덧붙여진다.

 ∙ name=value 쌍은 "&"마크에 의해 분리된다.

∙ GET 방식을 이용하면 클라이언트에서 서버로 보낸 자료가 URL에서 모두 노출되기 때문에 비밀번호와 같은 보안 정보를 GET 방식으로 보내는 것은 위험할 수 있다.

∙ GET 방식으로 보낼 수 있는 자료의 양은 한계가 있기 때문에 많은 데이터를 보내는 경우 일정 크기 이상에서

  잘릴 수 있다. 이러한 문제를 해결할 수 있는 방식이 POST 방식이다.

 

2. POST

∙ POST 방식은 입력 자료들을 URL의 뒷부분에 추가해서 보내는 것이 아니라 HTTP 헤더 안에 넣어 보낸다.

∙ POST method는 데이터가 클라이언트의 요청 안에 있는 서버로 보내지는 것을 허락한다.

∙ 이 기술은 데이터 베이스 작업을 위한 인터페이스 보완을 비롯하여 더 많은 목적을 위해 이용될 수 있다.

∙ GET method를 가지고 하는 것과 마찬가지로, 데이터는 서버 프로그램에 의해 수행 될 수 있는 name=value

  쌍으로 구성된다.

∙ 일반적으로, 웹 클라이언트 요청의 바디(body)로 보내진 데이터는 URL을 이용하여 전환된다.-URL 내부에서 특별한

  의미를 갖는 공백과 문자를 전환하는 코딩화 작업-예를 들면. "/"는 그에 해당하는 16진수 값으로 전환된다.

∙ GET  method에 비유되는 POST method를 이용하는 이점은 POST를 이용해 보내진 데이터는 브라우저 안의 URL

  처럼 눈에 보이지 않는다는 것이다.

∙ 브라우저에 의해 보내진 데이터는 <FORM>태그가 method="POST" 속성을 이용한 HTML폼에 의해 만들어진

  HTTP 요청의 바디(body)에 위치한다.

<FORM name="Sample" method="POST" action="out.jsp"> <P>GET방식 자료 전송 예<BR><BR> 방문자의 이름을 입력하세요 <INPUT type="text" name="visitor_name" size="20"><BR><BR> <INPUT type="submit" value="서버로 보내기“ name="button1">&nbsp <INPUT type="reset" value="다시 작성“ name="button2"></P> </FORM>

∙ Submit 버튼을 누르는 순간 폼의 자료들은 인코딩되어 전송되며 주소란에서는 보이지 않는다. 따라서, GET 방식에서 발생할 수 있는 보안 문제를 해결할 수 있다.

 

3. HEAD

∙ HEAD method는 서버에 있는 문서를 검색하는 데 이용되는 것이 아니라, 문서에 대한 정보를 찾는데 이용된다.

∙ HEAD method는 서버가 응답 메시지에 Message-Body를 반드시 리턴해야 한다는 것 이외에는 GET과 동일하다.

∙ HEAD 요구에 대한 응답으로 HTTP 헤더에 포함된 메타 정보는 GET 요구에 대한 응답으로 발송된 정보와 반드시

  동일해야 한다.

∙ HEAD method는 Entity-Body 자체를 전송하지 않고도 요구가 내포하는 엔터티에 대한 메타 정보를 얻는 데 사용할

  수 있다.

∙ HEAD method는 종종 하이퍼텍스트 링크의 유효성, 접근성 및 최근의 변경 사항을 테스트하기 위해 사용된다.

∙ HEAD 요구에 대한 응답은 응답에 포함된 정보를 해당 자원의 이전 캐시 엔터티를 갱신하는데 사용할 수 있다는

  의미에서 캐시 할 수 있다. 새로운 필드 값이 캐시 된 엔터티가 현재의 엔터티(Content-Length, Content-MD5,

   ETag 또는 Last-Modified의 변화에 의해 표시되는 것과 같은)와 상이함을 표시할 때는 캐시는 반드시 이 캐시 엔트

    리를 낡을 것으로 취급해야 한다.

 

4. PUT

∙ PUT method는 동봉된 엔터티를 제공된 Request-URI에 저장하도록 요구한다.

∙ Request-URI가 이미 존재하는 자원을 지칭할 경우 동봉된 엔터티는 원서버에 있는 엔터티의 변경된 버전으로 간주해야 한다. Request-URI가 기존 자원을 지칭하지 않고 URI가 요구하는 사용자 에이전트가 새로운 자원으로 규정할 수 있다면 원서버는 해당 URI로 자원을 생성할 수 있다.

∙ 만약 새로운 자원이 생성되었으면 원서버는 사용자 에이전트에게 201(Created) 응답을 알려야 한다. 기존

  자원이 변경되었다면 200(OK)이나 204(No Content) 응답 코드를 발송하여 요구를 성공적으로 완료하였음을

  표시하여야 한다.

∙ Request-URI로 자원을 생성하거나 변경할 수 없는 경우에는 문제의 기본 성격을 반영하는 적절한 에러

  응답을 발송해야 한다. 엔터티의 수신측은 이해 또는 구현할 수 없는 Content-* (예: Content-Range) 헤더를

  반드시 무시해야 하고 이러한 경우 501(Not Implemented) 응답을 리턴해야 한다.

∙ 요구가 캐시를 통과할 경우 Request-URI는 하나 또는 그 이상의 현재 캐시 된 엔터티를 식별한다. 이러한

  엔터티는 낡은 것으로 취급해야 하며 이러한 method에 대한 응답은 캐시할 수 없다.

​∙ POST와 PUT 요구의 근본적인 차이점은 Request-URI의 다른 의미에 반영된다. POST의 URI는 동봉된

 엔터티를 처리할 자원을 식별한다. 그 자원은 데이터를 접수하는 프로세스, 다른 규약으로의 게이트웨이 또는 

 주석을 접수하는 별도의 엔터티일 수 있다. 이에 비하여 PUT 요구의 URI는 요구에 포함된 엔터티를 식별한다.

∙ 단일 자원이 복수의 상이한 URI에 의하여 식별될 수 있다. 예를 들어 기사(article)는 각각의 특별한 버전을 식

  별하는 URI와 구별되는 "현재 버전"을 확인하기 위한 URI를 가질 수 있다. 이 경우 일반 URI의 PUT 요구는 원

  서버에 의하여 규정되는 복수의 URI를 생성할 수도 있다.

 

5. DELETE

∙ DELETE method는 Request-URI가 식별하는 자원을 삭제하도록 원서버에 요구한다.

∙ DELETE method는 원서버에서 사용자의 개입(또는 다른 방법)에 의하여 무시될 수 있다.

∙ 클라이언트는 비록 원서버에서 발송한 상태 코드가 해당 작업이 성공적으로 완수되었다는 표시를 하여도 실

  제로 작업이 완료되었다는 보장을 받을 수 없다. 그러나 서버는 요구를 접수한 시점에서 자원을 삭제하거나

  접근할 수 없는 위치로 이동할 의사가 없는 한 성공을 표시해서는 안 된다.

∙ 성공적인 응답은 응답이 상태를 설명하는 엔터티를 포함한다면 200 (OK), 처리가 시작되지 않았으면 202 (Accepted), 응답은 OK이나 엔터티를 포함하지 않고 있으면 204 (No Content)이다.

∙ 요구가 캐시를 통과할 경우 Request-URI는 하나 또는 그 이상의 현재 캐시 된 엔터티를 식별한다. 이러한 엔

  터티는 낡은 것으로 취급해야 하며 이러한 method에 대한 응답은 캐시할 수 없다.

 

6. TRACE

∙ TRACE method는 요구 메시지의 원격지, 애플리케이션-계층 루프백(loop back)을 호출하는데 사용한다.

∙ 요구 메시지의 최종 수신처까지의 루프백 검사용으로 쓰인다. 즉, 클라이언트가 보내는 요구 메시지가

  거쳐가는 프락시나 게이트웨이의 중간 경로 및 최종 수신 서버까지 이르는 경로를 알아내는 데에 쓰인다.

∙ 함께 사용되는 헤더 필드는 Max-Forwards라고 하는 것이며, 중간에 거쳐갈 프락시나 게이트웨이 경로의 최대

  숫자를 지정하는 것이다.

∙ 응답의 최종 수신측은 클라이언트에게 되돌려 진 메시지를 200(OK) 응답의 Entity-Body로 수신해야 한다. 마

  지막 수신측은 메시지의 Max-Forwards 제로 값을 수신하는 원서버, 첫 프락시 또는 게이트웨이이다.

∙ TRACE 요구는 절대 엔터티를 포함해서는 안 된다.

∙ TRACE는 클라이언트가 Request chain의 다른 끝 쪽에 무엇이 수신되는가를 알 수 있게 하며 그 데이터를 시

  험 또는 진단 정보로 사용한다.

∙ Max-Forwards 헤더 필드를 사용하면 클라이언트가 Request chain의 길이를 제한할 수 있으며 이는 무한 루프에서 메시지를 전달하는 프락시 고리를 테스트하는 데 유용하다.

∙ 성공적이면 응답은 "message/http" 의 Content-Type을 가진 Entity-Body의 전체 요구 메시지를 포함할 수 있어

 야 한다. 이러한 method에 대한 응답을 절대 캐시해서는 안 된다.

​

7. OPTIONS

∙ OPTIONS method는 Request-URI에 의하여 식별되는 요구/응답의 관계 (Request / Response chai

  n)에서 사용할 수 있는 통신 선택 사항에 관한 정보 요구를 표시한다.

∙ OPTIONS method는 클라이언트가 자원 처리를 시도하거나 자원 조회를 시작하지 않고도 선택 사항 및/또는

  자원과 관련된 필요 조건, 서버의 처리 능력을 결정할 수 있게 한다.

∙ 이를 통해 클라이언트는 어느 것을 선택할지 결정할 수 있으며 또는 자원과 관련된 필요사항도 결정할 수 있다. ​

  그리고 서버의 수행 능력에 대해서도 알아볼 수 있다.

∙ 자원에 대한 어떤 동작을 수행시키거나 갖고 온다든지 하는 동작은 허용되지 않는다.

∙ 서버의 응답이 에러가 아닌 이상 응답은 통신 선택 사항이라고 간주할 수 있는 것 이외의 엔터티 정보를 포함

  해서는 안 된다.(예를 들어 Allow 는 적합하지만 Content-Type은 적합하지 않다).

∙ Request-URI 가 별표("*")이면 OPTIONS 요구는 전체를 서버에 적용하려는 것이다. 200 응답은 모든 적용 가

  능한 일반 필드 또는 Response-Header 필드 이외에 이 규격에서 규정하지 않는 모든 확장을 포함하여 서버가

  구현한(예 Public) 선택 기능을 표시하는 모든 헤더 필드를 포함해야 한다. "OPTIONS *" 요구는 경로 정보 없

  이 Request-URI에 목적지 서버를 명시함으로써 프락시를 통하여 적용할 수 있다.

∙ Request-URI가 별표가 아니면 OPTIONS 요구는 해당 자원과 통신할 때 사용할 수 있는 선택 사항에만 적용된

  다. 200 응답은 모든 적용 가능한 일반 필드 또는 Response-Header 필드 이외에 이 규격에서 규정하지 않는

  모든 확장을 포함하여 서버가 구현한(예 Allow) 선택 기능을 표시하는 모든 헤더 필드를 포함해야 한다.

∙ OPTIONS 요구가 프락시를 통한다면 프락시는 프락시의 성능에 관계되는 선택 사항 및 프락시를 통하여 사용할 수 없

  는 것으로 알려진 선택 사항을 제외할 수 있도록 응답을 반드시 편집해야 한다.

 

 

￭ 용어 설명

[엔터티(entity), 개체]

데이타 자원의 특정한 표현 형태나 연출된 형태, 또는 어느 서비스 자원으로부터의 응답이 엔터티가 될 수 있으며, 이것은 요구 또는 응답 메시지에 포함될 수 있어야 한다. 엔터티는 엔터티 영역에 있는 내용과 엔터티 헤더의 형태로 되어 있는 메타정보(metainformation)로 구성되어 있다.

Entity는 Entity-Header 필드와 Entity-Body로서 구성된다.

 

[URI (Uniform Resource Identifiers)]

URI는 현재 여러 가지 이름으로 불리우고 쓰이고 있다. 예를 들어, WWW addresses, Universal Document Identifiers, Universal Resource Identifiers 등이며, 최종적으로 URL(Uniform Resource Locators)과 URN(Uniform Resource Names)의 결합으로 정의되고 있다. 이것은 하나의 대상체에 대해 이름, 위치, 서비스, 프로토콜 등등 여러 가지 요소들을 참조할 수 있게 형식화시킨 것이다.

 

[Request-URI]

요구 메시지에 있는 Method에 의해 지정되는 동작을 어느 장소에 있는 대상에게 적용할 것인지 나타낸다.

 

참고 자료

1) RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1

2) RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0

4) Arnaud Le Hors, Dave RagGett, Ian Jacobs 1998.4 정보시대 -- HTML 4.0 규격

5) 황인태, 1999, 성인당 -- HTML Master

6) http://www.w3.org/Protocols/HTTP/