문서 소개:하이퍼링크 로그인이 보입니다.
컬을 통해 상대방 인터페이스에 전화했을 때, 타임아웃 현상이 매우 심각하다는 것을 알게 되었고, 저는 상대방 인터페이스 담당자에게 물었고, 상대방은 추가해야 한다고 했습니다:
추가한 후 정말 잘 작동한다는 것을 알게 되어 사용법을 조사했습니다. POST에 curl을 사용할 때, "POST 데이터가 1024바이트를 초과한다"고 할 때, curl은 POST 요청을 직접 시작하지 않고 두 단계로 나뉩니다:
Expect: 100-continue
1. Expect:100-continue이 포함된 요청을 보내 서버에 데이터를 수락해 달라고 요청합니다
2. 서버로부터 100번 계속(continu) 응답을 받은 후, 데이터는 서버에 POST됩니다
하지만 여기에는 몇 가지 문제가 있습니다:
모든 서버가 100-continue에 올바르게 응답하는 것은 아니며, 예를 들어 lighttpd는 417 Expectation Failed를 반환합니다.
지연을 초래하며,클라이언트가 첫 번째 Expect:100-continue을 보낼 때, 서버가 응답할 때까지 기다려야 합니다.。
상대방 서버가 1024바이트를 초과하는 POST 요청을 거부하지 않을 것이라면, 이 방법을 사용하지 않고 위에서 언급한 두 가지 부작용을 피할 수 있으며, 해결책은 문서 처음에 언급된 것입니다.
약 100명이 계속 진행 중입니다
이 문서의 목적은 다음과 같습니다:
클라이언트는 서버를 보내기 전에 요청 데이터를 받을 의사가 있는지 판단할 수 있으며, 서버가 받을 의사가 있다면 실제로 데이터를 전송합니다.
클라이언트 행동:
100번의 계속을 보내는 클라이언트는 서버로부터 응답을 영원히 기다려서는 안 되며, 일정 타임아웃 후에는 클라이언트가 해당 엔티티를 직접 보내야 합니다.
서버 측 동작:
서버가 100 계속(continu) 요청을 받으면 100 계속(100 continu)로 응답하거나 오류 코드를 보냅니다. 서버는 100 Continue를 보내지 않는 클라이언트에게 100 Continue를 보낼 수 없습니다. 하지만 일부 서버는 그렇습니다. IIS 5가 잘못 100-Continue 응답을 전송함
서버가 100 계속응답을 보내기 전에 클라이언트의 본문을 받는다면, 이는 클라이언트가 데이터를 전송하기 시작하기로 결정했으므로 더 이상 클라이언트에게 100 continu를 보낼 수 없다는 의미입니다.
.NET Expect Off Expect 설정 코드는 다음과 같습니다:
RestSharp는 다음과 같이 구성되어 있습니다:
|
2021-4-22 15:32:09에 게시됨
|
|
|
집주인