HttpServletResponse

HttpServletResponse 역할

HTTP 응답 메시지 생성

• HTTP 응답코드 지정
• 헤더 생성
• 바디 생성

편의 기능 제공

• Content-Type, 쿠키, Redirect

 

---

HTTP 응답코드

• 해당 인터페이스로 들어가보면 응답코드들이 이미 만들어져있으므로 이것을 가져다 사용하기만 하면된다.

 

response-header

• setHeader를 통해 헤더를 생성할 수 있다.

먼저 아무것도 캐싱하지 않으려면

Cache-Control: no-store

를 하면됩니다. 또는 no-cache, no-store, must-revalidate로 no 시리즈를 다 붙여줍니다.

Cache-Control: no-cache

는 가장 많이 헷갈려하는 헤더 설정인데요. no-cache이지만 cache하지 말라는 뜻이 아닙니다!!! 모든 캐시를 쓰기 전에 서버에 이 캐시 진짜 써도 되냐고 물어보라는 뜻입니다.

Cache-Control: must-revalidate

must-revalidate는 만료된 캐시만 서버에 확인을 받도록 하는 겁니다. no-cache랑 must-revalidate는 이름이 잘못 지어진 감이 있습니다.

Cache-Control: public 또는 private

public이면 공유 캐시(또는 중개 서버)에 저장해도 된다는 뜻이고 private이면 브라우저같은 특정 사용자 환경에만 저장하라는 뜻입니다.

Cache-Control: public, max-age=3600

max-age로 캐시 유효시간을 줄 수 있습니다. 초 단위이므로 위 예제에서는 1시간입니다. 1시간이 지나면 이 응답 캐시는 만료된 것으로 여겨집니다.

참고로 위의 옵션들은 혼합해서 써도 됩니다. no-store, no-cache, must-revalidate처럼 콤마로만 구분하면 되고요. 

Cache-Control을 응답 헤더라고 생각하실 수도 있는데, 요청 헤더로도 사용할 수 있습니다. 프론트 - 중개 서버 - 진짜 서버와 같은 구조인 경우에 중개 서버에 있는 캐시를 가져오지 않도록 하려면 요청 시부터 Cache-Control을 헤더로 넣어주곤 합니다.

 

Pragma no-cache

 Cache-Control: no-cache 와 같다. 캐시가 캐시 복사본을 릴리즈 하기전에 원격 서버로 요청을 날려 유효성 검사를 강제하도록 한다.

서버에 접속한 후에 헤더를 살펴보자.

• 내가 설정한 헤더들이 다 들어가있다.
  • Cache-Control, Content-Type, my-header, Pragma

 

Header 편의 메서드

 

• Content-Type을 직접 지정해줬던 부분을 주석처리하고 편의 메서드를 사용하여 헤더를 생성해보자.

• 편의 메서드를 사용하여 헤더를 설정할 수 있음

 

• 파란색 밑줄처럼 setHeader를 통해 쿠키를 설정해 줄 수있지만 편의기능 메서드를 서블릿이 제공한다.

• 쿠키가 헤더에 추가된 것을 확인할 수 있다. 이제 refresh했을 때 쿠기가 Request Headers에 나타나는지를 확인해보자.

 

Redirect 편의 메서드

• setHeader를 사용하지않고 편의메서드를 사용하여 Redirect를 해보자.

• 지정한 페이지로 리다이렉션 되었고, response-header로 접속했을 때 302 status-code를 가지고 redirect되어 hello-form.html로 이동하여 200을 띄웠다.