[CS Web] HTTP Request Method

HTTP 요청 방법

1. GET
2. PUT
3. POST
4. DELETE
5. PATCH
6. HEAD
7. OPTIONS
8. TRACE
9. CONNECT

 

DELETE

• 지정된 리소스 삭제
• 비안정성을 가지므로, DELETE 요청 시 클라이언트를 인증/인가에 필요한 정보들을 함께 보내야함

URL query string parameter

• 인증에 필요한 username, id, password 등 민감 정보가 그대로 노출될 수 있으므로 보안상 좋진 않다.
  • server log에 password가 평문 그대로 저장될 수 있다.
  • 브라우저 히스토리에 url이 저장될 수 있다.
  • Google Analytics 같은 애플리케이션에 Referer 헤더들로 URL이 전달되며, 민감정보가 그대로 드러날 수 있다.

Request Body parameter

• 민감 정보가 URL에 직접 노출되지 않는다는 점에서 URL query vstring parameter 보다는 보안이 좋다.
• 하지만 DELETE 요청 메세지에 body가 포함되어 있으면 요청을 거절해버리는 서버가 있어서 좋은 방식은 아니다.
• DELETE 메서드 자체를 허용하지 않는 서버, 방화벽도 있어서 꼭 DELETE 메서드를 써야하는 상황이 아니라면,
  Requesgt body에 필요한 정보를 담고, POST 메서드 요청 메시지를 보내는 방법도 있다.
• TOSS 결제 시스템의 경우, PG 연동 개발자들의 편의를 위해 POST 메서드로 DELETE 요청에 해당하는 API를 디자인한 사례가 있다. (여기 클릭)

Request Header parameter

• 일반적인 방법
• Authorization header에 Bearer 타입을 명시하고, 인증 정보가 담긴 JWT를 넣어서 보낸다.

 

PATCH

• 리소스에 부분 수정하는 데 사용
• PUT은 해당 자원 전체를 수정하는 반면 PATCH는 해당 자원을 부분 수정한다.

{
    "id" : 1,
    "user_name" : "홍길동",
    "age" : 10
}

{
    "id" : 1,
    "age" : 20
}

 

ORM을 쓰거나 요청 mapping에서 DTO 객체를 받게 되면, user_name에 해당하는 field가 null로 적용이 된다.

(kotilin, java 등 여러 언어에서 parsing 할 때 나오는 현상)

이를 다시 db에 적용하기 위해 entity로 변환하는 과정에서 userName이라는 변수가

class User {
    id = 1
    age = 20
    userName = null
}

 

age는 20으로 변경이 되지만, userName이 null로 변환되는 크리티컬 이슈가 발생할 수 있다.

어떤 field의 수정이 일어났는지 굳이 서버에서 관리하지 않을 수 있음 + 코드의 유연함 => PATCH 보다 PUT을 사용한다.

 

HEAD

• GET 요청 시 응답으로 오는 헤더부분만 요청하는 메소드
• GET과 거의 동일하지만 Response Body가 없다.
• GET /users가 사용자 목록을 반환하는 경우, HEAD /users는 동일한 요청을 수행하지만 사용자 목록을 반환하진 않는다.
• HEAD 요청은 실제로 파일을 다운로드하지 않고 Content-Length 헤더를 읽어 파일 크기를 확인할 수 있다.
• HEAD 요청은 실제로 GET 요청을 하기 전에 GET 요청이 무엇을 반환할지 확인하는 데 유용하다.

 

그냥 GET 쓰면 안 되나ㅇㅅㅇ ??

 

-> GET과 다르게 Response Body 없이 상태 값과 HEAD 값만 넘어가기 때문에

(Response Body가 있어도 무시해야 된다고 함)

데이터의 양이 줄어들어 서버의 상태를 빠르게 조회할 수 있는 장점이 있다.

 

예를 들어, caching을 사용하는 클라이언트가 최근 접속 이후 document가 바뀌었는지 봐야하거나

요청에 쓰인 hypertext links의 validity(타당성), accessibility(접근성), recent modification(최근 수정사항)을 테스트해야 하는 경우

GET 요청을 통해 body 를 포함한 큰 응답 데이터를 받는 것보다 header 부분만 가진 응답이 더 효율적인 것이다.

 

OPTIONS

