[Spring] RequestBody 여러 번 읽기

지난 프로젝트에서 서버 운영 중 생각보다 많은 부분에서 예외가 발생했다. 예외가 발생했음에도 이 사실을 모른채 방치하게 되는 일이 생기기 시작했고, 예외가 발생할 때마다 EC2 인스턴스에 접근해 직접 로그를 확인해야한다는 번거러움이 있었다. 이번 프로젝트에서 이를 개선하기 위해 서버에 슬랙을 연동했고 AOP에서 RequestBody의 데이터를 읽어 에러 내용을 파싱한 후 슬랙으로 전송하는 방법을 사용했다. 이 과정에서 RequestBody를 여러 번 읽어야만 했고 그 방법을 이 글에 써보고자 한다. 

 

 

---

 

☑️  HttpServletRequest Body

 

HttpServletRequest의 Body 데이터는 getInputStream() 또는 getReader()를 통해 접근할 수 있다. 하지만 이는 스트림 형태로 저장되어 있기 때문에 일회성 소모 데이터이다. 만약 인터셉터나 필터에서 추가 작업을 위해 데이터를 먼저 읽는다면, RequestBody를 처리하는 컨버터인 Jackson2HttpMessageConverter를 통해 Json 데이터를 바인딩할 때 아래와 같은 에러가 발생할 것이다. 먼저 바인딩을 한 후 추가 작업을 진행하는 경우에도 마찬가지이다. 

java.lang.IllegalStateException: getReader() has already been called for this request
org.springframework.http.converter.HttpMessageNotReadableException: Could not read JSON: Stream closed; nested exception is java.io.IOException: Stream closed

 

 

 

☑️ 해결방법

 

이를 해결하기 위해 ContentCachingRequestWrapper를 사용할 수 있다.

Spring에서 제공하는 ContentCachingRequestWrapper는 Java Servlet API의 HttpServletRequestWrapper를 상속받아 구현되어있다. 이는 한 번만 읽을 수 있는 Stream 데이터인 RequestBody의 데이터를 캐싱하여 여러 번 읽을 수 있도록 하기 위해 만들어진 클래스이다.

 

이를 사용하여 필터에서 래핑 후 바로 로깅 작업을 하고자 한다면 ContentCachingRequestWrapper 클래스를 직접 사용하여 getContentAsByteArray를 통해 즉시 읽을 수 있다. 하지만 나의 경우, 바인딩 작업을 거친 후 실행되는 ExceptionHandler를 타겟으로 하는 AOP에서 Body 데이터를 읽어야 했다. 타겟 메서드에서 HttpServletRequest를 인자로 받는 경우를 제외하면 AOP에서 Request를 직접적으로 받을 수 있는 방법이 없기에 간접적인 접근이 필요했다.

크게 두가지 방법이 있고 나는 그 중 첫 번째 방법을 사용했다.

 

1️⃣ 별도의 클래스 - Request Scope 빈

요청이 들어오고 나가기 전까지 래퍼 Request 객체를 저장하고 있을 별도의 클래스 이용하는 방법이다.

먼저 RequestStorage라는 클래스를 선언해준다. 이후 빈으로 등록하는데 이 때 각 요청과 생명주기를 같이 하기 위한 Request Scope와 ProxyMode를 적용한다. 여기서 Proxy mode를 사용하는 이유는 Request Scope는 Request가 들어올 때 주입이 이루어지기 때문에 프록시 모드를 설정해주지 않으면 Application Context를 로딩하는 시점에 에러가 발생하기 때문이다. 

 

아래의 사용 코드와 같이 필터에서 RequestStorage에 저장하면 요청이 처리되는 동안 모든 곳에서 get 메서드를 통해 Request 객체를 편하게 사용할 수 있다.

 

 

💠 설정 코드

public class RequestStorage {
    private ContentCachingRequestWrapper request;

    public void set(ContentCachingRequestWrapper request) {
        this.request = request;
    }

    public ContentCachingRequestWrapper get() {
        return request;
    }
}

@Configuration
public class WebConfig{
    @Bean
    @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
    public RequestStorage requestStorage() {
        return new RequestStorage();
    }
}

 

💠 사용 코드

@Component
public class ServletWrappingFilter extends OncePerRequestFilter {

    private final RequestStorage requestStorage;

    public ServletWrappingFilter(RequestStorage requestStorage) {
        this.requestStorage = requestStorage;
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
            FilterChain filterChain) throws ServletException, IOException {

        ContentCachingRequestWrapper wrappedRequest = new ContentCachingRequestWrapper(request);
        requestStorage.set(wrappedRequest);

        filterChain.doFilter(wrappedRequest, response);
    }
}

@Aspect
@Component
@RequiredArgsConstructor
public class SlackMessageAop {
    private final RequestStorage requestStorage;
    
    @Before("@annotation(###.SlackAlarm)")
    public void slackAlarmAspect(JoinPoint joinPoint) {
		ContentCachingRequestWrapper request = requestStorage.get();
    }
}

 

 

 

2️⃣ RequestContextHolder

스프링이 제공하는 RequestContextHolder를 통해 현재 스레드에 바인딩된 HttpServletRequest를 얻을 수 있다.

이 방법을 사용한다면 필터에서는 ContentCachedRequestWrapper 클래스를 통해 기존 request를 래핑하는 과정만 추가하면 되고 아래 코드와 같이 사용할 수 있다.

 

💠 사용 코드

@Aspect
@Component
public class SlackMessageAspect {

    @Before("@annotation(###.SlackAlarm)")
    public void slackAlarmAspect(JoinPoint joinPoint) {
		HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder
       			.currentRequestAttributes()).getRequest();
    }
}

 

 

---

 

☑️ 결론

 

RequestContextHolder를 사용한다면 구현이 단순하고 직관적이다. 하지만 RequestStorage를 사용하면 요청과 관련된 다양한 정보를 유연하게 저장하고 관리할 수 있다. 예를 들어, 특정 요청에서만 필요한 정보를 저장하거나, 요청 처리 과정에서 동적으로 정보를 추가하거나 변경하는 것이 가능해진다. 이러한 점들을 고려한다면 애플리케이션 상황에 맞게 적절히 사용할 수 있을 것이다.