|Re: [p2-dev] those wacky ntlm proxies|
I think this would be a great idea and would definitely benefit our users.
However, just to be complete, is the Oakland Sofware HTTP client free for non commercial users?
Francis Upton ---09/15/2009 12:50:42 PM---Yes my company, Oakland Software, has for years been selling an HTTP client that is plug compatible with the JRE HTTP Client th
Francis Upton <francisu@xxxxxxxx>
Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>
P2 developer discussions <p2-dev@xxxxxxxxxxx>
09/15/2009 12:50 PM
Re: [p2-dev] those wacky ntlm proxies
Yes my company, Oakland Software, has for years been selling an HTTP client that is plug compatible with the JRE HTTP Client that specifically supports NTLMv2 authentication.
Seems it would be pretty easy to create an ECF provider for that product; we just have not gotten around to it.
On Tue, Sep 15, 2009 at 7:52 AM, Scott Lewis <slewis@xxxxxxxxxxxxxxxxx> wrote:
Pascal Rapicault wrote:
> My understanding from Francis Upton is that the jetty client does not
> support NTLM either, so I don't expect this to be a long-term solution.
> I suggest that we (Pascal and I) engage in discussion with Francis about
> options in this regard (i.e. how to get NTLM support directly in some
> provider(s)). Frankly put, I (Scott) don't have the resources to
> address it further myself.
The only reason why I was suggesting Jetty client was because I thought Francis had said that NTLM v2 support could be added to an http client without infringing copyrights or patents. Therefore I thought that this improvement could be contributed to the Jetty client.
In my conversations with Francis, what became clear is that it would be quite simple for him to create a new provider (not based upon Jetty client, but rather based upon the UrlConnection as I recall) that did not infringe copyrights or patents. I'm willing to support such an effort.
Despite the resources issues, I wonder if we want to go through the pain of changing again http client in this release.
It wouldn't be changing the httpclient provider, but rather simply adding on a new provider...specifically for NTLMv2 users...that would handle many of the edge cases of NTLMv2 proxy configuration, etc. So their is likely not much pain involved (at least for p2) since the existing UrlConnection provider can simply be cloned and modified.
But given the resources issues, as well as no direct access to NTLMv2 networks for me/ECF committers, I won't be able to drive any such effort...or even fully respond to bugs raised WRT proxy-config-specific issues.
p2-dev mailing list