나는 GET으로 보냈는데 왜 POST로 갈까? (feat. OpenFeign 기여)

개요

최근 OpenFeign을 사용할 때 이상한 문제를 겪었다. 

@FeignClient(name = "test-client")
public interface TestClient {

    @GetMapping("/test")
    String getData(String query);
}

위와 같이 정의된 OpenFeign클라이언트를 통해 A 서버에서 B 서버의 API를 호출했는데, 405 Method Not Allowed 에러가 발생했다. 분명 B 서버에는 해당 API가 GET 메서드로 정확히 정의되어 있는데도 말이다.

@Slf4j
public class FeignLoggingInterceptorConfig {

    @Bean
    public RequestInterceptor requestLoggingInterceptor() {
        return template -> log.info("[Feign Request] method={}, url={}, query={}, body={}",
                                    template.method(), template.url(), template.queryLine(), (template.body() != null) ? new String(template.body()) : "null");
    }
}

A 서버 로그: c.k.n.i.r.FeignLoggingInterceptorConfig  : [Feign Request] method=GET, url=/test, query=, body=test

문제를 파악하기 위해 A서버에 위와 같이 로그를 남기도록 설정하고 확인했을 때도 분명 A서버에서는 GET 방식으로 요청을 보내고 있음을 확인할 수 있었다. 근데 그런데도 불구하고 B 서버에서는 다음과 같이 POST로 전달받았다는 로그가 출력됐다.

B 서버 로그: DefaultHandlerExceptionResolver : Resolved [org.springframework.web.HttpRequestMethodNotSupportedException: Request method 'POST' is not supported]

즉 A 서버에서는 GET 요청을 보냈다고 생각했지만 실제 B 서버에서는 POST 요청이 들어온 것이다. 도대체 이게 무슨 일일까?

 

 

원인

사실 눈썰미가 좋다면 A 서버의 로그를 보고 문제의 단서를 조금이나마 확인할 수 있긴 하다. 위 A 서버의 로그를 다시 보면 쿼리 파라미터(query)에 값이 포함되지 않고 HTTP body에 값이 담겨 있는 것을 확인할 수 있다.

@FeignClient(name = "test-client")
public interface TestClient {

    /**
     * @RequestParam 없음 — 문제가 발생한 코드
     */
    @GetMapping("/test")
    String getData(String query);

    /**
     * @RequestParam 있음 — 정상 동작
     */
    @GetMapping("/test")
    String getData(@RequestParam String query);
}

개발자의 의도는 GET /test?query=value처럼 쿼리 파라미터로 전송하려던 것이었지만, OpenFeign은 GET인데 '@RequestParam, @PathVariable, @SpringQueryMap.. 등'과 같은 HTTP 바인딩 어노테이션이 지정되지 않아 실제로 전송할 때 전달 값을 본문(body)으로 처리하려고 POST로 변환해 문제가 발생한 것이다.

사실 더 정확히는 Feign이 직접 HTTP 메서드를 POST로 바꾸는 것은 아니고 Feign이 내부적으로 사용하는 Java의 표준 HTTP 클라이언트(HttpURLConnection)가 바꾼 것이다.

 

 

그렇다면 HttpURLConnection은 왜 GET을 POST로 바꾸는가?

HTTP 표준(RFC 7231)에 따르면 GET 요청이 body를 가지면 일부 구현체가 동작하지 않을 수도 있다고 한다.

https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.1%5D%5B1

그렇기에 사용자가 GET을 사용하고자 하면서 '@RequestParam, @PathVariable, @SpringQueryMap.. 등' HTTP 바인딩 어노테이션을 지정해주지 않으면 HttpURLConnection은 "아, body를 쓰겠다는 거구나"라고 해석을 해버리고 RFC 7231 규칙에 따라 GET에 Body가 들어왔기 때문에 HttpURLConnection는 '호환성 유지 차원에서' 자동으로 POST로 바꾸는 우회 로직을 수행한다.

https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1326

명시적인 예외를 던지는 대신 암묵적으로 HTTP 메서드를 바꾸어 클라이언트가 계속 동작하도록 하기 위한 레거시 호환 로직인 것이다.

주석에도 쓰여있지만 'Backward compatibility(하위 호환성, 또는 하위 호환)'는 새로운 시스템이나 소프트웨어가 이전 버전에서 만들어진 프로그램이나 데이터와도 호환되는 성질을 말한다. 과거에는 많은 개발자들이 HTTP 명세를 엄격히 따르지 않았고 GET 요청에도 body를 붙이려는 시도가 있었지만 이를 허용하지 않으면 기존 코드가 깨질 수 있어서 HttpURLConnection에서는 조용히 POST로 전환하는 방식으로 '호환성 유지'를 선택한 것이다.

