HTTP/1.x 차단, 보안은 잡았지만 호환성은?

게시물에서는 Nginx의 `map` 지시어를 활용하여 HTTP/1.x 요청을 식별하고, 허용된 에이전트만 접근을 허용하거나, 악성 에이전트를 차단하는 두 가지 접근 방식을 제시한다. 첫 번째 접근 방식(Include)은 알려진 에이전트만 허용하여 보안을 강화하지만, 모든 유효한 에이전트를 식별하기 어렵다는 단점이 있다. 두 번째 접근 방식(Exclude)은 의심스러운 에이전트를 차단하여 더 유연하게 대응할 수 있지만, 오탐의 가능성이 존재한다.

게시물은 HTTP/1.x 요청에 대해 426 상태 코드를 반환하여 클라이언트에게 프로토콜 업그레이드를 안내한다. 426 응답(Response)은 `Upgrade` 및 `Connection` 헤더를 포함하여 HTTP/2로의 업그레이드를 시도하도록 유도한다. 하지만, 실제 사례에서는 426 응답을 받은 클라이언트가 업그레이드를 수행하는 경우는 드물다고 언급하며, 불필요한 노력이 될 수 있음을 지적한다.

커뮤니티에서는 HTTP/1.x 차단이 보안을 강화하지만, 호환성 문제(Compatibility Issues)를 야기할 수 있다는 점을 지적한다. 특히, 개인 도구 개발자나 구형 봇(Bot)의 경우 HTTP/2 및 HTTP/3의 복잡성으로 인해 HTTP/1.x를 사용할 수밖에 없는 상황이 발생할 수 있다. 결과적으로, 무분별한 차단은 개발 생태계에 부정적인 영향을 미칠 수 있다는 우려가 제기된다.

게시물은 HTTP/2 및 HTTP/3의 도입을 권장하지만, 구현의 복잡성(Implementation Complexity)과 호환성 문제를 간과할 수 없음을 강조한다. 특히, HTTP/2 및 HTTP/3를 지원하지 않는 클라이언트의 경우, 서버에서 HTTP/1.x를 차단하면 서비스 이용에 제약이 발생할 수 있다. 따라서, HTTP/1.x 차단은 신중하게 고려해야 하며, 426 상태 코드와 같은 적절한 안내를 제공해야 한다.