HTTP 100 상태 코드

100(계속) 요청자는 계속 요청해야 합니다. 서버는 이 코드를 반환하여 요청의 첫 번째 부분을 수신했고 나머지 부분을 기다리고 있음을 나타냅니다.

서버는 클라이언트의 요청 헤더를 기반으로 클라이언트의 요청을 수락할지 여부를 결정합니다. 요청이 수락되면 서버는 Expect: 100-continue 요청 헤더가 있는지 여부에 따라 100 상태 코드로 응답합니다(일부 웹 서버는 Expect 요청을 올바르게 처리할 수 없음). 서버가 초기 요청 부분을 수신했음을 나타내고 클라이언트에게 계속 전송하도록 요청합니다. 서버는 100 Continue 상태 코드를 보낸 후 클라이언트로부터 요청을 받으면 응답해야 합니다.

이 상태 코드는 실제로 다음 시나리오에 대한 최적화입니다. 클라이언트에 업로드하고 저장해야 하는 더 큰 파일이 있지만 클라이언트는 서버가 파일을 수락할지 여부를 알지 못하므로 파일을 전송하려고 합니다. 네트워크 리소스를 소비하기 전에 먼저 서버에 원하는 사항을 물어보세요. 실제 작업은 클라이언트가 특별한 요청 메시지를 보내는 것이며 메시지 헤더에는

Expect: 100-continue

가 포함되어야 합니다. 이때 서버가 이를 수락할 의사가 있으면 100 Continue 상태 코드를 반환하고, 그렇지 않으면 417 Expectation Failed 상태 코드를 반환합니다. 클라이언트의 경우, 클라이언트가 실제 요청을 보낼 의도가 없다면 100 Continue Expect가 포함된 메시지를 보내서는 안 됩니다. 이렇게 하면 서버가 클라이언트가 곧 요청을 보내려고 한다고 잘못 생각하게 되기 때문입니다.

앞서 언급했듯이 모든 HTTP 애플리케이션이 100 Continue 상태 코드(예: HTTP/1.0 및 이전 버전의 프록시 또는 서버)를 지원하는 것은 아니므로 클라이언트는 100 Continue Expect 를 보낸 후 서버의 응답을 기다리면 안 됩니다. 특정 기간 동안 클라이언트는 전송 예정인 콘텐츠를 직접 전송해야 합니다.

서버의 경우 100 Continue를 엄밀한 판단 방법으로 여겨서는 안 됩니다. 서버는 응답을 보내기 전에 클라이언트로부터 본문 메시지를 받았을 수 있습니다. 이 시점에서 서버는 더 이상 응답으로 100 Continue를 보낼 필요가 없습니다. 하지만 승인이 완료된 후에도 적절한 상태 코드를 반환해야 합니다. 이론적으로 서버는 100 Continue Expect 요청을 받으면 응답해야 합니다. 그러나 서버는 100 Continue Expect 요청을 보내지 않은 클라이언트에 대한 응답으로 100 Continue 상태 코드를 보내서는 안 됩니다. 여기에 언급된 응답은 다음을 의미합니다. 서버가 클라이언트가 보낼 본문 메시지를 수신할 의도가 없다고 가정할 때 단순히 연결을 닫는 대신 적절한 응답(예: 417 Expectation Failed 전송)도 해야 합니다. 클라이언트에 대한 문제. 네트워크 수준에 영향을 미칩니다.

특히 프록시인 HTTP 애플리케이션은 100 Continue Expect로 요청을 받을 때 추가 판단을 내려야 합니다. 프록시 서버가 메시지의 HTTP 버전 다운스트림이 HTTP/1.1과 호환된다는 것을 분명히 알고 있거나 프록시 서버가 메시지의 다운스트림 버전을 모른다고 가정하면 이 100 Continue Expect 요청을 전달해야 합니다. 그러나 프록시 서버가 메시지의 애플리케이션 다운스트림이 100 Continue Expect를 처리할 수 없다는 것을 분명히 알고 있는 경우 클라이언트에 응답으로 417 Expectation Failed를 직접 반환해야 합니다. 이것이 유일한 해결책은 아닙니다. 또 다른 가능한 방법은 100 Continue를 클라이언트에 직접 반환한 다음 100 Continue Expect가 삭제된 메시지를 다운스트림에 전달하는 것입니다.

또한 프록시 서버가 HTTP/1.0 및 이전 버전을 제공하기로 결정한 경우 서버로부터 100 Continue 응답 메시지를 수신하면 이 응답을 클라이언트에 전달해서는 안 됩니다. 이 메시지를 처리하는 방법을 모르겠습니다.