Closed afelisatti closed 7 years ago
I guess you're using the Grizzly provider from AHC 1?
Yes, but I suspect this is the same for Netty. Been working on a test case and no provider worked as expected. I'll try adding it if I get the test case to work as expected.
Friendly reminder: AHC1 is EOL'ed, and you MuleSoft people are basically the only ones using the Grizzly provider there.
It's possible that the bug is fixed with AHC2.
Then, honestly, I have a very hard time testing and fixing NTLM support as I don't have a test environment for that. :(
I know, but we'll do our best to provide PRs and tests if necessary. I'll see what I can do here with mock servers, for example. Regarding AHC2, I know it's Netty only right now but can we ever expect a Grizzly side to it? I know that depends on other devs but I'm thinking whether the APIs make that possible or not.
I know, but we'll do our best to provide PRs and tests if necessary. I'll see what I can do here with mock servers, for example.
It would be great, thanks!
Regarding AHC2, I know it's Netty only right now but can we ever expect a Grizzly side to it? I know that depends on other devs but I'm thinking whether the APIs make that possible or not.
I've answered to Ryan on the mailing list on this topic. I think it's a bad idea and a Grizzly based HTTP client would be better as a dedicated project.
Closing, AHC1 is EOL'ed.
We've found that when having a proxy with NTLM authentication the HTTP to HTTP scenario works fine (there are tests for this) but it fails when it's HTTP to HTTPS. From what I could find, it seems that during the CONNECT the auth is not considered because a) it's not preemptive and b) the proxy response does not cause the auth challenge dance to begin.