[Han, Jay] 웹서버 1단계 구현 #48

beginin15 · 2020-03-19T09:40:19Z

구현사항

브라우저의 요청 URL 에서 resource path를 기반으로 나뉘어져서 응답하도록 구현
Session DB를 나름 구현해봤음.
로그인 + Cookie 기능 구현
로그인 시에 유저 리스트를 보여주도록 구현
RequestHandler 부분만 리팩토링 하였음. 2단계 진행시에 교안 참고하여 더 진행해볼 생각입니다.

질문사항

동적으로 HTML을 변경하는 코드에서 byte[] 배열 => String => StringBuilder로 변환하여 구현했는데 자연스럽지 않다.
세션 DB가 잘 구현되었는지 의문입니다.
어떤 상황에서 브라우저의 요청이 null로 넘어오는지 궁금합니다.

BufferedReader를 이용, Request Header가 전체 출력되는 것 확인, Null 처리

/index.html 요청시, split 하여 정상적으로 출력된다. IOUtils parsePath method를 통해 위 요청사항을 해결

index.html 요청 시, 브라우저 출력 확인

URL 추출 메서드 이름 변경, 위치를 HttpRequestUtils로 변경

QueryString에 따른 User 객체 생성, 일치 확인

URL 이 / 이거나, /index.html일 때 index.html을 반환하도록 함. 이외 /user/create 시 객체를 생성하는 과정을 수행하도록 설정.

get -> post

header에서 content-legnth를 추출하여, 이에 해당하는 body를 읽어오는 기능 확인 body를 기반으로, User 객체 생성

302header method를 통해, 회원가입 후 브라우저에 302 status 보내서 "/"로 redirect 하도록 설정

header parse HttpRequestUtils.parseHeader를 이용. 404에 해당하는 url 요청 처리

Database 클래스를 이용하여, 회원가입 기능 구현 Database에서 로그인을 시도한 유저가 존재하는지 확인하고 성공, 실패시 로그 출력 Database에 테스트 유저가 자동적으로 추가되도록 설정

로그인 성공, 실패시 브라우저에게 전송될 header, body 설정 실패시에는 401 상태를 보내줌. 아직 로그인을 시도한 유저가 db에 존재하지 않을 때 어떻게 해야할지는 고민중

JSESSIONID를 생성하여 Set-Cookie에 저장함.

요청 헤더에서 jessionid value 추출 sessiondb에 존재하는지를 판단하여 있으면 user/list.html 보여주고 없으면 302 헤더와 함꼐 login페이지를 보여주도록 설정

db에서 user를 가져와서 list.html에 추가함.

css 자원을 요청하는 request에 대한 응답 구현

HttpResponse, SessionUtils 클래스 생성하여, 책임을 나눴다. 전자에는 요청파일을 응답하는 메서드를 할당하고, 후자에는 session 기능을 담당하게 만들었음.

redirect302, redirectWithCookie, readCss

readStaticFile, response404Header 추가함

if => switch문으로 변경 HttpRequestUtils의 extractHeader 메소드를 이용하여 헤더를 추춣하는 기능 분리

convention 수정 존재하지 않는 회원이 로그인을 시도한 경우, login_Failed.html 출력하도록 구현

1단계 배포 테스트

httpRequest 클래스 만들었고, HttpMethod enum 생성, httpRequest method 에 대한 테스트 코드 작성

HttpResponseUtils의 기능을 HttpResponse로 옮김

Response 클래스와, util 클래스의 책임과 역할을 나눔. response forward 시, 웹서버내 정적자원을 찾아서 브라우저에게 전달해주도록

[웹서버 2단계] Refactor

imjinbro · 2020-03-22T17:50:49Z

src/main/java/db/DataBase.java