HttpURLConnection는 그렇다는 거고 다음과 같이 Feign이 사용하는 HTTP 클라이언트를 HttpClient대신 다른 클라이언트인 Apcache HTTP Client 5를 사용하면 Apache Client는 GET 요청에 body가 있어도 내부적으로 HTTP 메서드를 변경하지 않으므로 GET 방식으로 계속 유지할 수 있다.(OpenFeign/feign #issues/832)

<dependency>
    <groupId>io.github.openfeign</groupId>
    <artifactId>feign-hc5</artifactId>
</dependency>

다만 현업에서 HTTP Client를 바꿔 쓰는 것은 어떤 사이드이펙트가 있을지 모르기 때문에, GET을 사용할 때는 어노테이션을 잘 붙여줬는지 꼭 확인하자.

 

 

OpenFeign 오픈소스 기여

 s.n.www.protocol.http.HttpURLConnection  : sun.net.www.MessageHeader@68c984c97 pairs: {POST /test HTTP/1.1: null}{Content-Type: text/plain;charset=UTF-8}{Accept: */*}{User-Agent: Java/17.0.14}{Host: localhost:8090}{Connection: keep-alive}{Content-Length: 4}

사실 로깅 레벨을 DEBUG로 설정하면 위와 같은 A 서버에서 HttpURLConnection이 GET을 POST로 바꾸는 과정의 로그가 자동으로 출력되긴 한다. 다만.. 현실적으로 DEBUG 레벨은 너무 많은 불필요한 로그를 발생시키기 때문에 우리 팀은 일반적으로 Spring의 로깅 레벨을 INFO로 설정해 두고 사용하고 있었고, 그렇다 보니 이처럼 중요한 힌트를 담고 있는 로그가 노출되지 않았다. 그래서 저런 로그가 자동으로 출력되는지 몰라 직접 OpenFeign 전용 RequestInterceptor를 구현해 INFO 수준으로 로그를 찍었던 것이었고, Feign 레벨에서는 여전히 GET 요청으로만 출력되고 있었던 것이었다.

그나마 나는 요청을 받는 B 서버도 직접 개발하고 있었기 때문에 B서버의 로그를 비교하며 빠르게 원인을 추적할 수 있었지만 권한이 없는 외부 서버나 타사 API에 요청을 보냈던 상황이라면, 이러한 원인 모를 405 오류를 파악하는 데 훨씬 더 많은 시간을 허비했을 것이라 생각한다.

가장 중요한 건 GET 요청을 사용할 때는 반드시 HTTP 바인딩 어노테이션(@RequestParam, @PathVariable 등)을 정확히 붙여줬는지 확인하는 것이지만 개발하다보면... 옥에 티처럼 꼭 한 번씩 별거 없는 이런 것들이 안 보이는 경우가 한 번씩 있다. 그래서 애초에 "GET 요청인데 파라미터에 HTTP 바인딩 어노테이션이 없다면 경고 로그를 출력해 주면 안 될까?"라는 생각을 했고 이 생각을 바탕으로 OpenFeign/feign Issue#2872에 관련 내용을 올렸다. 그리고 직접 문제를 해결해 보기 위해 OpenFeign의 코드를 분석하다가 핵심 포인트가 SpringMvcContract.java의 parseAndValidateMetadata() 메서드라는 것을 파악하게 되었다.

이 메서드는 OpenFeign에서 사용하는 중요한 로직인데 Spring MVC의 어노테이션들(@RequestMapping, @GetMapping, @RequestParam, @PathVariable 등)을 기반으로 FeignClient 인터페이스의 메서드들을 분석하고 HTTP 요청 정보로 매핑하는 역할을 한다. 

그런데 여기서 뜻밖의 사실을 알게 되었는데 내가 수정하려고 했던 SpringMvcContract.java는 OpenFeign의 feign-core에 있는 게 아니라 spring-cloud/spring-cloud-openfeign 프로젝트에 속해 있었다. 알아보니까 둘의 차이점에 대해서는 다음과 같았다.

• OpenFeign/feign: Feign의 핵심(core) 라이브러리, 프레임워크에 독립적인 기능을 제공
• spring-cloud/spring-cloud-openfeign: Feign을 Spring 환경에 맞게 통합하기 위한 어댑터, Spring MVC 스타일의 어노테이션을 사용 가능하게 해 줌

실제로 우리 팀은 spring-cloud-openfeign을 사용하고 있었고, 주변 다른 회사의 지인들에게도 물어보니 스프링을 사용한다면 대부분 이 라이브러리를 사용 중이었다. 그래서 이슈를 OpenFeign core가 아닌 실제 적용 대상인 spring-cloud-openfeign/Issues #1191에 다시 올렸고, 최종적으로는 PR #1194를 통해 기여했다.

릴리즈가 배포된다면 이제는 GET 메서드에 HTTP 바인딩 어노테이션이 빠진 경우 다음과 같이 명확한 경고 메시지가 출력되어 개발자가 쉽게 문제를 인지할 수 있을 것이다.

[OpenFeign Warning] Feign method 'public abstract Response com.example.Client.getSomething(java.lang.String)' is declared as GET with parameters, but none of the parameters are annotated (e.g. @RequestParam, @RequestHeader, @PathVariable, etc). This may result in fallback to POST at runtime. Consider explicitly annotating parameters.

 

 

spring-cloud-openfeign은 유지보수 모드이다.

https://spring.io/blog/2022/12/16/spring-cloud-2022-0-0-codename-kilburn-has-been-released#spring-cloud-openfeign-feature-complete-announcement

그리고 또 추가로 알게 된 점이 있는데 spring-cloud-openfeign은 Spring이 자체적으로 HTTP 클라이언트 인터페이스를 제공하게 됨에 따라 2022.0.0 버전부터 유지보수 모드에 들어갔고 신규 기능 개발은 더 이상 진행되지 않는다고 한다.

그래서 현재는 크리티컬 버그 수정이나 안정성 유지 목적의 PR만 수용하고 더 이상 활발한 기능 추가나 개선은 진행되지 않는다고 하니 알아두면 좋을 것 같다.