스프링 인터셉터는 어떻게 동작하는가?

[zuminzi]

문제

스프링 DispatchServlet 이후에 호출되는 스프링 인터셉터의 흐름에 대해 학습할 수 있었다.
스프링 인터셉터가 정상적인 상황에서, 그리고 예외 상황에서 각각 흐름이 어떻게 처리되는지 정리해보자.

관련 섹션

• section 7

[zuminzi]

답변

1. 인터셉터의 기본 동작 3단계

• 스프링의 인터셉터의 동작은 크게 '컨트롤러 실행 전', '컨트롤러 실행 후, 뷰 실행 전', '뷰 실행 후' 이 세 단계로 구분된다.
• 스프링 인터셉터를 만들기 위해서는 HandlerInterceptor 인터페이스를 구현해야 한다.
• 해당 인터페이스는 preHandle(), postHandle(), afterCompletion() 이라는 세 메소드를 제공한다.

  1. preHandle():

     

     • 실행시점:
       • 컨트롤러 호출 전
     • 용도:
       • 컨트롤러 이전에 처리해야 하는 전처리 작업이나 요청 정보를 가공하거나 추가할 때 유용하다.
     • 특징:
       • 세 번째 파라미터인 handler 객체 타입은 어떤 핸들러 매핑을 사용하는가에 따라 달라진다.
         • HandlerInterceptor 인터페이스에서는 Object 형태로 업 캐스팅해서 매개변수로 넘겨주는 것이고, 실제 사용할 때는 instanceof 연산자로 객체의 타입을 확인해서 다운 캐스팅 한 뒤 객체에 접근하면 된다.
         • @Controller ,@RequestMapping을 활용한 핸들러 매핑을 사용하는 경우, HandlerMethod 타입의 객체가, 정적 리소스가 호출 되는 경우, ResourceHttpRequestHandler 타입의 객체가 핸들러 객체로 넘어온다.
       • 반환 타입은 boolean인데 반환값이 true면 다음 단계로 진행이 되지만, false라면 작업을 중단하여 이후의 작업(다음 인터셉터 또는 컨트롤러)은 진행되지 않는다.
       • 따라서, JwtInterceptor 를 구현해서 인가/인증하는 경우,false를 반환하여 해당 Handler로 접근을 제한할 수 있다.

  2. postHandle() :

     

     • 실행시점:
       • 컨트롤러 호출 후
     • 용도:
       • 컨트롤러의 비즈니스 로직이 성공적으로 처리된 이후에 필요한 후처리 작업이 있을 때 유용하다.
     • 특징:
       • 컨트롤러가 반환하는 데이터 정보와 뷰 정보를 가지고 있는 modelAndView 파라미터는 REST API에서는 사용되지 않는다.
       • 전통적인 웹 애플리케이션에서는 ModelAndView를 사용하여 서버 측 뷰 렌더링을 위한 정보를 다루지만, REST API에서는 JSON 형식으로 데이터를 직접 반환하기 때문이다.

  3. afterCompletion() :

     

     • 실행시점:
       • 뷰 렌더링 작업을 포함하여 모든 작업이 완료된 후에 실행된다.
     • 용도:
       • 요청 처리 중에 사용한 리소스(파일, 데이터베이스 연결 등)를 해제하거나 로깅 등에 사용하기에 적합하다.

2. 핸들러 예외 발생 시 인터셉터의 흐름

• 컨트롤러 단에서 예외가 발생했을 때 각 메서드들의 동작은 다음과 같다.

  1. preHandle():

     • 컨트롤러 호출 전에 사용되기 때문에 영향을 받지 않는다.

  2. postHandle() :

     • 호출 되지 않는다.
     • WAS로 예외가 전달되어, /error로 재요청하며, 500 페이지를 제공한다.
       • Controller나 그 뒤 계층에서 throw된 Exception은 DispatcherServlet이 일단 전달 받은 뒤, 다시 Servlet 밖의 Servlet Container가 처리하게 된다.
       • 따라서, Controller의 작업 중 발생한 Exception을 처리하는 결정 전략 객체인 HandlerExcetpionResolver가 등록되어 있지 않다면, 'HTTP Status 500 내부 서버 오류'와 같은 메시지가 브라우저 단에 노출된다.

  3. afterCompletion() :

     • HandlerExcetpionResolver 을 함께 사용하는 경우와 그렇지 않은 경우에 따라 호출 여부가 결정된다.
       • 함께 사용하는 경우:
         • ExceptionResolver가 컨트롤러 단 예외 처리를 우선적으로 담당하기 때문에, 해당 예외 처리에 성공하면 afterCompletion 메서드가 호출되고, 예외 처리에 실패하면 afterCompletion 메서드는 호출되지 않는다.
       • 함께 사용하지 않는 경우:
         • 컨트롤러단 예외 발생 여부와 관계 없이 항상 호출된다.
         • 예외가 발생하면, 예외 정보(ex 파라미터)를 포함해서 호출하기 때문에 예외를 파라미터로 받아서 로그로 출력하거나, 예외와 무관하게 후처리해야 하는 공통 작업을 처리할 수 있다.

💡 스프링 MVC 인터셉터와 ExceptionResolver 함께 사용 시 예외 처리 비교

1. PageNotFound(404): 컨트롤러에서
   • Interceptor: 미작동
     • 404는 클라이언트의 요청 URL이 서버에서 찾을 수 없을 때 발생하는 HTTP 상태코드이기 때문에, 인터셉터 실행 전에 실행이 종료된다.
   • ExceptionResolver: 미작동
     • 인터셉터와 마찬가지로, 컨트롤러 처리하는 단까지 오기 전에 실행이 종료된다.
2. PageFound, Not Allowed (405 등)
   • Interceptor: 미작동
   • ExceptionResolver: 작동
     • 405는 이미 컨트롤러나 핸들러가 요청을 받아들이고 있으나, 해당 요청 메소드를 처리할 수 없는 상황이기 때문에 컨트롤러 단에서 발생하는 예외로 간주되기 때문이다.
3. Controller Exception(500):
   • Interceptor.afterCompletion: 미작동
   • ExceptionResolver: 작동
     • 컨트롤러에서 발생한 예외는 ExceptionResolver에서 우선적으로 처리하기 때문이다.
4. View Exception(500):
   • Interceptor.afterCompletion(ex): 작동
     • View 렌더링 중 예외가 발생하면 예외 객체가 afterCompletion으로 전달된다. 따라서, View 렌더링에 대한 예외 처리 등의 후속 작업을 수행할 수 있다.
   • ExceptionResolver: 미작동.
     • View 렌더링 과정에서 발생한 예외는 ExceptionResolver가 처리하지 않는다.

References

• [Spring Web] Filter & Interceptor
• [Spring] DispatcherServlet의 예외처리 전략
• Spring HandlerInterceptor를 활용하여 컨트롤러 중복 코드 제거하기
• [Spring Web] Filter & Interceptor
• 스프링 인터셉터
• 스프링 MVC 2 - HandlerExceptionResolver 시작
• handler 메소드에서 발생하는 예외를 인터셉터에서 처리할 수 있는 방법 문의