ECF Filetransfer Support for NTLMv2 Proxies
Like other parts of ECF, the filetransfer API has a provider architecture, allowing multiple implementations to be used for filetransfer (i.e. via http, ftp, and others). In ECF 3.0/Eclipse 3.5 the primary provider is based upon Apache httpclient 3.1. This was introduced in the ECF 3.0/Eclipse 3.5 cycle because the previous provider that was based upon the JRE URLConnection implementation proved insufficiently reliable (i.e. see bug 166179).
Unfortunately, the Apache httpclient implementation, although more robust than the URLConnection-based provider, does not support NTLMv2 proxies directly (for an explanation of why, see here).
For NTLMv2 Proxies, that require username and password for access the workaround is to
- Disable the ECF httpclient provider.
- Provide the NTLMv2 proxy authentication info (domain, username, and password)
In ECF 3.0 both 1 and two can be done via *system properties*. Here is an example using 'myproxy', 'mydomain', 'myusername', and 'mypassword':
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient\ -Dhttp.proxyPort=8080 -Dhttp.proxyHost=myproxy -Dhttp.proxyUser=mydomain\myusername -Dhttp.proxyPassword=mypassword -Dhttp.nonProxyHosts=localhost|127.0.0.1
The first property disables the httpclient provider (and so uses the URLConnection-based provider, which does have support for NTLMv2 proxies), and the next 5 properties are as specified by Sun for the URLConnection-based provider.
In the future, it is likely that with other providers (e.g. the Apache httpcore client...i.e. bug 251740 or Jetty's asynch filetransfer implementation we will be able to support NTLMv2 proxies...i.e. bug 252002 more directly. Further, in future versions the Eclipse platform proxy API should support NTLMv2 as well...i.e. bug 269832.