425 Too Early

사용법

425 Too Early 오류는 HTTPS 연결을 수립하는 데 걸리는 시간과 관련이 있습니다. 지연 시간이 큰 환경에서는 TLS가 보안 연결을 만드는 데 걸리는 시간이 길어집니다. 한 가지 최적화는 클라이언트가 보안 연결이 완전히 수립되기 전에 과정 초반에 데이터를 보내는 것입니다.

연결 경로에 중계자가 있다면 그 중계자는 Early-Data: 1 요청 헤더를 포함해야 합니다. 중계자는 이 헤더를 제거해서는 안 됩니다. 이 헤더는 그 요청이 조기 데이터로 전송되었으며 클라이언트가 425 Too Early 응답을 이해한다는 사실을 서버에 알립니다.

요청

GET /tech-news HTTP/1.1
Host: example.com
Early-Data: 1

요청을 최초로 시작한 쪽은 이 헤더를 보낼 필요가 없습니다. 데이터를 조기에 보냄으로써 클라이언트는 그 결과를 이해하고 있으며 425 Too Early 응답을 적절히 처리한다는 것을 암묵적으로 나타냅니다.

특정 상황에서는 조기 데이터를 보내는 것이 바람직하지 않으며, 서버는 그에 대한 응답으로 이 오류를 반환합니다. 위험은 클라이언트 요청이 재생되어 보안을 훼손하는 부수 효과로 이어질 수 있다는 점입니다.

클라이언트가 이 상태 코드를 받으면 요청은 자동으로 재시도됩니다. 핸드셰이크가 완료되고 보안 연결이 수립된 뒤에 말입니다.

SEO 영향

Google 같은 검색 엔진은 425 응답 상태를 가진 URL을 색인하지 않습니다. 이전에 색인되었다가 이 상태 코드를 반환하는 URL은 검색 결과에서 제거됩니다.

예시

클라이언트가 리소스를 요청하고, 서버는 425 Too Early로 응답하여 연결이 완전히 수립될 때까지 기다렸다가 재시도하라고 지시합니다.

요청

GET /tech-news HTTP/1.1
Host: example.com
Content-Type: application/xml
Content-Length: 225

<Message includes early data>

응답

HTTP/1.1 425 Too Early

해결 방법

TLS 핸드셰이크가 완전히 끝난 뒤에 요청을 재시도하세요. 클라이언트는 보안 연결이 완료되기를 기다렸다가 다시 보냅니다. 대부분의 브라우저와 HTTP 라이브러리가 이 재시도를 자동으로 처리합니다.

멱등하지 않은 요청(POST, PUT, DELETE 등)을 TLS 0-RTT 조기 데이터로 보내지 마세요. 재생해도 부수 효과가 없는 멱등한 GET 요청만 조기 데이터로 안전합니다.

nginx의 서버 측에서는 ssl_early_data 지시문이 0-RTT 동작을 제어합니다. ssl_early_data off;로 설정하면 모든 조기 데이터를 거부하여 이 응답을 완전히 없앨 수 있습니다. 0-RTT를 켤 때는 proxy_set_header Early-Data $ssl_early_data;로 조기 데이터 신호를 백엔드에 전달해, 애플리케이션이 요청별로 조기 데이터를 받아들일지 거부할지 판단하게 하세요.

Early-Data: 1 헤더를 받은 백엔드 애플리케이션은 부수 효과가 있는 요청(계정 변경, 결제, 폼 제출)을 425로 응답해 거부합니다. 안전한 읽기 전용 엔드포인트는 평소대로 진행합니다.

클라이언트의 조기 데이터를 전달하는 중계자는 Early-Data: 1 헤더를 보존해야 합니다. 이 헤더를 제거하면 오리진 서버가 재생 위험을 감지할 수 없게 됩니다.

코드 참고

.NET

HttpStatusCode.TooEarly

Rust

http::StatusCode::TOO_EARLY

Rails

:too_early

http.StatusTooEarly

Symfony

Response::HTTP_TOO_EARLY

Python3.9+

http.HTTPStatus.TOO_EARLY

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_TOO_EARLY

Angular

@angular/common/http/HttpStatusCode.TooEarly