Closed arinban closed 7 years ago
@glassfishrobot Commented Reported by facundovs
@glassfishrobot Commented This issue was imported from java.net JIRA GRIZZLY-1899
@rlubke Commented Closing this out. Opened https://github.com/javaee/grizzly-ahc/issues/1 on the AHC issue tracker.
Hello,
I have found a problem in AsyncHttpClient:
I'm creating a HttpRequest with the following configuration in the authentication:
Realm.RealmBuilder realmBuilder = new Realm.RealmBuilder() .setPrincipal(authentication.getUsername()) .setPassword(authentication.getPassword()) .setUsePreemptiveAuth(false);
As you can see preemptiveAuth is set to false. In this case, the requestTimeOut is not honored.
I was debugging the application and I can see in com.ning.http.client.providers.grizzly.AsyncHttpClientFilter.sendRequest(), line 279, the following line:
ctx.write(requestPacket, ctx.getTransportContext().getCompletionHandler());
which is executed twice, according to the non-preemptive definition. After I can see in the execution flow in com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider.initializeTransport(), line 263 the following fragment:
final HttpTransactionContext context = HttpTransactionContext.currentTransaction(connection); if (context != null) { if (context.isWSRequest)
{ return clientConfig.getWebSocketTimeout(); }
final long timeout = context.getAhcRequest().getRequestTimeout(); if (timeout > 0)
{ return timeout; }
} return timeout; when the first request is processed, context!=null condition is true so It returns the requestTimeOut set in the request.
However when the second request is processed (the request that contains the authorization header), context is null, so it returns the timeout of the AsyncHtttpClientConfig, that is 60 seconds by default, ignoring the timeout set in the request.
I think It's a bug. Could you confirm it? In this case, I could create a JIRA to report it.
In addition, what would be the expected behaviour when non-preemptive authorization is used? As two requests are implicitily executed, would the final request timeout be equal to configured two timeouts?
P.D.: I have sent this doubt to grizzly user list, but I haven't been accepted yet and I haven't received replies, so I don't know if the List's active.
Thanks and Cheers
Affected Versions
[2.3.29]