리소스 핸들러

리소스 핸들러는 이미지, JS, CSS, HTML 등의 정적인 리소스를 처리하는 핸들러이다.

 

이 핸들러는 서블릿 컨테이너 ( 톰캣 , 제티 등 )가 기본으로 제공하는 Default 서블릿

 

이며 이미 등록이 되어있다.

 

 

스프링은 이렇게 등록돼있는 디폴트 서블릿에 이 요청을 위임해서 정적인 리소스를 처리한다.

 

그런데 정적인 리소스 핸들러가 요청을 먼저 다 가로챈다면 우리가 만든 핸들러들은 무시될 것이다.

 

즉 우리가 만든 핸들러들이 우선순위가 더 높아야 하기 때문에 기본적으로 리소스 핸들러의 우선순위는 낮다.

 

 

스프링 부트를 쓰고 있다면 아무런 설정 없이도 기본 정적 리소스 핸들러와 캐싱 기능을 제공한다.

 

그 디렉터리 중 하나가 static 디렉터리이다. 

 

static 디렉터리 안에 index html 파일을 만들어 보자.

 

 

 

 

그 후에 다음과 같은 Test로 실제 정적인 요청이 잘 처리되는 것을 알 수 있다.

 

---

 

이렇게 스프링 부트가 제공하는 리소스 말고 직접 리소스 핸들러를 만들고 싶다면 다음과 같이 가능하다.

 

addResourceHandler에 어떠한 패턴의 요청을 처리할지

Locations을 주어서 resource를 어디서 찾아야 하는지 위치를 적어주면 된다.

 

resources ( classpath: / ) mobile 파일 이하의 모든 요청이 들어오면 해당 페이지를 보여준다.

 

setCacheControl은 Return 되는 리소스들은 캐시와 관련된 헤더가 응답 헤더에 추가가 되고 이 응답은 리소스가 변경돼

 

지 않았다면 10분 동안 캐싱하게 된다.

 

mobile/index.html

 

스프링 부트가 제공하는 리소스 핸들러도 역시 캐싱 기능이 동작하고 있고 application.properties를 통해

 

수정 가능하다.

 

 

이제 크롬 탭을 통해 확인을 해보면 로컬에서 정적 리소스들이 변경되지 않았기 때문에 

 

Last-Modified값이 변경되지 않았을 거고 304 응답이 나오게 된다.

 

Last-Moeidifed가 바뀌거나 if-Modified-Since 이후로 변경이 됐다면 서버가 요청을 받게 된다.

 

이렇게 하면 실제 레소스 전체를 응답으로 다시 내보내지 않기 때문에 빠르고 트래픽도 조금 쓰게 된다.

 

 

즉 우리는 스프링 MVC를 쓸 때 static resource를 사용할 수 있는 특별한 요청의 패턴과

 

요청 패턴에 해당하는 위치를 프로젝트 안에 들어있는 classpath 기준으로 줌으로써 

 

( war인 경우에는 web-app  디렉터리 및 ) 리소스 핸들러를 사용해 보았다.