🔍 Tomcat의 maxPostSize 체크 메카니즘

톰캣이 클라이언트로부터 요청을 받으면, 내부적으로 org.apache.catalina.connector.Request 객체가 이 요청을 처리합니다.

 

구체적인 체크 과정은 다음과 같습니다.

1. HTTP 헤더 스캔 (Early Check)

클라이언트가 POST 요청을 보내면 톰캣은 가장 먼저 HTTP 헤더의 Content-Length 값을 읽습니다.

• 작동 방식: 실제 데이터를 다 읽기 전, 헤더에 적힌 숫자가 설정된 maxPostSize보다 크면 즉시 거부할 준비를 합니다.
• 효율성: 데이터 본문(Body)을 전부 서버 메모리에 올리기 전에 미리 차단하여 불필요한 네트워크 대역폭 소모를 방지합니다.

2. 파라미터 파싱 단계 (Actual Check)

실제로 데이터가 서버로 들어오면, 톰캣이 getParameter() 같은 메서드를 통해 데이터를 읽으려고 시도할 때 체크가 일어납니다.

• 동작 시점: 서블릿이 request.getParameter()를 호출하는 순간, 톰캣 내부의 parseParameters() 메서드가 실행됩니다.
• 체크 로직:
  1. 데이터를 읽어들이면서 현재까지 읽은 바이트(byte) 수를 카운트합니다.
  2. 이 카운트가 maxPostSize를 초과하는 순간 IllegalStateException 또는 에러를 발생시킵니다.
  3. 이때 톰캣 로그에 그 유명한 Post too large 메시지가 남게 됩니다.

3. 멀티파트(Multipart) 요청 시의 차이점

파일 업로드와 같은 multipart/form-data 방식일 때는 체크 방식이 조금 달라질 수 있습니다.

• Tomcat 7/8 이상: 톰캣 자체의 서블릿 3.0+ 기능을 사용한다면 server.xml의 maxPostSize가 적용됩니다.
• 주의사항: 만약 Spring의 MultipartResolver나 Apache Commons-FileUpload 같은 외부 라이브러리를 사용한다면, 톰캣의 설정보다 애플리케이션(Spring) 내부의 파일 제한 설정이 우선순위를 가질 때가 많습니다.

---

🛠️ 내부 소스코드 구조 

• org.apache.catalina.connector.Request: 요청 데이터를 처리하는 메인 클래스.
• parseParameters(): maxPostSize를 체크하고 파라미터를 메모리에 적재하는 핵심 메서드.

결론: 톰캣은 무작정 데이터를 다 받고 나서 "크네?"라고 하는 게 아니라, 헤더를 보고 1차 필터링을 한 뒤, 파라미터를 추출(Parsing)하는 과정에서 실시간으로 크기를 감시합니다.

 

tip 체크로직 소스 참고 링크

https://zz9z9.github.io/posts/http-post-request-body-size-limit/

 

minor버젼에 따른 셋팅값 상이사항

https://jihwan-study.tistory.com/72