[Trouble Shooting] HTTP 리다이렉션 시 POST, PUT, DELETE (CUD)가 GET으로 바뀌는 문제점

HTTP의 POST, PUT, DELETE의 경우 HTTPS로 리다이렉션 시 GET으로 바뀐다.

이는 HTTP의 특성인데, 이를 알게된 계기와 해결 방법을 아래에 기술한다.

 

1. 문제 발생 🤬

쿠버네티스 각 Pod의 서비스 간 API 통신을 테스트 하기 위해 Postman으로 CRUD API 테스트를 진행했다.

(Local에 WAS를 띄우고 Pod에 배포된 다른 서비스를 Postman으로 콜하는 방식 )

그러나 Postman에서 HTTP로 POST, PUT, DELETE 요청할 경우 405로 Response 받고, GET의 경우 정상적(200)으로 Response를 받았다.

Ingress Controller의 로그를 확인하니 HTTP의 POST, PUT, DELETE의 요청들이 HTTPS의 GET로 변경되어 있었다.

 

2. 원인 파악 😵

원인을 파악해보니 ALB에서 HTTP로 POST, PUT, DELETE으로 요청 받을 경우 301 status code의 HTTPS의 GET으로 Ingress Controller로 리다이렉션하고 있었다. (HTTPS로 요청할 경우 이상 없음)

그 이유는 HTTP 프로토콜 특성 때문인데, 이는 클라이언트와 서버 간의 데이터 무결성을 보장하기 위함이다.

좀 더 자세히 말하자면..

ALB에서는 일반적으로 HTTP 요청의 경우 HTTPS로 리다이렉션을 지원하며, 이는 보안을 강화하기 위한 설정이다.

따라서 ALB에서 HTTP를 HTTPS로 리다이렉션하는 규칙이 설정되어 있을 때, HTTP의  POST, PUT, DELETE 요청을 받으면 301 status code의 HTTPS의 GET으로 리다이렉션한다. 이는 HTTP 프로토콜의 표준 동작으로 HTTP 프로토콜의 특성이다.

이 동작은 HTTP 클라이언트가 POST, PUT, DELETE 요청을 보낼 때, 리다이렉션 응답을 받으면 자동으로 GET 요청을 보내도록 설계되어 있기 때문이다. 이렇게 GET 요청으로 변경되는 이유는, 리다이렉션 응답을 받은 클라이언트가 POST 요청을 다시 보내면 중복된 데이터를 서버에 전송할 수 있기 때문이다. 따라서, 클라이언트는 리다이렉션 응답을 받으면 GET 요청을 보내도록 되어 있다.

이러한 동작은 HTTP 프로토콜의 표준이며, ALB는 이를 준수하여 동작한다.

따라서, HTTP POST, PUT, DELETE 요청을 받으면 ALB는 301 status code 의 HTTPS GET으로 리다이렉션하게 된다.

이는 궁극적으로 클라이언트와 서버 간의 데이터 무결성을 보장하기 위한 것이다.

 

3. 해결 방법 😄

1) HTTPS로 요청한다.

2) HTTP 요청을 받을 경우 리다이렉션을 301이 아닌 308로 변경한다.

301 Moved Permanetly는 리다이렉트시 요청 HTTP Method를 GET으로 바꾸어서 전송한다.
308 Permanent Redirect는 전송 받은 HTTP Method를 유지한다.

k8s의 Pod 간 통신을 외부로 나가 다시 들어와 통신하는 경우는 301 → 308로 변경하고(ALB를 타기 때문), Pod 간 통신을 내부에서 할 경우 ALB를 타지 않기 때문에 변경이 필요 없다. (Pod 간 통신은 HTTP)

 

4. 결론 🚀

ALB에서 HTTP를 HTTPS로 리다이렉션하는 규칙이 설정되어 있을 때, POST, PUT, DELETE 요청을 받으면 301 status code로 리다이렉션하여 GET 요청으로 변경한다.

이는 HTTP 프로토콜의 특성과 관련 있는데 궁극적으로 클라이언트와 서버 간의 데이터 무결성을 보장하기 위함이다.

 

 

참고.

301, 308 Status Code

[NginX] 리다이렉션 시 POST가 GET으로 바뀌는 문제점 (velog.io)