+    public static int getSizeOfUsers() {
+        return users.size();
+    }
+
    public static void addUser(User user) {


User 파라미터가 null인 경우에 대한 처리가 없네요
호출하는 쪽에서 null을 거르면 호출하는 곳마다 null을 체크해야하지만 해당 메소드 내부에서 안전하게 처리를 해둔다면 여러번 처리를 하지 않겠죠?

imjinbro · 2020-03-22T17:55:01Z

src/main/java/db/DataBase.java

-    public static User findUserById(String userId) {
-        return users.get(userId);
+    public static User findUserById(String userId) throws NoSuchElementException{
+        return Optional.ofNullable(users.get(userId)).orElseThrow(NoSuchElementException::new);


저는 호출 하는 쪽에서 Optional로 받고 예외를 발생시킬 지 말지를 정하도록 하는 것이 좋다고 생각하는 편 입니다.
위와 같이 기능 메소드에서 예외를 발생시킬 경우 예외를 발생시키지 않아도 되는 상황에 일률적으로 발생시키는 것이 되어버리며 정상적인 진행이 되도록 하기 위해 try ~ catch 처리를 해야하기 때문입니다.

imjinbro · 2020-03-22T17:55:54Z

src/main/java/db/SessionDataBase.java

+public class SessionDataBase {
+    private static Map<String, User> sessions = Maps.newHashMap();
+
+    public static void addSession(String sessionId, User user) {


위 UserDataBase와 동일한 피드백을 드리고 싶군요

imjinbro · 2020-03-22T17:57:37Z

src/main/java/db/SessionDataBase.java

+    }
+
+    public static boolean isSessionIdExist(String sessionId) {
+        return sessions.containsKey(sessionId);


위 메소드들과 마찬가지로 예외처리를 보강해주셔야합니다.

imjinbro · 2020-03-22T18:01:17Z

src/main/java/http/HttpRequest.java

+    private Map<String, String> header;
+    private Map<String, String> parameter;
+
+    public HttpRequest(BufferedReader br) {


HttpRequest는 입력을 파싱하여 각각을 필드로 갖고 있는 클래스로 보이는데, BufferedReader를 생성자로 꼭 받을 필요가 있을까요?
요청 데이터가 표준입력이 아닌 파일입력 또는 그외의 방식으로 변경될 경우 HttpRequest 클래스에도 그 영향이 가지 않을까요?
여기에 대한 고민 한번 해보시고 리팩토링 권해드립니다.
저는 HttpRequest가 입력값만 받아도 크게 이상 없다고 피드백 드리겠습니다.

imjinbro · 2020-03-22T18:01:54Z

src/main/java/http/HttpRequest.java

+        String requestLine;
+
+        try {
+            requestLine = br.readLine();


해당 라인 또한 사용자의 요청 입력 방식 변경이 영향 미칠 라인입니다.

imjinbro · 2020-03-22T18:07:38Z

src/main/java/http/HttpResponse.java

+import java.util.List;
+import java.util.Map;
+
+public class HttpResponse {


여러 리스폰스 코드(200, 302 등)에 맞춰 메소드를 만든 것으로 보입니다.
그리고 해당 메소드에 DataOutputStream 메소드가 있군요
HttpResponse는 말그대로 응답에 대한 필드만 가지고 있으면 될 것으로 보입니다. 2개의 역할을 모두 하고 있는 것으로 보여요
그리고 HttpResponse는 몇가지 정해져 있으니 각 응답코드에 맞춘 객체를 미리 생성해두고 재활용하면 어떨까요?
메소드로 풀어내는 것을 유지한다면 응답코드 대응할 때마다 메소드가 여러개 늘어나고, 이전에 만들었는지 체크하기도 힘들 것입니다.

imjinbro · 2020-03-22T18:09:32Z

src/main/java/model/User.java

@@ -13,6 +13,11 @@ public User(String userId, String password, String name, String email) {
        this.email = email;
    }

+    public User(String userId, String password) {


생성자에서 예외처리가 필요해보입니다
userId, pwd 입력이 없을 경우에 대한 처리가 바깥에서 이뤄지거나 아예 없거나 한다면 User가 비정상적인 입력값에 의해서도 데이터가 계속해서 쌓일 수 있는 위험이 있습니다.

imjinbro · 2020-03-22T18:18:25Z

src/main/java/webserver/RequestHandler.java

+
+            log.error("url : {}", url);
+
+            switch (url) {


RequestHandler 개념 도입은 좋아보이네요
RequestHandlerMapper 역할(적절한 RequestHandler를 찾아 위임하는 역할)을 하나 더 추가해보는 것은 어떨까요?

요청 url이 많아질 수록 case문은 늘어날 것이고 관리 하기가 매우 어려워 질 것 입니다.
RequestHandlerMapper가 RequestHandler List를 가지고 있고, 각 RequestHandler는 자기의 요청인지 알아차릴 url을 멤버 필드로 가지고 있으면 switch 문을 쓰지 않을 수 있을 것입니다.

spring mvc 처리 흐름 그림을 보시면 도움이 될 것 같습니다.

imjinbro · 2020-03-22T18:24:03Z

동적으로 HTML을 변경하는 코드에서 byte[] 배열 => String => StringBuilder로 변환하여 구현했는데 자연스럽지 않다.

구체적으로 어떤 부분에서 자연스럽지 않고, 고민 거리가 무엇인지 적어주시면 같이 고민해볼 수 있을 것 같습니다.

세션 DB가 잘 구현되었는지 의문입니다.

메모리 DB에 대한 코멘트는 남겨두었습니다. 예외처리를 보강 했으면 합니다. 구체적으로 어떤 의문인지는 몰라 의문이 해소되었을지는 모르겠습니다.

어떤 상황에서 브라우저의 요청이 null로 넘어오는지 궁금합니다.

브라우저가 아니더라도 curl로도 서버에 요청이 가능합니다. 서버에서 원하는 데이터를 포함시키지 않고 요청을 던지면 null인 상황이 있겠죠? 해당 경우 말고도 예상치 않은 요청이 가능하기때문에 모든 가능성을 열어둔 예외처리가 필수입니다.

imjinbro · 2020-03-22T18:24:39Z

수고하셨습니다.
답변이 애매하거나 잘 모르겠는 부분 있으면 슬랙 dm(colin)으로 질문 주세요

beginin15 and others added 29 commits March 16, 2020 17:51

[1단계] Request Header 출력

f4923c4

BufferedReader를 이용, Request Header가 전체 출력되는 것 확인, Null 처리

[1단계] path 분리

e6ad562

/index.html 요청시, split 하여 정상적으로 출력된다. IOUtils parsePath method를 통해 위 요청사항을 해결

[1단계] Request에 따른 응답하기

97f55a9

index.html 요청 시, 브라우저 출력 확인

[2단계] refactor Utils

bffb09e

URL 추출 메서드 이름 변경, 위치를 HttpRequestUtils로 변경

[2단계] User 객체 생성

d7d51d4

QueryString에 따른 User 객체 생성, 일치 확인

[2단계] refactor requestHandler

c70def8

URL 이 / 이거나, /index.html일 때 index.html을 반환하도록 함. 이외 /user/create 시 객체를 생성하는 과정을 수행하도록 설정.

[3단계] 회원가입 전송 method 수정

de6b63d

get -> post

[3단계] Post 방식 회원가입

e7176bc

header에서 content-legnth를 추출하여, 이에 해당하는 body를 읽어오는 기능 확인 body를 기반으로, User 객체 생성

[4단계] 회원가입 후 redirect

1f2ab3e

302header method를 통해, 회원가입 후 브라우저에 302 status 보내서 "/"로 redirect 하도록 설정

[4단계] refactor decode method 생성

8e70aac

[4단계] refactor RequestHandler

bbf6d71

header parse HttpRequestUtils.parseHeader를 이용. 404에 해당하는 url 요청 처리

[5단계] 회원가입 , 로그인 기능

8bae0f8

Database 클래스를 이용하여, 회원가입 기능 구현 Database에서 로그인을 시도한 유저가 존재하는지 확인하고 성공, 실패시 로그 출력 Database에 테스트 유저가 자동적으로 추가되도록 설정

[5단계] 로그인 기능 + redirect

24956dc

로그인 성공, 실패시 브라우저에게 전송될 header, body 설정 실패시에는 401 상태를 보내줌. 아직 로그인을 시도한 유저가 db에 존재하지 않을 때 어떻게 해야할지는 고민중

[5단계] Set-Cookie 구현

d9db934

JSESSIONID를 생성하여 Set-Cookie에 저장함.

[6단계] user/list 요청

5c412a1

요청 헤더에서 jessionid value 추출 sessiondb에 존재하는지를 판단하여 있으면 user/list.html 보여주고 없으면 302 헤더와 함꼐 login페이지를 보여주도록 설정

[6단계] 유저리스트를 동적으로 보여주기

2637a42

db에서 user를 가져와서 list.html에 추가함.

[7단계] stylesheet file 요청에 대한 응답

63832f2

css 자원을 요청하는 request에 대한 응답 구현

[7단계] refactor RequestHandler

30dbdf3

HttpResponse, SessionUtils 클래스 생성하여, 책임을 나눴다. 전자에는 요청파일을 응답하는 메서드를 할당하고, 후자에는 session 기능을 담당하게 만들었음.

[7단계] refactor RequestHandler

52f53b7

redirect302, redirectWithCookie, readCss

[7단계] refactor RequestHandler

53977ff

readStaticFile, response404Header 추가함

[7단계] refactor RequestHandler

c3d7eb9

if => switch문으로 변경 HttpRequestUtils의 extractHeader 메소드를 이용하여 헤더를 추춣하는 기능 분리

[7단계] refactor RequestHandler

ae01631

convention 수정 존재하지 않는 회원이 로그인을 시도한 경우, login_Failed.html 출력하도록 구현

Merge pull request #16 from beginin15/step7

d68a164

1단계 배포 테스트

[deploy] 배포 컴파일 에러 수정

39e1b94

[deploy] README 업데이트

0600e24

[Refactor 1단계] 메서드 , 클래스 분리

113fa7a

httpRequest 클래스 만들었고, HttpMethod enum 생성, httpRequest method 에 대한 테스트 코드 작성

[Refactor 2단계] HttpResponse 분리

885c742

HttpResponseUtils의 기능을 HttpResponse로 옮김

[Refactor 2단계] HttpResponse , utils

9c8d051

Response 클래스와, util 클래스의 책임과 역할을 나눔. response forward 시, 웹서버내 정적자원을 찾아서 브라우저에게 전달해주도록

Merge pull request #21 from beginin15/refactor

5741c8b

[웹서버 2단계] Refactor

imjinbro reviewed Mar 22, 2020

View reviewed changes

honux77 merged commit 6bd765f into code-squad:beginin15 Mar 24, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Han, Jay] 웹서버 1단계 구현 #48

[Han, Jay] 웹서버 1단계 구현 #48

Uh oh!

beginin15 commented Mar 19, 2020

Uh oh!

imjinbro Mar 22, 2020

Uh oh!

imjinbro Mar 22, 2020

Uh oh!

imjinbro Mar 22, 2020

Uh oh!

imjinbro Mar 22, 2020

Uh oh!

imjinbro Mar 22, 2020

Uh oh!

imjinbro Mar 22, 2020

Uh oh!

imjinbro Mar 22, 2020 •

edited

Loading

Uh oh!

imjinbro Mar 22, 2020

Uh oh!

imjinbro Mar 22, 2020

Uh oh!

imjinbro commented Mar 22, 2020

Uh oh!

imjinbro commented Mar 22, 2020

Uh oh!

Uh oh!

[Han, Jay] 웹서버 1단계 구현 #48

[Han, Jay] 웹서버 1단계 구현 #48

Uh oh!

Conversation

beginin15 commented Mar 19, 2020

구현사항

질문사항

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

imjinbro Mar 22, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

imjinbro commented Mar 22, 2020

Uh oh!

imjinbro commented Mar 22, 2020

Uh oh!

Uh oh!

imjinbro Mar 22, 2020 •

edited

Loading