HTTP 1.1 프로토콜의 비효율성
-
불명확한 사양: RFC 문서들이 실제 구현의 참조 문서에 가깝고, 명확한 ‘규격’이 아니어서 혼란을 야기합니다.
-
이상한 선택: 청크 전송 시 청크 크기를 십진수가 아닌 16진수로 인코딩하거나, 상태 코드 뒤에 이유 문자열이 없어도 공백을 필수로 요구하는 등 이해하기 어려운 설계가 존재합니다.
폼 데이터 처리의 문제점
웹 폼 데이터는 application/x-www-form-urlencoded와 multipart/form-data 두 가지 “표준” 방식으로 인코딩되지만, 이들은 모두 심각한 문제점을 안고 있습니다.
1. application/x-www-form-urlencoded
-
가장 기본적인 표준: URL 쿼리 문자열과 유사한 형식을 사용합니다.
-
사양 부족: RFC 9110, 9112 모두 언급하지 않으며, RFC 1866(현재 폐기됨)에서 간략히 정의되거나 WHATWG URL 사양에 정의되어 있으나 변경될 수 있는 ‘살아있는 표준’입니다.
- 구현 불일치:
- 인코딩 방식: 명확한 사양 부재로 인해 이모티콘과 같은 특수 문자의 URL 인코딩 방식이 구현마다 다를 수 있습니다.
- 배열 처리:
numbers=1&numbers=2,numbers[]=1,2,numbers[0]=1&numbers[1]=2등 배열을 인코딩하는 여러 방식이 존재하여 상호 운용성을 저해합니다.
- 비효율성: 파일 업로드와 같은 대용량 비ASCII 데이터를 URL 인코딩할 경우 데이터 크기가 최대 3배까지 증가하여 전송 효율이 매우 떨어집니다.
2. multipart/form-data
-
이메일 형식 기반: RFC 7578에 정의되며, 각 필드가 경계(
--BOUNDARY)로 구분된 ‘파트’로 구성됩니다. - 설계 문제:
- 경계 충돌: 경계 문자열이 필드 값에 나타날 수 있어, 일반적으로 임의의 값을 생성하여 충돌을 피하지만 완벽하지 않습니다.
- 비효율적인 파싱: 여러 문자열로 구성된 경계 때문에 효율적인 파싱이 어렵습니다.
- 불필요한 복잡성: 닫는 경계(
--BOUNDARY--)에--를 추가하는 방식이 직관적이지 않습니다.
- 기능 부족:
Content-Length헤더가 지원되지 않아 파트 값을 한 번에 읽을 수 없으며,Content-Type헤더는 클라이언트가 거짓 정보를 보낼 수 있어 신뢰하기 어렵습니다. 배열이나 객체와 같은 데이터 타입에 대한 개념이 없어 시스템 간 데이터 직렬화 합의가 어렵습니다.
이러한 문제점들은 불필요하게 비대하고, 효율적인 파싱이 어려우며, 데이터 무결성 보장이 어려운 폼 인코딩 방식을 초래합니다.