Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4C87C373.4060200@web.de>
Date: Wed, 08 Sep 2010 19:10:11 +0200
From: Michel Onoff <michel.onoff@web.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: dev@hc.apache.org
Subject: Re: getting the "entity" of a status 304 response
References: <4C86664A.90805@web.de>
 <1283887432.1846.12.camel@ubuntu>	 <4C8759AF.2030102@web.de>
 <1283939400.15185.68.camel@ubuntu>
In-Reply-To: <1283939400.15185.68.camel@ubuntu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: michel.onoff@web.de

On 2010-09-08 11:50, Oleg Kalnichevski wrote:
> On Wed, 2010-09-08 at 11:38 +0200, Michel Onoff wrote:
>> On 2010-09-07 21:23, Oleg Kalnichevski wrote:
>>> On Tue, 2010-09-07 at 18:20 +0200, Michel Onoff wrote:
>>>> By specification, HTTP response 304 Not Modified has no entity.
>>>>
>>>> However, getEntity() on the BasicHttpResponse still returns a non-null
>>>> entity. Trying to getContent() and read() then blocks. The same happens
>>>> if one tries to send the response with
>>>> HttpServerConnection.sendResponseEntity(response).
>>>>
>>>> Is this supposed to be correct behavior? In other words, must the
>>>> programmer be aware of which responses might have an entity? Why can't
>>>> he rely on the return value of getEntity()?
>>>>
>>>
>>> Michel,
>>>
>>> BasicHttpResponse does not have any protocol specific logic. It is
>>> merely a bean with properties. It is the responsibility of the protocol
>>> processor to assign an instance of HttpEntity to the response object if
>>> a response content is expected.
>>>
>>> I am fairly confident the standard HTTP protocol processors handle 304
>>> Not Modified responses correctly
>>>
>>> http://hc.apache.org/httpcomponents-core-4.0.1/httpcore/xref/org/apache/http/protocol/HttpRequestExecutor.html#290
>>> http://hc.apache.org/httpcomponents-core-4.0.1/httpcore/xref/org/apache/http/protocol/HttpRequestExecutor.html#83
>>>
>>> What is it exactly you are trying to do and what module (HttpCore,
>>> HttpCore NIO, HttpClient) are you using?
>>>
>>
>> In fact, I'm using the blocking core directly (http connections,
>> requests, responses, entities and headers), without using protocol-aware
>> processors. The idea is to have as few overhead as possible, given that
>> I'm trying to build a load-balancer which simply forwards requests to
>> available servers and responses back to the originating clients in the
>> right order.
>>
>> I'll have a look at the processors and try to experiment with them to
>> evaluate if performance still remains reasonable.
>>
>> Thanks for the explanation
>> MO
>>
> 
> Michel
> 
> You can certainly continue using your custom protocol handling code, but
> you will have to ensure it is capable of dealing with responses that are
> not meant to enclose a content body (status 304, responses to HEAD, etc)
> 

I took a look at the processor API.

Unfortunately, it doesn't fit in my project. For my usage, I would need
a processor for *incoming* responses: alas, there are no ready-to-use
class for that.

I cannot use HttpRequestExecutor either, because I send a request on a
client connection in one thread and receive the response on the same
connection in another thread (full-duplex usage in different sending and
receiving threads).

So, instead of implementing a processor for incoming responses, it's
easier for me to check the availability of an entity based on the status
code of the response or the type of the originating request.

Cheers
MO

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org