Mettre en tampon un envoi Jersey 2 pour les nouvelles tentatives d'authentification par proxy

Rendez réutilisable l'entité de requête Jersey 2 avec le connecteur Apache lorsque la négociation d'authentification doit renvoyer l'envoi.

Un envoi retenté après un défi du proxy a de nouveau besoin de son corps. Pour le connecteur Apache de Jersey 2, sélectionnez le traitement d'entité mis en tampon dans la configuration servant à construire ce client :

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);

Effectuez l'envoi via le client obtenu. Ces types proviennent des paquets Jersey client et Apache-connector ; définir une configuration inutilisée n'aurait aucun effet sur la requête.

Le connecteur enveloppe une entité mise en tampon dans le BufferedHttpEntity d'Apache. Son entité de flux non tamponnée n'est pas réutilisable. La mise en tampon fournit au flux d'authentification des octets qu'il peut renvoyer au lieu de relire un producteur déjà consommé.

Cela ne garantit pas que l'authentification se termine après un seul 407. Certains schémas exigent légitimement plusieurs échanges ; examinez donc toute la négociation avant de considérer un nouveau défi comme un état perdu.

Gardez la taille du corps dans le budget mémoire. Un envoi en flux volumineux a besoin d'une stratégie de rejeu adaptée à cette charge ; activer la mise en tampon pour chaque requête peut échanger un échec de négociation contre un épuisement de mémoire.

Articles similaires