428 Precondition Required (사전 요구 사항)
전제 조건은 클라이언트가 HTTP 요청을 보낼 때 요청이 성공하려면 몇 가지 사전 설정된 조건을 충족해야 한다는 것입니다.
좋은 예는 If-None-Match 헤더로, GET 요청에 자주 사용되며, If-None-Match 가 지정된 경우 클라이언트는 응답의 ETag 가 변경된 후에만 응답을 다시 받습니다.
전제 조건의 또 다른 예는 If-Match 헤더입니다. 이 헤더는 일반적으로 PUT 요청에서 변경되지 않은 리소스만 업데이트됨을 나타내는 데 사용됩니다. 이는 여러 클라이언트가 HTTP 서비스를 사용할 때 서로 동일한 콘텐츠를 덮어쓰지 않도록 하는 데 사용됩니다.
서버측에서 428 Precondition Required 상태 코드를 사용하는 경우 클라이언트가 요청을 실행하기 위해 위의 요청 헤더를 전송해야 한다는 것을 의미합니다. 이 방법은 서버에' lost update' 문제를 방지하는 효과적인 방법을 제공합니다.
429 너무 많은 요청
이 상태 코드는 클라이언트가 요청한 서비스 수를 제한해야 할 때 유용합니다. 즉, 요청 속도 제한입니다.
그 이전에는' 509 bandwidth limit exceded'. Twitter 가 420 (HTTP 정의 상태 코드가 아님)
을 사용하는 것과 같은 유사한 상태 코드가 있었습니다서비스에 대한 클라이언트 요청 수를 제한하려면 429 상태 코드를 사용하고 Retry-After 응답 헤더와 함께 클라이언트에 서비스를 다시 요청할 수 있는 기간을 알려 줍니다.
431 Request Header Fields Too Large (요청 헤더 필드가 너무 큼)
경우에 따라 클라이언트가 HTTP 요청 헤더를 보내면 서버가 431 Request Header Fields Too Large 를 전송하여 문제를 나타낼 수 있습니다.
왜 430 상태 코드가 없는지 잘 모르겠는데, 429 에서 431 로 직접 뛰어내려 봤는데 결과가 없어요. 유일한 추측은 430 Forbidden 이 403 Forbidden 과 너무 비슷하다는 것이다. 혼동을 피하기 위해 이렇게 한 것이다. 신은 알고 있다!
511 네트워크 인증 필요
이 상태 코드는 나에게 매우 흥미 롭습니다. HTTP 서버를 개발하는 경우 상태 코드를 처리 할 필요는 없지만 HTTP 클라이언트를 작성하는 경우이 상태 코드는 매우 중요합니다.
노트북과 스마트폰을 자주 사용한다면, 많은 공용 와이파이 서비스를 사용하려면 몇 가지 프로토콜을 수락하거나 로그인해야 한다는 것을 알 수 있을 것이다. (윌리엄 셰익스피어, 윈도, 스마트폰, 스마트폰, 스마트폰, 스마트폰, 스마트폰, 스마트폰)
이는 HTTP 트래픽을 차단하여 사용자가 네트워크에 액세스하여 리디렉션 및 로그인을 반환하려고 할 때 짜증나지만 실제로는 그렇습니다.
이러한' 차단' 클라이언트를 사용하면 불쾌한 부작용이 생길 수 있다.
이 두 가지 예는 RFC 에서 언급됩니다.
WIFI 에 로그인하기 전에 웹사이트를 방문하면, 인터넷 장치가 첫 번째 요청을 가로채는데, 이들 장치에도 종종 자체 사이트 아이콘' Favicon.ICO' 가 있다. 로그인 후, 잠시 동안 방문한 웹 사이트 아이콘이 WIFI 로그인 웹 사이트의 아이콘임을 알 수 있습니다.
클라이언트가 HTTP 요청을 사용하여 문서 (JSON 일 수 있음) 를 찾는 경우 네트워크는 로그인 페이지에 응답하여 클라이언트가 오류를 해결하고 클라이언트 실행 예외를 발생시킬 수 있도록 합니다. 이러한 문제는 실제로 매우 일반적입니다.
그래서 511 상태 코드의 제안은 이 문제를 해결하기 위한 것이다.