On Tue, 2009-01-13 at 18:24 -0500, Sam Berlin wrote:
I guess the client can just forcibly call HttpGet.abort() which should
kill the connection. I was wondering if there was a way to do it
without the abort, so the server can know the connection is going to
close. In my ideal world, the exchange would be something like:
--> GET /resource
--> Connection: Keep-Alive
<-- 4xx - Requires Authentication
--> GET /resource
--> Auth-Header: auth-value
--> Connection: Close
<-- 2xx
<-- <resource>
<connection close>
Sorry if this is a bad use-case -- the abort should work just fine.
Sam
Hi Sam
Please note that this approach may not work as desired with pooling
connection managers where the authentication process can take place on
one connection but the subsequent GET /resource may be executed using a
completely different physical connection.
Anyways, you can detect an authentication failure using the following
interceptor and make use of information stored in the execution context
to add "Connection: close" to the subsequent GET request.
Hope this helps
Oleg
----
DefaultHttpClient httpclient = new DefaultHttpClient();
httpclient.addResponseInterceptor(new HttpResponseInterceptor() {
public void process(
final HttpResponse response,
final HttpContext context) throws HttpException, IOException {
AuthState authState = (AuthState) context.getAttribute(
ClientContext.TARGET_AUTH_STATE);
if (authState.isValid()) {
int code = response.getStatusLine().getStatusCode();
if (code == HttpStatus.SC_UNAUTHORIZED) {
context.setAttribute("flag", Boolean.TRUE);
}
}
}
});
HttpContext localContext = new BasicHttpContext();
HttpGet httpget = new HttpGet("http://www.whatever.com/");
HttpResponse response = httpclient.execute(httpget, localContext);
HttpEntity entity = response.getEntity();
System.out.println(response.getStatusLine());
entity.consumeContent();
System.out.println(localContext.getAttribute("flag"));
----
On Tue, Jan 13, 2009 at 5:29 PM, Oleg Kalnichevski <ol...@apache.org
<mailto:ol...@apache.org>> wrote:
> Sam Berlin wrote:
>>
>> Sorry, I had a bit of troubling grasping the question in my head, so
>> it didn't come out too clearly.
>>
>> On the client side, I'd like to send a request that I know will
>> require credentials. So I get the HttpClient's credentialsProvider &
>> set some credentials in it. I'd also like to open a GET request with
>> a 'Connection: Close' header, but I know the GET is going to have the
>> interim credentials exchange.
>>
>> Will the 'Connection: Close' that's added to the outgoing GET cause a
>> server to close the connection before the authentication finishes?
>> (This question is mostly a 'server behavior' question, but I'm not
>> sure what the correct behavior should be.)
>>
>
> I believe so.
>
>> If a properly behaved (or typically behaved) server will close the
>> connection before the auth finishes, then the next question is: How do
>> I add the Connection: Close into the subsequent GET that's performed
>> internally by HttpClient after the auth finishes? What trick would I
>> use in an interceptor in order to get the subsequent GET?
>>
>
> What for do you need that GET? Why do not you just close the connection if
> you do not want to keep it alive?
>
> Am I still missing something?
>
> Can you describe what kind of HTTP messages would you expect HttpClient to
> generate?
>
> Oleg
>
>
>> Thanks!
>>
>> Sam
>>
>>
>>
>> On Tue, Jan 13, 2009 at 2:33 PM, Oleg Kalnichevski <ol...@apache.org
<mailto:ol...@apache.org>>
>> wrote:
>>>
>>> Sam Berlin wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Is there a preferred way of adding a "Connection: Close" header into
>>>> an exchange you expect (and want) to use credentials with? I would
>>>> expect if the initial request had a failure due to unauthorized
>>>> credentials that the Connection: Close would kill the connection
>>>> instead of continuing the exchange of the credentials. If this is the
>>>> case, is there a way to add Connection: Close to the request only
>>>> after credentials are added?
>>>>
>>> Hi Sam
>>>
>>> I am not sure I understand the problem entirely. Are you talking about
>>> client-side or server-side processing? Anyways, a simple protocol
>>> interceptor should do the job quite easily.
>>>
>>> Oleg
>>>
>>>
>>>> Thanks.
>>>>
>>>> Sam
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
<mailto:dev-unsubscr...@hc.apache.org>
>>>> For additional commands, e-mail: dev-h...@hc.apache.org
<mailto:dev-h...@hc.apache.org>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
<mailto:dev-unsubscr...@hc.apache.org>
>>> For additional commands, e-mail: dev-h...@hc.apache.org
<mailto:dev-h...@hc.apache.org>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
<mailto:dev-unsubscr...@hc.apache.org>
>> For additional commands, e-mail: dev-h...@hc.apache.org
<mailto:dev-h...@hc.apache.org>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
<mailto:dev-unsubscr...@hc.apache.org>
> For additional commands, e-mail: dev-h...@hc.apache.org
<mailto:dev-h...@hc.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
<mailto:dev-unsubscr...@hc.apache.org>
For additional commands, e-mail: dev-h...@hc.apache.org
<mailto:dev-h...@hc.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org