[
https://issues.apache.org/jira/browse/HTTPASYNC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPASYNC-143.
-----------------------------------------
Resolution: Invalid
[[email protected]] I cannot confirm this issue as a defect in
HttpAsyncClient code.
NTLM authentication is stateful and requires connections to be persistent in
order to work. What I see that the connection gets terminated in the middle of
NTLM handshake. It took me a while to figure what was causing the connection to
get dropped in the middle of the NTLM handshake.
Here is the short story: Microsoft does not follow its own bloody protocol.
Here is the long story: Please take a look at this two snippets. They are
essential to understanding of the problem. In one case the server sends back
401 status out of sequence while the client is still sending the request body.
In the second case the server responds with 401 correctly when the client is
done with sending the request body.
{noformat}
http-outgoing-2 [ACTIVE] Output ready
http-outgoing-2 [ACTIVE] [content length: 52984; pos: 49152; completed: false]
http-outgoing-2
xxx.xxx.xx.xxx:58680<->xxx.xxx.xx.xxx:443[ACTIVE][rw:w][ACTIVE][rw][NOT_HANDSHAKING][0][0][4125]:
4096 bytes written
http-outgoing-2
xxx.xxx.xx.xxx:58680<->xxx.xxx.xx.xxx:443[ACTIVE][rw:rw][ACTIVE][rw][NOT_HANDSHAKING][0][0][0]:
798 bytes read
http-outgoing-2 << HTTP/1.1 401 Unauthorized
...
http-outgoing-2
xxx.xxx.xx.xxx:58680<->xxx.xxx.xx.xxx:443[ACTIVE][r:rw][ACTIVE][r][NOT_HANDSHAKING][0][0][0]:
Close
{noformat}
{noformat}
http-outgoing-2 [ACTIVE] Output ready
http-outgoing-2 [ACTIVE] [content length: 52984; pos: 52984; completed: true]
http-outgoing-2
xxx.xxx.xx.xxx:58934<->xxx.xxx.xx.xxx:443[ACTIVE][rw:w][ACTIVE][rw][NOT_HANDSHAKING][0][0][3861]:
3832 bytes written
http-outgoing-2 [ACTIVE] Request ready
http-outgoing-2
xxx.xxx.xx.xxx:58934<->xxx.xxx.xx.xxx:443[ACTIVE][r:w][ACTIVE][r][NOT_HANDSHAKING][0][0][0]:
Event cleared [w]
http-outgoing-2
xxx.xxx.xx.xxx:58934<->xxx.xxx.xx.xxx:443[ACTIVE][r:r][ACTIVE][r][NOT_HANDSHAKING][0][0][0]:
798 bytes read
http-outgoing-2 << HTTP/1.1 401 Unauthorized
{noformat}
The client upon receipt of an out of sequence response assumes the server is no
longer interested in continuing the session, stops sending request data,
processes the response and closes the connection as non-reusable.
To work the problem around I very strong recommend always using a cheap GET,
HEAD, OPTIONS request in force NTLM handshake prior to sending any entity
enclosing request over an NTLM protected connection.
Oleg
> Connection closed randomly during NTLM authorization
> ----------------------------------------------------
>
> Key: HTTPASYNC-143
> URL: https://issues.apache.org/jira/browse/HTTPASYNC-143
> Project: HttpComponents HttpAsyncClient
> Issue Type: Bug
> Affects Versions: 4.1.4
> Reporter: Isa Muqattash
> Priority: Major
> Attachments: asyncHttpClient_failed.log, asyncHttpClient_success.log
>
>
> Recently switched from the (synchronous) HttpClient to HttpAsyncClient, and
> I'm dealing with a HTTP 401 error returned from an HTTP POST that involves
> NTLM authentication.
> The issue sporadically occurs, more frequently with HttpAsyncClient 4.1.3,
> and still occurs in 4.1.4 but less frequently.
> The HTTP POST request incorrectly includes a "Content-Type:
> Application/JSON" header and the body is a ZIP file binary, and removing that
> header seems to make the issue go away, or at least I cannot reproduce the
> random behavior when the head is not specified. However, all this worked fine
> with the synchronous HttpClient and it will be difficult to go to many many
> applications and remove that additional header, which I'm not sure why it
> would cause this issue described here.
> I enabled context and wire logs, and what I'm seeing is that the three-step
> NTLM handshake takes place. When the issue does not reproduce, all three
> steps occur on the same connection. But when the issue reproduces, the
> context and wire logs show that the connection is closed between each of the
> three steps.
> Furthermore, I looked into this for several days and the issue reproduces
> more frequently with some zip binaries rather than other. The same zip file
> sometimes succeeds but other times fails.
> Perhaps there is some JSON parsing taking place that randomly causes issues
> and causes the connection to be closed? (I'm just rambling now but just
> trying to give as much info as possible...)
> Sample success and failure handshake logs attached.
> Source code I'm using is as follows (stripped down):
>
> {code:java}
> val httpclientB = HttpAsyncClients.custom().setRedirectStrategy(new
> LaxRedirectStrategy() {
> override def createLocationURI(location: String): URI = {
> super.createLocationURI(location)
> }
> override def isRedirected(req: HttpRequest, resp: HttpResponse, ctxt:
> HttpContext): Boolean = {
> super.isRedirected(req, resp, ctxt)
> }
> override def getRedirect(req: HttpRequest, resp: HttpResponse, ctxt:
> HttpContext): HttpUriRequest = {
> val x = super.getRedirect(req, resp, ctxt)
> if (x.containsHeader("Content-Length")) {
> x.removeHeaders("Content-Length")
> }
> x
> }
> })
> val credsProvider = new BasicCredentialsProvider()
> credsProvider.setCredentials(AuthScope.ANY, new NTCredentials("foo", "bar",
> "baz", "domain"))
> httpclientB.setDefaultCredentialsProvider(credsProvider)
> val httpClient = httpclientB.useSystemProperties().build()
> httpClient.start()
> val future = httpClient.execute(httpRequest, null)
> future.get(Long.MaxValue, TimeUnit.MILLISECONDS))
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
