BufferedReader의 readLine()으로 HTTP 요청 파싱 중 생긴 문제

우아한테크코스 레벨 4 미션 중 요청의 헤더와 바디를 파싱해야 하는 상황이 생겼다. 그래서 HTTP 요청의 첫 줄인 요청 라인(Request Line)을 파싱하던 것처럼 BufferedReader의 readLine()을 반복해서 파싱하려고 했다. 그런데, 이상하게 자꾸 응답이 오지 않고 웹 브라우저가 무한 로딩에 빠지고 있는 것이다.

// 파싱을 위한 코드 일부
String tmp;
while ((tmp = bufferedReader.readLine()) != null) {
	// 파싱을 처리하는 코드 ...
}

 

그래서 이를 파악하기 위해 서버에 파싱이 잘 되고 있는지 로그를 남겨 확인해봤다. 그런데 파싱 관련 로그가 남지도 않는 것이다! 재밌는 점은 다시 새로고침하거나 다른 요청을 보내면 그제서야 파싱 관련 로그가 쫘르륵 나왔다는 점이다. 근데 여기서 한 가지 의문이 들었다. 분명 첫 줄인 요청 라인을 파싱할 때는 문제없었던 것이 여러 개를 파싱하려고 하니 문제가 되는 것이 아닌가?

그래서 while 문을 잠시 지우고, 연속해서 3개만 읽어보기로 했다.

예상외로 문제없이 잘 되었다. 그래서 요청 헤더까지는 잘 읽을 수 있는 것으로 추측을 했고, 요청 바디를 읽을 때 문제가 생기는 것 같았다. 그래서 먼저 readLine()이 어떤 방식으로 한 줄을 읽는지 찾아보기 위해 공식 문서를 찾아보았다.

 

 

설명을 해석해보면, readLine()은 줄의 끝을 LF(’\n’), CR(’\r’) 또는 CRLF(’\r\n’)로 판단하고 있다는 것을 알 수 있다. 그렇다면 헤더의 경우에는 CR, LF 또는 CRLF가 줄 끝에 붙지만 Body의 경우에는 뭔가 이러한 처리가 안되고 있는 것 같았다. 그래서 한 가지 실험을 시도해봤다. 바로 Body에 의도적으로 줄의 끝을 의미하는 문자를 넣는 것이다.

 

 

역시 예상대로 잘 작동했고, 이를 확실하게 매듭짓기 위해서 HTTP 명세를 살펴보았다.

 

 

미션에서 HTTP/1.1을 기준으로 하고 있기에 이에 대한 명세를 봤는데, Message Format이 그림처럼 되어있었다. 해석해보면 헤더의 각 줄에는 끝에 개행을 의미하는 CRLF가 들어가도록 되어 있으며, 헤더와 바디 사이에는 CRLF로 서로 공간을 분리한다. 그 후 message-body가 들어가는데 여기에는 CRLF가 들어가야 한다는 규칙이 없다! 그렇다면, HTTP의 각 헤더들은 CRLF가 명세에 지정되어 있어 한 줄을 읽을 수 있지만, HTTP 바디는 바디 값에 따라 CR, LF 혹은 CRLF가 없을 수 있기 때문에 BufferedReader 입장에서는 어디까지 읽어야 할지 판단할 수 없는 것이다. 그래서 요청이 처리되지 못하고 무한 대기에 빠지게 된 것이다.

이런 문제를 해결하기 위해서 이번 미션에서는 BufferedReader의 read() 메서드를 사용했다. 특히, Body가 있는 경우라면 Content-Length도 함께 넘겨주므로 이를 이용해 파싱하도록 했다.

String length = requestHeader.getHeader("Content-Length");
int contentLength = Integer.parseInt(length);
char[] buffer = new char[contentLength];
bufferedReader.read(buffer, 0, contentLength);
String requestBody = new String(buffer);

HTTP에 대한 지식이 정말 중요한 것 같다.