세션이 생성되고 관리되는 과정

HTTP는 stateless다.
어떤 넘이 수백 번을 요청을 보내더라도 얘가 걘지 걔가 얘인지 알 수가 없다.
한 마디로 메멘토다. 장기 기억력을 상실했다.
요청에 대한 처리가 끝나면 갑자기 지금까지 했던 모든 것을 잊어버린다.

근데 분명히 웹에서 state는 필요하다. 안 그러면 장바구니 구현 어떻게 하는데?
그 것을 위하여 세션이라는 것이 HTTP를 보완해준다.

세션은 무언가?
한 마디로 말해서 클라이언트마다 주어지는 객체들이다.
클라이언트 하나당 세션 객체 하나가 주어진다.

그럼 클라이언트는 무엇인가? 특정 아이디? 특정 IP?
다 아니다. 클라이언트는 바로 브라우저 창 그 자체다.
인터넷 익스플로러를 더블 클릭을 두 번 눌러서 키면 니는 지금
클라이언트를 두 개나 생성한 것이다.
(아 물론 ctrl+n을 눌러서 만드는 건 같은 클라이언트임... 좀 다르더라구..)

이제 클라이언트가 뭔지 이해가 갔다.
클라이언트는 서버에 HTTP Request를 보낼 때마다
어느 것이 자기 세션인지 서버에 말을 해줘야 한다.
서버는 띨하니까!

그럼 세션 객체마다 구별해야 하는 정보가 있어야 한다.
이 것이 바로 session id다.
서로 다른 클라이언트는 서로 다른 session id를 이용하여,
서로 다른 session 객체에 접근하게 된다.

근데 아무 것도 없는 無의 상태에서 사용자의 브라우저가 갑자기 신내림을 받아서
session id를 지가 만들어낼 리가 만무하다.


세션은 서버 쪽에서 만들어진다.
원리는 이렇다.

< 세션 사용을 필요로 하는 사용자의 첫 요청 >
서버의 생각///// 어라, HTTP Request의 헤더에세션 id가 없네?
이 넘은 처음 요청한 넘이다. 세션 객체를 하나 새로 만들고
그 객체의 key를 HTTP Response의 헤더로 넘겨주자.
그 HTTP Response를 받은 클라이언트의 생각/////
어 이넘이 세션 ID를 줬어. 쿠키에 설정해놓자.

< 그 다음 요청들 >
클라이언트의 생각///// HTTP Request 헤더에 session id를 넣어서 보내자.
그 걸 받은 서버의 생각///// 이 넘은 예전에 보내줬나보네... 기억이 안나. 객체 만들필요 없겠군. 있던거 쓰자!


일련의 작업은 어디서 이루어지는감?

     HttpSession session = request.getSession();

저 코드에서 모든 것이 이루어진다. 컨테이너가 알아서한다.
개발자는 세션이 어떻게 생성되고, id는 어떻게 주고받아지는지 전혀 신경 쓸 필요 없다.
참고할 메소드들 알아보자.

(1) boolean b = session.isNew()   
//방금 전에 생성된 세션일 경우 true 리턴

(2) HttpSession session = request.getSession(false);   
//기존 세션 객체가 있으면 그 걸 리턴하고, 없으면 걍 null을 리턴해. 세션을 새로 만들지 말고...
//참고로 request.getSession(true)는 request.getSession()과 동일한 코드...



좋다. 근데 또 문제가 생겼다.
쿠키를 사용하지 않는 브라우저가 있다.
그런 넘에게는 URL을 통하여 session_id를 주고받는 방법밖에 없다.
이 것을 URL재작성이라고 부른다.
URL재작성은 서블릿 내에서 다음과 같은 코드로 이루어진다.

     out.println("<a href = \"" + response.encodeURL("/BeerTest.do") + "\">click me</a>");

URL뒤에 세션 ID를 추가하게 된다.
/BeerTest.do;jsessionid=0AAB6C7DE415 이런 식으로...
아 참고로 정적인 페이지(걍 html)는 쿠키를 사용하지 않는 브라우저에겐 방법이 없다.
위의 방법을 쓰려면 무조건 동적으로 생성되는 페이지여야함 -ㅅ-
(컨테이너의 지능에 따라서 재작성을 안할수도! 아래 참고!)



컨테이너는 다음과 같이 동작한다.

< HTTP Request header의 Cookie헤더 또는 URL에 session id가 없을 때 >
이 사용자는 처음 접속한 사용자다.
일단은 이 사용자가 쿠키를 사용할 수 잇는지 없는지 모른다.
그러므로 세션 id를 
HTTP 헤더와 URL 재작성, 두 가지 통로로 모두 보내본다.

< HTTP Request header의 Cookie헤더 또는 URL에 session id가 있을 때 >
이 사용자는 두 번째 이상 접속한 사용자다.
일단은 이 사용자가 쿠키를 사용할 수 있는지 없는지는
어디에 세션 id가 적혀있는지 보면 알 수 있다.
세션 id가 URL에 적혀있는 경우, request.encodeURL메소드는 URL을 세션id를 추가하여 재작성하게 된다.
세션 id가 HTTP Req 헤더에 적혀있는 경우, request.encodeURL메소드는 URL을 세션id를 추가하여 재작성하지 않는다. 그냥 안보내고 고고씽 해도 그 클라이언트는 세션 id 지가 알아서 저장한거기 때문.


그! 래! 서!
요청 파라미터의 jsessionid, JSESSIONID로 파라미터를 보내는
ㅄ짓은 하지 말자. 이미 예약되어있다. (RESERVED)