On Sun, 2007-10-07 at 12:03 +0100, sebb wrote: > On 07/10/2007, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > Folks, > > > > I think we are reasonably close to HttpClient 4.0 ALPHA2 and it is time > > we made some kind of (preliminary) decision on the NTLM authentication > > support in HttpClient 4.x codeline. > > > > I personally have neither capacity nor inclination to set up a Microsoft > > test lab at home with all sorts of Windows versions and Microsoft > > products. I strongly suspect none of the present committers does as > > well. > > > > I long hoped we might find some kind soul willing to contribute an > > AuthScheme based on jCIFS, someone knowledgeable enough about Microsoft > > stuff and motivated enough to not just contribute code but also to stick > > around to maintain and support it. Let's face it, this may take a pretty > > long while, maybe forever. > > > > So, it now all boils down to the following dilemma > > > > (1) Ship HttpClient 4.0 without NTLM support at all, stoically take all > > the whining and b*tching on the user list but give people some incentive > > to scratch their own itch (so to speak). > > > > (2) Port old NTLM code from HttpClient 3.x to give the users at least > > NTLMv1 support but stand the risk this code _may_ be infringing on some > > Microsoft IP. > > > > Thoughts? Alternatives? > > > > Sun Java on Windows supports NTLM since 1.4. > > http://java.sun.com/j2se/1.4.2/changes.html#networking > > So you could just say that the user needs Windows Java for NTLM support. > Since servers using NTLM probably expect that the clients are running > Windows, this is hopefully not a huge restriction ... > > If it is possible to plug-in NTLM auth at run-time, you could provide > the hook for doing so. There seems to be at least one GPL > implementation; this cannot be included with the ASF code, but with a > suitable hook, then users could add it themselves. >
Hi Sebastian, Authentication schemes in HttpClient 3.x and 4.x are fully pluggable. So, one can always plug in a custom AuthScheme implementation, whatever license. The question is whether we should remove an _existing_ piece of functionality solely based on the assumption it _may_ potentially cause legal issues. Oleg > S/// > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
