You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Michel Onoff <mi...@web.de> on 2010/09/07 18:20:26 UTC
getting the "entity" of a status 304 response
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()?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: getting the "entity" of a status 304 response
Posted by Michel Onoff <mi...@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
Re: getting the "entity" of a status 304 response
Posted by Oleg Kalnichevski <ol...@apache.org>.
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)
Hope this helps
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: getting the "entity" of a status 304 response
Posted by Michel Onoff <mi...@web.de>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: getting the "entity" of a status 304 response
Posted by Oleg Kalnichevski <ol...@apache.org>.
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?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org