[Spring] Json 응답 gzip 압축하기 - 2

이전 글에서 min-reponse-size 설정값에 대한 문제가 있었습니다.

해결방법을 찾아서 돌아온다고 했지만..

 

시도해보려고 한 방법은 두 가지 입니다.

1. 응답값에 대한 Content-Length 헤더를 직접 HttpServletResponse에 넣어준다.

이 방법에는 큰 문제가 있습니다. 이전 글에서도 언급했듯이 Transfer-Encoding 헤더 문서를 보면 Content-Length가 생략된다고 나와있습니다.

생략되는 이유는 rfc 7230 section 2.2.2 을 보면 스펙으로 정해놓을 것을 볼 수 있습니다.

(Spring Framekwork 깃허브 저장소에 같은 내용의 이슈가 등록되어 있습니다.)

간단하게 요약하자만 Transfer-Encoding 과 Content-Length 헤더가 공존할 때 Transfer-Encoding이 Content-Length를 덮어쓰고 응답에는 Content-Length 헤더가 삭제돼야 한다는 의미입니다.

 

즉 Content-Length를 직접 넣는것은 문제가 발생할 수 있습니다.

 

2. 내부 구현을 바꿔볼 수 있는가?

 

Http1Prosessor 클래스 내부의 compression에 대한 메소드를 타고 들어가다 보면 CompressionConfig를 만날 수 있습니다.

위의 CompressionConfig 클래스 파일은 package org.apache.coyote; 패키지에 존재하는 클래스입니다.

 

CompressionConfig 클래스는 응답값 압축에 대한 설정을 담당하고있습니다.

내부에는 useCompression(Request request, Response response) 라는 메소드가 있습니다.

compression 설정에 따라 분기를 타면서 압축을 실행하지 않으면 false를 반환하고 압축을 실행하면 true를 반환합니다.

(실제로 내부 코드를 들여다보면 

 

이 부분을 비슷하게 구현해서 우리의 Controller 코드에 넣어주면 될거라 생각합니다.

(디버깅을 해보면 Content-Length를 -1로 가져와서 비교하는것을 확인할 수 있습니다. -1이라는 것은 사실상 헤더가 존재하지 않음을 나타내는것 입니다.)

 

하지만 이 방법도 선택하지 않았습니다.

현재 문제는 320byte를 압축시켜 370byte가 됐습니다.

이것을 직접 코딩해서 개선했을 때 극적인 변화가 생길것인가? 라고하면 아니라고 생각합니다. 

추가한다면 이득이 생기겠지만 지금 상황에서는 꼭 필요한 작업이 아니라고 생각합니다!

 

즉 현재는 min-response-size설정이 잘 먹히지 않더라도 큰 문제는 없다고 결론지었습니다 :)