프록시 인증 재시도와 재전송할 수 없는 업로드 본문

GET은 프록시를 통해 인증될 수 있지만 POST나 PUT은 재전송할 수 없는 본문 또는 되감기 오류로 실패할 수 있습니다. 계정은 올바를 수 있습니다. 클라이언트가 이미 업로드를 소비한 뒤에도 인증 교환이 또 다른 요청을 요구할 수 있기 때문입니다.

libcurl은 다중 패스 인증을 포함한 용도를 위한 탐색 콜백을 문서화합니다. Jersey는 커넥터 동작에 따라 버퍼링 및 분할 엔터티 처리 모드를 제공합니다. Jersey 2 Apache 커넥터 예제 는 버퍼링 설정을 보여줍니다. 어느 것도 무제한 인메모리 업로드를 적절하게 만들지 않습니다.

실패하는 메서드와 본문 원본을 재현하세요. 준비용 GET에는 재전송할 업로드가 없으며, 이후 업로드가 같은 연결이나 인증 상태를 공유한다는 것을 증명하지도 않습니다. 새 대상, 클라이언트 객체 또는 연결 정책이 이를 바꿀 수 있습니다. 파일 기반 본문과 라이브 스트림은 샘플 텍스트가 같더라도 다릅니다.

버퍼링한다면 크기 한도, 저장 위치, 수명을 정의하세요. 동시 업로드는 비용을 배로 늘리고, 민감한 데이터는 버퍼가 보관되는 곳에 남습니다.

알려진 호환 프록시에 대한 사전 인증 은 최초의 챌린지 하나를 피할 수 있습니다. 그러나 다른 시도가 필요할 수 있는 이후의 모든 인증 라운드, 리디렉션 또는 닫힌 연결을 배제할 수는 없습니다.

프록시 응답, 본문 소비 지점, 재전송 오류를 함께 보관하세요. 그런 다음 프로토콜 재전송과 불확실한 애플리케이션 결과를 구분하세요. 응답이 유실되기 전에 제출이 처리되었을 수 있습니다. 다시 보내기 전에 대상의 멱등성 규칙을 따르세요.