Right, and to get Axis to use the custom HttpClient, presumably I will need to do steps 1 and 2 below, given that otherwise, HTTPSenderImpl just does a new DefaultHttpClient()? Or is there a more polite way to hook in a customized client?
Nick On Mon, May 1, 2017 at 11:32 AM, Jeff Greif <jgr...@alumni.princeton.edu> wrote: > Retries and proxy: HttpClients.custom().setRetryHandler(), setProxy(). > You can specify a limit on the number of retries, depending on your > implementation of the handler. > > Try checking HttpContext for some of the others. > > Also, you might be able to disable chunked encoding via headers on the > request. > > On Mon, May 1, 2017 at 10:14 AM, Nick Johnson <n...@bluejeansnet.com> > wrote: > >> With earlier versions of Axis that used Commons-Httpclient, much >> configuration was possible through setting options, but I notice on >> perusing the source, that many of the options we used to use are not >> available for use with HttpClient 4.x, I'm sure in part because HC does a >> lot of things differently. >> >> Is the way to handle client customizations now to: >> >> 1. Extend HTTPSenderImpl and implement a getHttpClient which calls >> super() and then performs client customizations >> 2. Extend HTTPClient4TransportSender to provide the custom >> HTTPSenderImpl in createHTTPSender() >> >> Specifically I need to: >> >> * Disable chunked coding (formerly HTTPConstants.CHUNKED) >> * Disable retries (formerly via HTTPConstants.HTTP_METHOD_PARAMS) >> * Configure a custom SSL context to possibly allow self-signed SSL >> certificates (using our own TrustVerifier) (formerly via >> HTTPConstants.CUSTOM_PROTOCOL_HANDLER) >> * Use a custom Authenticator to support both NTLM and Basic >> * Possibly configure a proxy server >> >> We used to achieve all of these settings via setting options using >> HTTPConstants, but it looks like support only exists now for the >> Authenticator and Proxy server settings, unless things have moved or gotten >> implemented in a different way. >> >> I'm not averse to extending HttpSenderImpl and >> HTTPClient4TransportSender, but if there's a bitter / more elegant way, I'd >> rather use it. >> >> Any advice? >> >> Nick >> > >
