책에 나와있는 리팩토링 1단계 힌트를 참고하여 요청 데이터를 처리하는 로직을 별도의 HttpRequest 클래스로 작성했다. 해당 클래스는 InputStream으로 전달받은 Http 메시지를 다음 4가지 필드로 파싱하고 저장한다. 1. 서버의 동작 내용을 판단하는 "Method" 2. 어떤 리소를를 읽을지 판단하는 "Path" 3. 리소스의 타입, 로그인 상태 등의 속성을 가지고 있는 "Header" 4. 추가적으로 필요한 내용이 담긴 "Body"
우선 내가 이해한 리팩토링은 프로그램에 필요한 기능을 잘 나누고 (예- Http 요청 메시지를 method, path, header, body로 나누어 파싱하자) 비슷한 기능들을 묶어 (Http 요청 메시지 관련한 기능들) 하나의 클래스가 처리할 수 있도록 구성해야 하는 것 같았다. 또한 클래스를 만들기 전에 성격에 따라 필드를 그룹핑하고 구분 짓는 것도 필요하겠구나 싶었다. + 동작이 잘 되는지 최소한의 테스트코드도 같이 작성해야 한다.
+ WebServer에서도 해당 클래스를 사용하도록 메시지를 전달하도록 수정을 같이 해 주었는데 응답하지 않는 에러가 발생한다. 이 부분은 강사님이 구현한 내용과 비교해보며 어떤 부분을 잘못 쓰고 있는지 다시 확인해 봐야할 것 같다.
HTTP 전송, 응답 메시지를 보면 다음과 같이 다양한 방식으로 구성되어 있음을 알 수 있다. 1. queryString 형식 : field1=value1&field2=value2 (URL 중 ? 뒤에 붙거나 form 내용으로 전달되는 형식) 2. Header 필드 형식 : field1: value1 3. Header 필드의 value의 형식 : - Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 - Cookie: logined=true; path=/
강사님이 제공하는 소스를 보면 각각의 메시지 중 필요한 key와 value값을 파싱하기 위한 클래스를 따로 정의해서 제공해주셨다. 나는 해당 클래스에 몇가지 메서드 및 각 메서드가 잘 작동하는지 테스트 케이스를 추가했다. 그리고 강사님이 작성한 테스트 케이스와 비교해 보았다.
먼저 강사님이 작성한 내용을 보면 훨씬 한눈에 읽기가 쉽다. 동작 확인할 메서드를 실행한 후 결과값에서 원하는 키를 꺼내고, 이 값이 실제로 내가 원하는 것이 맞는지?의 방식으로 테스트가 되고 있다. 결과값이 기대값과 같은지? 의 방식으로 테스트가 되고 있어서 문맥상으로도 훨씬 이해하기 쉽다. (나는 반대의 방식으로 했었다.) 그리고 없는 키를 찾는 경우 결과값이 null인지? 에 대한 코드도 있음을 알 수 있다. (이 부분은 Map 자체의 특성이기도 해서 해당 클래스의 기능에 대해서도 잘 이해하고 있어야겠구나 싶었다.)
그리고 null, "", " ", 유효한 속성 및 유효하지 않은 속성이 전달되는 경우 빈 map객체가 리턴되는지에 대한 테스트 코드도 같이 작성되어 있음을 알 수 있다.
먼저 해당 웹 서버가 어떤 식으로 동작하는지 내가 이해한 만큼 그림으로 그려보았다. 또한 코드 중 사용자의 요청을 동시에 받아 처리할 수 있도록 RequestHandler가 Thread를 기반으로 상속되어 있는 것은 100% 이해하진 못한 것 같아, 다시 코드를 작성하며 공부를 해야할 것 같다. 그리고 한가지 헷갈렸던 부분은 java.util.stream.Stream과는 전혀 다른 Stream 기반 (java.io)을 사용한다는 것이다. Socket이 제공하는 java.io 패키지의 InputStream으로는 사용자가 요청한 데이터를 읽고, OutputStream으로 데이터를 전송하는 것을 알게 되었다. Stream도 간단한 코드를 작성해서 정리해봐야겠다.
HTTP웹 서버 구현을 통해 HTTP 이해하기 1 - 요구사항 구현 내용 중 강사님께서 try () 안에 Closeable이 상속된 객체를 생성하면 굳이 close를 안해도 java compiler가 알아서 삭제를 해준다는 언급을 해 주셨는데 관련해서 어떤 내용인지 알고 싶고, java.io.inputStream 관련해서도 모르는 부분이 많은 것 같아 찾아보게 되었다.
예를 들어 파일에서 내용을 읽어와 다른 파일에 복사하는 코드가 있다고 하자. 복사할 때 반드시 bw.close() 를 호출해야 내용이 쓰여지고 (쓰여지는 건 flush라는 호출만으로 가능하다) 관련된 리소스가 삭제된다.
File sourceFile = new File("recipe_src.txt");
File copiedFile = new File("recipe_dst.txt");
try {
FileInputStream is = new FileInputStream(sourceFile);
InputStreamReader ir = new InputStreamReader(is);
BufferedReader br = new BufferedReader(ir);
FileWriter fw = new FileWriter(copiedFile);
BufferedWriter bw = new BufferedWriter(fw);
String source = "";
String line = "";
while ((line = br.readLine()) != null) {
source += line + "\n";
}
bw.write(source);
bw.close();
br.close();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
하지만 try 사이에 () 괄호문을 넣어주고 그 안에서 객체를 생성한다면 close를 굳이 안해줘도 된다. java 7버전에서 제공되는 기법으로 try-with-resources 이라고 한다. java compiler가 생성된 리소스를 알아서 삭제해준다고 하니 훨씬 편한 것 같다. 그런데 자바는 굳이 생성된 객체 관리를 안해도 되지 않나? (가비지 콜렉터가 있기 때문) 이 경우는 왜 자동으로 삭제가 안되고 직접 close()를 호출해야 하는지 잘 모르겠다.
File sourceFile = new File("recipe_src.txt");
File copiedFile = new File("recipe_dst.txt");
try (InputStreamReader ir = new InputStreamReader(new FileInputStream(sourceFile));
BufferedReader br = new BufferedReader(ir);
BufferedWriter bw = new BufferedWriter(new FileWriter(copiedFile));) {
String source = "";
String line = "";
while ((line = br.readLine()) != null) {
source += line + "\n";
}
bw.write(source);
// bw.close(); 안해줘도 된다.
// br.close();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
<자바 웹 프로그래밍 - Next Step의 HTTP 웹 서버 구현을 통해 HTTP 이해하기> 에 나와있는 요구사항들을 토대로 HTTP 요청이 오면 서버에서 각 리소스별로 어떻게 응답할지에 대한 구현을 무작정 시도해 보았었는데 오늘은 유투브 영상과 책을 참고하며 더 나은 방법과 잘 이해하지 못했던 부분을 다시 이해하며 적용해 보았다.
- 알게 된 것 1. HTTP에서 교환하는 정보는 다음과 같이 정해진 표준 규칙에 따라 구성된다. (시작줄과 헤더는 필수 구성요소이다.) 시작줄 : 메서드, URI, 버전 헤더 : <Key> : <Value> 와 같은 형태로 다음과 같은 값들이 들어갈 수 있다. (Host부터 시작)
바디 : 전송되는 데이터로 헤더와 \r\n (빈줄 공백) 다음에 위치한다. 예를 들어 서버측에서 Stream을 통해 클라이언트에서 요청된 바디를 읽을 때 read()를 사용하는데, 이때 데이터의 길이가 어느 정도 되는지를 헤더의 Content-Length를 통해 알아내어 파라미터로 전달해 파싱할 수 있도록 한다.
2. 302 Redirect의 의미는 브라우저에게 서버가 보내는 URI 다시 보내달라고 요청하는 의미이며 (이것 역시 표준으로 정해져 있다.) 다음과 같이 작성할 수 있다.