• 대상 리소스에 대한 통신 옵션을 확인하기 위해 사용한다.
• 서버가 어떤 method, header, content type을 지원하는지 알 수 있다.
• 통신 타입이 XMLHttpReqeust (XHR)이 아닌 preflight 이다.

curl -X OPTIONS https://API서버 -i

HTTP/1.1 204 No Content
...
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
...

 

CORS 동작에서도 Options 요청이 사용된다. (Options 요청을 보낸 뒤 응답 정보를 사용 가능한지 파악)

서버의 허가가 떨어지면 실제 요청을 보내도록 요구하고,

서버는 클라이언트에게 요청에 인증정보(쿠키나 HTTP 인증)를 보내라고 알려주거나 405 발생시키거나 한다.

 

CORS의 동작원리

1. 단순 요청 (Simple Request)
2. 예비 요청을 보내서 확인 (Preflight)

3. 인증된 요청을 사용하는 방식 (Credential Request)

 

Preflight Request

서버로 바로 요청을 보내는 Simple Request와는 다르게 지금 보내는 요청이 유효한지 확인하기 위해 Options 메서드로 예비 요청을 보낸다.

Simple Request

Preflight Request

 

만약 크기가 10,000인 Array를 body에 담아서 보내는 요청이 있는데, 이 요청이 CORS 정책을 위반한다면?

이런거 판단 안 하고 보내버렸는데, 알고보니 유효하지 않은 요청이라면 불필요하게 리소스를 낭비한 꼴이 되고, 서버에도 부하가 크다.

이를 방지하기 위해 특정 조건인 경우 예비요청을 먼저 날려, 이게 유효한 요청인지 확인하는 것이다.

 

preflight는 보안을 위한 절차이지만, 응답속도가 중요한 경우라면

 

1. CORS 상황이 되지 않도록 웹서버와 동일한 오리진을 사용한다.

• 보통 API 서버와 프론트엔드가 분리돼 있는 경우가 많은데, 브라우저에서 보내는 요청을 웹서버와 동일한 서버에서 받아주는 중간 서버를 두어서 실제 API 서버로 전달하면 된다.

2. preflight 발생조건을 없앤다.

 

발생 조건

1. GET, HEAD, POST 요청이 아닌 경우

2. Custom HTTP Header가 존재하는 경우

• Connection, User-Agent (en-US), Fetch 명세에서 "forbidden header name"으로 정의한 헤더) 외에
  수동으로 설정할 수 있는 헤더는 오직 Fetch 명세에서 "CORS-safelisted request-header"로 정의한 헤더뿐이다.
  (Accept, Accept-Language, Content-Language, Content-Type)

3. Content-Type이 application/x-www-form-urlencoded, multipart/form-data, text/plain이 아닌 경우

 

TRACE

• 대상 리소스의 경로를 테스트하는 메시지 루프백 테스트를 수행하는 데 사용 -> 디버깅 목적으로 유용
• 루프백(Loopback) 테스트 : PC에서 별도의 장치와 연결 없이 통신하는 테스트

 

CONNECT

• 요청된 자원과의 양방향 통신(터널)을 시작할 때 사용한다.

 

Proxy를 통해 Client와 Server가 SSL 통신을 하려고 할 때, 생성된 key는 보안을 위해 Proxy가 모르도록 해야 한다.
이 때 Connect method는 Client와 Server가 SSL handshake를 맺도록 하기 위해

Client가 Proxy에게 Server와 TCP Connection을 맺으라고 지시할 때 쓰인다.

Client와 Server의 handshake가 끝나고 대칭키가 설정된 이후, 양자간의 모든 통신은 키를 이용해 암호화되고 Proxy에게 보내진다.

이때 Proxy는 data relay에 역할만 수행하고, key를 모르기 때문에 데이터를 검사할 수 없으며, end-to-end 보안이 보장된다.

 

WebClient 프록시(CONNECT HTTP Method)

진식아 도와줘

 

#

REFERENCE

HTTP request methods explained

 

W3Schools.com

[API 설계] DELETE request 요청/처리/응답에 관한 소소한 고민

HTTP Method 설명에서요~ PATCH 메서드는 왜 없을까요? - 인프런

[SW 정글 55일차] HEAD 메소드는 왜 쓸까?

[HTTP] Options 요청은 뭘까?

 

CORS의 기본 개념과 동작 방식(부제: Preflight 요청이란?)

HTTP Trace Method 와 취약점(XST)

HTTP CONNECT method