💥 아! Get 요청시에는 Message body를 사용하면 안되는구나!!

이 글은 Velog에서 이전한 글입니다. Velog 원문 보기

현재 진행중인 2개의 프로젝트 중 Sucat 프로젝트에서 문제가 발생했다.

문제는 '닉네임 중복 검사' API 요청에서 발생했는데 기존 요구사항을 살펴보자

닉네임 중복 검사 요구사항

• Get 요청
• body에 json 형식으로 'nickname' 속성에 중복 검사할 닉네임을 담아서 전송
• 성공시 200 코드 반환

기존의 요구사항은 위와 같았다. 백엔드 측에서 Postman으로 테스트할 때는 문제 없이 API 요청이 가능했기에 문제가 생길거라고 생각하지 못했다.

---

그러나 AWS로 서버를 배포하고 프론트 쪽에서 API 테스트를 하던 중 문제가 발생했다. '닉네임 중복 검사' API에서 요구 사항을 모두 충족했음에도 에러가 발생했다.

문제의 해답은 아주 가까이 있었다.

HTTP 지식과 프론트 협업 경험의 부족에서 나온 실수였는데, 바로 Get 요청 시에는 body를 사용하면 안된다는 것이다.

지금 생각하면 너무 부끄럽다..

MDN에 작성된 HTTP GET 요청에 대한 표준

GET 요청에 본문이나 페이로드가 담겨있으면 명세에는 금지되어있지 않지만, 의미가 정의되지 않아 기존에 존재하는 구현체에게 요청을 거부당할수 있습니다. 이러한 이유로 GET 요청에는 본문이나 페이로드를 담지 않는 것이 바람직합니다.

---

다시 공부하는 마음으로 Get Method의 특징을 알아보고자 한다.

web3 school - HTTP Request Methods

Get Method 특징

1. Get 요청을 캐시할 수 있다.
2. Get 요청은 브라우저 기록에 남아 있다.
3. Get 요청을 북마크할 수 있다.
4. Get 요청은 민감한 데이터를 처리할 때 사용해서는 안된다.
5. Get 요청에는 길이 제한이 있다.
6. Get 요청은 데이터를 요청하는 데만 사용된다.

HTTP 명세서에서 Get 요청에서 Message Body를 사용하지 않도록 권장하는 이유

• 캐시 가능성: HTTP GET 요청은 종종 웹 브라우저에 의해 캐시된다. GET 요청을 간단하고 예측 가능하게 유지함으로써, 이러한 시스템이 캐시를 보다 쉽게 관리하고 검색할 수 있다.
• 안전성: GET 요청은 안전(safe) 및 멱등(idempotent)이어야 한다. 이것은 서버에서 어떠한 데이터도 수정하지 않고, 부작용이 없어야 함을 의미한다. GET 요청에서 Message Body를 허용하지 않음으로써, GET 요청이 안전하고 멱등하게 유지되도록 보장한다.
• 보안성: GET 요청은 종종 서버 로그, 브라우저 히스토리 및 다른 시스템에서 기록된다. 데이터를 URL에 유지함으로써, 이를 쉽게 볼 수 있으며, 제 3자가 잠재적으로 가로챌 수 있다. 반면, Message Body에 데이터를 포함하는 POST 요청은 덜 가시적이며, 추가적인 보안 계층을 제공할 수 있다.

요약
HTTP 명세서에서 GET 요청에서 Message Body를 사용하지 않는 것은 캐시 및 보안 문제를 일으킬 수 있기 때문이다.
권장하지 않을 뿐이지 body를 사용 가능한 경우가 존재한다.

실제로 2014년부터는 Get 요청이 Message Body를 사용 가능하도록 변경되었다. 하지만 특정 클라이언트는 이를 허용하지 않는데, 우리 프로젝트에서 사용하는 클라이언트가 이에 해당하는 클라이언트인 것 같다.

---

출처
https://www.w3schools.com/tags/ref_httpmethods.asp
https://velog.io/@sejin3319/HTTP-HTTP-Method
https://www.baeldung.com/cs/http-get-with-body
https://lazyfriend.hashnode.dev/get-request-body