HTTP는 HTTP Method라고 불리는 여러 가지 종류의 요청 명령을 지원한다. 모든 HTTP 요청 메시지는 한 개의 Method를 갖는다.
Method는 서버에게 어떤 동작이 취해져야 하는지 알려준다.
아래 표는 흔히 사용되는 HTTP Method 목록이다.
| HTTP Method | 설명 |
| GET | 서버에서 클라이언트로 지정한 리소스를 보내라 |
| PUT | 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장 |
| DELETE | 지정한 리소스를 서버에서 삭제 |
| POST | 클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라 |
| HEAD | 지정한 리소스에 대한 응답에서 HTTP 헤더 부분만 보내라 |
안전한 Method
HTTP는 안전한 Method라 불리는 Method의 집합을 정의한다. GET과 HEAD를 안전한 Method로 정의한다.
이 말은 두 Method는 서버에 어떠한 작용도 없음을 의미한다.
=> HTTP 요청의 결과로 인해 서버에서 일어나는 일은 아무것도 없다.
근데 또 이 Method를 개발자가 어떻게 사용하는지에 따라 서버에 영향을 미칠 수도 있고 그렇다...
안전한 Method를 정의해 놓은 가장 큰 이유는 서버에 어떤 영향을 줄 수 있는 안전하지 않은 Method가 사용될 때 사용자에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있다고 한다.
GET
가장 흔하게 사용되는 Method로, 서버에게 리소스를 달라고 요청하기 위해 사용된다.
메시지의 엔티티 본문 없이 요청 URL에 다 때려넣음
아래는 GET Method를 사용해 요청을 한 경우의 패킷 예시다.
| -요청- GET /laoching/blog/test.html HTTP/1.1 Host: www.laoching.tistory.com Accept: * -응답- HTTP/1.1 200 OK Content-Type: text/html Context-Length: 123 <html> <head><title>this is test</title></head> ........... |
HEAD
GET과 같은 동작을 보여주지만 응답으로 헤더만을 돌려준다.
엔티티 본문을 절대 반환하지 않음
그럼 왜 사용하는가??
=> 클라이언트가 서버의 리소스를 가져오지 않고도 헤더만을 조사할 수 있음
| 1. 리소스를 가져오지 않고도 그에 대해 무엇인지 대충 파악 가능(ex: content-type 등) 2. 응답 상태 코드를 통해 개체의 존재 여부 파악 가능(ex: 404 나오면 없는 것, 403 나오면 있는 것) 3. 헤더를 확인해 리소스가 변경되었는지 검사 가능 |
아래는 HEAD Method 사용 시 보여지는 패킷의 예시이다.
GET과 달리 엔티티 본문이 없음
| -요청- HEAD /laoching/blog/test.html HTTP/1.1 Host: www.laoching.tistory.com Accept: * -응답- HTTP/1.1 200 OK Content-Type: text/html Context-Length: 123 |
PUT
PUT은 서버에 문서를 쓰는 동작을 한다.
서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해 교체한다.
콘텐츠를 변경할 수 있는 Method기 때문에 많은 웹 서버에서는 PUT Method를 사용할 경우에 인증 절차를 거친다.(ex: 패스워드를 통한 사용자 인증)
아래는 PUT Method 사용 시 보여지는 패킷의 예시이다.
응답의 201 Created에서 Created(사유구절)는 임의로 작성이 가능하다. HTTP는 200, 404와 같은 숫자만 보고 통신을 하기 때문에 숫자만 보자.(200 Denied라고 쓰여있어도 이건 OK인거임 사실)
| -요청- PUT /laoching/blog/food_list.txt HTTP/1.1 Host: www.laoching.tistory.com Content-Type: text/plain Content-Type: 25 this is PUT Method test! Accept: * -응답- HTTP/1.1 201 Created Location: https://www.laoching.tistory.com/blog/food_list.txt Content-Type: text/plain Context-Length: 25 https://www.laoching.tistory.com/blog/food_list.txt |
POST
서버에 입력 데이터를 전송하기 위해 설계된 Method로 HTML 폼을 지원하기 위해 흔히 사용된다.
폼에 담긴 데이터는 서버로 전송되고, 서버는 이를 모아서 필요로 하는 곳(예를 들면 그 데이터를 처리할 서버 게이트웨이 프로그램)에 보낸다.
아래는 POST Method 사용 시 보여지는 패킷의 예시이다.
브라우저는 메시지의 엔티티 본문에 데이터를 집어넣는다.
cnt라는 변수에 zerocoke를 넣고 그것의 재고 상황을 반환해주는 예시이다.
| -요청- POST /laoching/blog/item_count.cgi HTTP/1.1 Host: www.laoching.tistory.com Content-Type: text/plain Content-Type: 13 cnt=zerocoke -응답- HTTP/1.1 200 OK Content-Type: text/html Context-Length: 25 The zerocoke is in stock |
TRACE
클라이언트가 서버로 요청을 전달하면, 그 요청은 방화벽, 프록시, 게이트웨이 등의 애플리케이션들을 통과할 수 있는데, 이들에게는 원래의 HTTP 요청을 수정할 수 있는 기회가 있다.
TRACE Method는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려주는 동작을 한다.
=> 목적지 서버에서 루프백 진단을 수행한다. 요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려준다.
클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답을 따라가면서 자신이 보낸 메시지가 망가졌거나 수정되었는지, 만약 그렇다면 그 내용을 확인할 수 있다.
이러한 동작의 특성 때문에 요청이 전달되는 과정과 중간에 위치하는 애플리케이션이 어떤 동작을 하는지 점검할 때 사용된다.
하지만 HTTP 애플리케이션은 Method에 따라 다르게 동작하고, 이는 TRACE 요청을 어떻게 처리할 것인지는 해당 애플리케이션이 결정한다는 말을 뜻한다.
또 TRACE Method는 어떠한 엔티티 본문도 보낼 수 없다. 엔티티 본문에는 서버가 받은 요청이 그대로 들어있을 뿐이다.
아래는 TRACE Method 사용 시 보여지는 패킷의 예시이다.
Via: ~~부분은 중간에 위치해 패킷이 거쳐간 HTTP 애플리케이션의 주소가 적혀있다.
| -요청- TRACE /laoching/blog/test.html HTTP/1.1 Host: www.laoching.tistory.com Accept: * -응답- HTTP/1.1 200 OK Content-Type: text/html Context-Length: 123 TRACE /laoching/blog/test.html HTTP/1.1 Host: www.laoching.tistory.com Accept: * (Via: ~~~) |
OPTIONS
웹 서버에게 어떤 Method를 허용해놨는지 확인하는 데 사용된다. 여러 Method를 사용하지 않고도 어떤 Method가 사용 가능한지 확인할 수 있기 때문에 점검 시 유용하게 사용된다.
아래는 OPTIONS Method 사용 시 보여지는 패킷의 예시이다.
아래의 경우는 GET, POST, HEAD Method만 사용이 가능하다는 것을 의미한다.
| -요청- OPTIONS * HTTP/1.1 Host: www.laoching.tistory.com Accept: * -응답- HTTP/1.1 200 OK Allow: GET, POST, HEAD Context-Length: 0 |
DELETE
서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다.
하지만 클라이언트가 삭제를 요청한다고 해서 무조건 지워진다는 보장이 없다.
HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.
아래는 DELETE Method 사용 시 보여지는 패킷의 예시이다.
| -요청- DELETE /laoching/blog/test.html HTTP/1.1 Host: www.laoching.tistory.com -응답- HTTP/1.1 200 OK Content-Type: text/html Content-Length: 16 Delete Complete |
확장 Method
HTTP는 필요에 따라 확장해도 문제가 없도록 설계되어 있기 때문에 새로운 기능을 추가하고 사용하더라도 이미 존재하는 소프트웨어들의 오동작을 유발하지 않는다.
확장 Method는 개발자들이 구현하고자 하는 기능으로 만들어졌을 것이며 이는 HTTP/1.1 명세에 정의되지 않았을 것이다.
내가 Method를 정의하면 HTTP 애플리케이션들은 이해하지 못할 것이고, 내가 사용하고 있는 HTTP 애플리케이션들이 이해하지 못하는 확장 Method를 만날 수 있다.
이 경우를 대비해 확장 Method에 대해 관용적인 마음을 가지는게 중요하다고 한다.
HTTP 애플리케이션들은 이런 친구들을 마주쳐도 관대하게 보내준다고 한다.
* 해당 내용들은 'HTTP 완벽 가이드'에서 읽음.
'보안 > 웹' 카테고리의 다른 글
| los darknight (0) | 2022.03.24 |
|---|---|
| los golem (0) | 2022.03.24 |
| los orge (0) | 2022.03.24 |
| los orc (lord of sqlinjection 4번) (0) | 2022.03.22 |
| textarea사용하기 (0) | 2015.02.15 |
댓글