[HTTP] 쿠키와 쿠키를 삭제하는 응답 메시지 보내기

쿠키

쿠키를 사용하는 이유

HTTP는 무상태를 기반으로 하는 프로토콜이다. 따라서 우리가 구현해야 하는 로그인을 구현해 사용자가 로그인을 하더라도, 이후 요청에서 마이페이지를 조회하는 요청이 오더라도 로그인 정보를 기록해두지 않아 누구의 마이페이지 인지 알 수 없다. 즉, 클라이언트가 다시 요청을 하면 서버는 이전 요청을 기억하지 못한다. → 클라이언트와 유저는 상태를 유지하지 않는다.

동작 과정

1. 홍길동이라는 클라이언트가 서버에게 로그인을 요청한다.
2. 로그인을 완료시킨 서버는 Set-Cookie 헤더를 통해 쿠키를 유저에게 전달한다.
3. 클라이언트의 웹 브라우저는 쿠키 저장소에 전달 받은 쿠키를 저장한다.
4. 로그인 이후에 웹 브라우저는 어떠한 요청을 수행하더라도 저장된 쿠키를 Cookie 헤더에 담아 전달한다.
5. 서버는 Cookie 헤더를 읽어 어떤 유저인지 알 수 있게 된다.

쿠키의 사용처

• 사용자의 세션을 관리할 때 사용된다.
  • 여기서 사용되는 것이 세션 ID이다.
  • 세션 ID는 클라이언트의 로그인 요청 시 서버에서 만들어서 미리 저장한 뒤 이를 클라이언트에게 전달하고, 클라이언트는 이 세션 ID를 활용해 접속을 유지한다.
• 광고 정보를 트래킹 할 때 사용한다.
• 쇼핑의 경우 장바구니와 같은 기능을 사용할 때 사용된다.
• 사용자의 선호도와 설정을 기억해 개인화된 정보로 웹사이트를 제공한다.
  • 사용자의 언어, 지역, 테마와 같은 정보를 쿠키에 담아 저장한 뒤 다음 방문에도 이를 적용하여 요청을 응답해 준다.

쿠키의 단점

서버 측면에서의 단점

• 쿠키의 정보는 매번 요청 시마다 담겨 서버에 요청한다.
  • 이는 서버에 트래픽을 추가로 유발하게 된다. 따라서 최소한의 정보만을 사용하도록 하는 것이 좋다. (세션 Id, 인증 토큰 관련된 로그인값 정도만 사용하는 것이 좋다.)
  • 로그인 정보 외에 필요한 정보에만 쿠키에 담아 요청해야 하는 정보는 웹 스토리지를 통해 전달하고, 필요에 따라 가져와서 사용하도록 구현하면 된다.
• 쿠키는 저장해두어야 하는 정보이다.
  • 쿠키를 사용하기 위해서는 서버에서 쿠키 데이터를 저장한 뒤 사용해야 한다. 이는 서버의 저장 공간에 부담이 갈 수 있다.
  • 유효 기간이 지난 쿠키를 클라이언트에서 자동으로 삭제되지 않는다. 이 쿠키를 삭제하기 위한 로직도 추가적으로 만들어 주어야 한다.
• 쿠키는 클라이언트에서 조작할 수 있다.
  • 처음 쿠키를 만들어 전송하는 것은 서버이지만, 저장되는 곳은 사용자의 브라우저이기 때문에 사용자는 쿠키를 조작할 수 있다. 따라서 보안성을 생각해야 하며, 민감한 정보는 쿠키에 담지 않는 것이 좋다.

클라이언트 측면에서의 단점

• 쿠키는 브라우저에 저장되는 데이터이다.
  • 브라우저마다 쿠키의 용량이 제한된다. 따라서 저장할 수 있는 정보가 제한되고, 쿠키의 용량이 커지면 브라우저 성능에 영향을 미칠 수 있다.
  • 쿠키는 유효 기간을 설정할 수 있다. 만약 이를 설정하지 않거나, 유효 기간이 지난 쿠키는 브라우저가 종료되기 전까지 삭제되지 않기 때문에 불필요한 데이터가 쌓이게 되는 문제가 발생한다.
