3주차 금요일 그룹 1

😊 김민주

request InputStream에서 오류가 있을 경우 문제가 발생할 수 있지 않을까? release가 안 될 수 있음

싱글턴을 위해 static으로 getInstance, 가시성 문제를 위해 volatile사용해야 하는 부분이 좋음

오개념!!!!! Cache-Control 쓰면 요청 안 보낸다~~

Cache-Control을 사용하면 브라우저에 캐시되어있는 정적 데이터는 따로 요청을 보내지 않음

→ 304 Not Modified랑 헷갈린듯, E-Tag랑 304로 Not Modified를 해야 서버에서 검사하고 변경 안 됐으면 요청 안 보내는 걸로 알고 있음

application이 webserver를 알면 사용할 수 있게 한다의 의미가 적절한 것 같음

의존하는 부분 궁금

application이 web server를 알면 ㄱㅊ, 그러면 web server에서 application을 몰라야하는거?

의존이란, 구현을 모른다

→ 이렇게 접근하면 굳이 invoke하는 게 의존한다(구현을 안다)라고 볼 수는 없는 것 같음

HTTP Version의 차이를 Client Server가 어떻게 결정할까

httpRequest의 버전이 높게 왔고, 서버의 가능한 버전이 낮으면 어떻게 협상하나

서버에서 가능한!

😁 지찬우

• 멀티 스레드에서의 싱글톤 문제
  • synchronized block과 volatile 키워드를 사용해 해결해야 함
• request 파싱 중 예외가 발생하면 어떻게 처리할 것인가?
  • 현재 구조에서는 RequestHandler의 handle에서 RuntimeException을 처리하기 때문에 handle을 호출하는 processor에서 발생하는 런타임 에러(ex. request 파싱 등)를 핸들링하기 어려워 졌다. ⇒ 고민해 보고 리팩토링 하기!
• Cache-Control과 If-Unmodified-Since의 차이
  • Cahce-Control은 브라우저 레벨에서 max-age 값에 지정된 시간만큼 디스크에 캐싱해 두고 아예 요청을 보내지 않는 방식
  • If-Unmodified-Since는 서버로 요청은 가지만 서버레벨에서 해당 리소스가 지정된 시점 이후에 변경 사항이 없다면 리소스를 전달하지 않는 방식
• HTTP version의 역할, 만약 클라이언트가 보낸 version을 서버가 지원하지 않는다면?

😉 조희승

• static util class 와 singleton 차이
  • singleton 인터페이스를 써서 mock 가능, 필드를 가질 수 있다
  • static 로 짜면 mock 테스팅이 어렵다
• header cache-controll 에 대해 공부해 보자
• filter를 고민해 보자, application 에서 작성해서 webserver에서 가져올 수 있도록
• SessionManager을 web-server로 옮기자

😇 최현식

• DI 컨테이너를 두고 의존성을 자동으로 주입해주는 것과 RequestMapping 어노테이션을 만들고 이를 스캔해 자동으로 핸들러 맵핑해주는 로직을 많이들 사용하시는 것 같아 다음 구조 변경시에 참고하면 좋을 것 같습니다.
• Clinet와 Server가 HTTP로 통신할때, 어떠한 프로토콜을 사용할지 협상과정이 잇는 것으로 알고있는데, 이부분에 대해서 찾아본적이 없다보니, 궁금증이 생겼습니다. 한번 확인해봐야 될 것 같습니다. (예. Request가 HTTP2.0으로 왓으면 응답도 이와 상응해야하는가)
• Session을 관리하는 것은 WebServer와 Application 중 누구의 책임인지 이야기를 하였습니다. 실제 서버 접근 권한을 확인하고 필터링하기 때문에 WebServer에 책임 이라는 것과, 세션을 활용하는 것은 Application이기 때문에 이 쪽에 책임이라는 의견이였습니다. 어느쪽에 책임이라고 하든 적절한 근거가 있어서 앞으로 확장했을 때까지를 고려하며 어디에 위치시킬지 생각해보고 적용해야할 것 같습니다.
• Cache-Control 헤더를 사용하시는 분이 계셨는데 Unmodified 헤더와의 차이 위주로 한번 공부해봐야 할 것 같습니다.
• static을 사용하는 것은 테스트에 어려움을 준다는 이야기가 있었는데 이에 대해 공부해봐야 할 것 같습니다.
• 오늘도 많이 배우고 갑니다 ^_^ 갈수록 코드리뷰에서 배우는 점이 더욱 많아지는 것 같네요~

🙂 김수현

• 어플리케이션에서 SessionManager를 관리하는 코드를 보고 HttpSession을 제공하는고, 인증을 제공하는게 웹 어플리케이션 서버의 책임인가에 대해서 다시 생각해봤다.

  HTTP 세션 관리 기능은 Java Servlet API의 표준 기능 중 하나입니다. 
  따라서, Java 기반의 웹 서버나 서블릿 컨테이너(예: Apache Tomcat, Jetty, JBoss 등)는 
  HTTP 세션을 제공하도록 되어 있습니다. 그러나 HTTP 세션 관리 기능이 모든 웹 서버의 필수 기능은 아닙니다. 
  HTTP 세션은 서버가 클라이언트와의 상태를 유지하기 위한 메커니즘 중 하나로, 다양한 방식으로 구현될 수 있습니다.

• 세션 관리 기능이 Java Servlet API의 표준 기능이기 때문에 was가 교체되어도 기존의 session을 사용할 수 있도록 was가 지원해야한다고 생각한다.

• 요청 http 버전을 그대로 응답 http 버전으로 설정했는데, 잘못된 구현이라는 것을 깨달았다.

😗 오민석

• static을 남용하니 테스트가 어려웠습니다! 이를 변경하여 리팩토링해야될 것 같습니다!
• Thread Local에 너무 많은 값이 들어가 있어서 조금 이상한 것 같습니다!
• Checked Exception을 다른 방식으로 해결해야 할 것 같습니다!