프록시 인증 재시도를 위한 Jersey 2 업로드 버퍼링

인증 협상에서 업로드를 다시 보내야 할 때 Jersey 2 Apache 커넥터 요청 엔티티를 반복 가능하게 만듭니다.

프록시 챌린지 후 재시도되는 업로드는 본문을 다시 필요로 합니다. Jersey 2의 Apache 커넥터에서는 해당 클라이언트를 만드는 데 쓰는 구성에서 버퍼링된 엔티티 처리를 선택합니다:

ClientConfig config = new ClientConfig();
config.connectorProvider(new ApacheConnectorProvider());
config.property(ClientProperties.PROXY_URI,
                "http://proxy.example.net:8080");
config.property(ClientProperties.REQUEST_ENTITY_PROCESSING,
                RequestEntityProcessing.BUFFERED);

생성된 클라이언트로 업로드를 수행합니다. 이 타입들은 Jersey client와 Apache-connector 패키지에서 옵니다. 사용되지 않는 구성을 지정해도 요청에는 영향이 없습니다.

커넥터는 버퍼링된 엔티티를 Apache의 BufferedHttpEntity로 감쌉니다. 버퍼링되지 않은 스트리밍 엔티티는 반복할 수 없습니다. 버퍼링은 이미 소비된 생산자를 다시 읽는 대신 인증 흐름에 다시 보낼 수 있는 바이트를 제공합니다.

인증이 407 한 번으로 끝난다고 보장하지는 않습니다. 일부 방식은 정당하게 여러 번의 교환을 요구하므로, 또 다른 챌린지를 상태 손실로 단정하기 전에 협상 전체를 살펴보십시오.

본문 크기를 메모리 예산 안에 유지하십시오. 큰 스트리밍 업로드에는 그 작업 부하에 맞는 재전송 전략이 필요합니다. 모든 요청에 버퍼링을 켜면 협상 실패를 메모리 고갈과 맞바꿀 수 있습니다.

관련 글