• 쿠키를 지원하지 않는 클라이언트가 존재할 수 있다.
  • 일부 클라이언트는 쿠키를 비활성화하는 경우도 존재한다. 이 경우를 방지하기 위해 다른 대체 기능을 구현해 사용해야 한다.

쿠키에 담기는 데이터

• expires: 만료 날짜 데이터
  • 만료 날짜를 지정하면 영속 쿠키로 해당 날짜까지 쿠키가 유지된다.
  • 만료 날짜를 생략하면 세션 쿠키로 브라우저 종료 시까지만 유지된다.
• max-age: 초 단위로 세팅하며 쿠키의 생명 주기를 지정한다.
• domain: 접근할 도메인을 지정한다.(naver.com)
  • 이 도메인을 생략하면 해당 도메인에서만 접근할 수 있다.
  • 이 도메인을 입력하면 해당 도메인과 하위 도메인 모두 접근할 수 있다.
• path: 경로를 지정해 줄 수 있다.(/user) (일반적으로 “/” 루트 패스로 지정한다.)
  • 지정한 경로를 포함한 하위 경로에서만 접근할 수 있다.
• secure: 이 쿠키를 넣으면 https에서만 전송하고, 넣지 않으면 http https 모두 전송한다.

쿠키를 삭제하는 방법!

쿠키를 삭제되지 않아 꽤나 고생했다.

HTTP/1.1 302 Found
Set-Cookie: sid=3d51fac6-8e92-453b-aff9-e4cfeb422264; path=/
Location: /index.html

해당 메시지는 내가 쿠키를 설정할 때 전송된 HTTP 응답 메시지이다.

클라이언트는 해당 메시지를 읽고, 쿠키로 sid의 값을 저장한 뒤 서버에게 요청마다 쿠키헤더에 담아 전송한다.

Cookie: sid=3d51fac6-8e92-453b-aff9-e4cfeb422264

실제로 매 요청마다 다음과 같은 헤더가 달려 전송되는 것을 확인할 수 있다.

---

HTTP/1.1 302 Found
Set-Cookie: sid=3a717e59-8400-4847-b1d3-90cea2582f28; Expires=Thu, 01 Jan 2000 00:00:00 GMT;
Location: /index.html

위 쿠키를 삭제시켜 주기 위해서는 Expires를 현재 or 과거 시간대로 두어 삭제시킬 수 있다.

또는 Max-age의 시간을 0으로 두어 삭제할 수 있다고 한다.

하지만 삭제되지 않았다..

이를 해결하기 위해 다양한 방법을 시도했다. 먼저 Set-Cookie에 값을 빈 값이나, 다른 값으로 변경해보기도 하고, 상태 응답코드를 302가 되는 경우 리다렉트 때문에 쿠키가 삭제되지 않을 수 있다는 이야기도 있어 200 상태코드로 바꾸어해보기도 하였다. 하지만 캐시는 끝까지 삭제되지 않았다.

이유를 열심히 찾아본 결과 브라우저에게 캐시 삭제를 강요할 수 없다는 이야기를 들었고, 내가 내린 판단은 브라우저가 브라우저를 닫을 때 일괄적으로 삭제된다고 생각했다.

하지만 주변분들의 도움을 받아 더 다양한 경우를 시도해 본 결과 문제는 Set-Cookie의 내용에 path=/ 부분이 빠진 것이었다.

결론은 단 하나..

path=/ 빼먹지 말자..!!

HTTP/1.1 302 Found
Set-Cookie: sid=3a717e59-8400-4847-b1d3-90cea2582f28; Expires=Thu, 01 Jan 2000 00:00:00 GMT; path=/
Location: /index.html

캐시 삭제에 성공한 요청 메시지이다.

 

[참고자료]

김영한 님 MVC 2편 스프링 강의