On Wed, May 13, 2009 at 02:35:28PM +0200, Alexander M??ller wrote: > >>> On 13.05.2009 at 14:10, in message > >>> <[email protected]>, > > > > Hi Alexander > > > > This is approach is obviously wrong because it does not take into account so > > called hop-by-hop headers. Proxies should not blindly copy all request > > headers > > of the incoming request to the outgoing request. This can lead to incorrect > > delimitation of the message content body. > > > > Please refer to the sample reverse proxy shipped with HttpCore for an > > example > > of hop-by-hop header handling. > > > > http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore/src/e > > > > xamples/org/apache/http/examples/ElementalReverseProxy.java > > > > Let me know if that resolves the issue for you. > > > > Oleg > > > Hello Oleg, > > thanks for the quick reply. I am aware of the hop-by-hop headers and even > though I am not yet taking - fully - care of them in the original code (the > one I posted was slightly trimmed down) I wouldnt suspect them to be the > problem as my test only involved a simple GET, where only the typical > user-agent, accept, .... headers are forwarded. Furthermore the problem also > occurs without forwarding any headers. > > As I previously mentioned I could successfully receive the response headers > by manually sending the request (via the socket) so I suppose I missed > something at the sending part. > > Thanks for the example code, as far as I can see it also uses a > HttpRequestExecutor, which worked for me as well, however I would assume the > code without a HttpRequestExecutor should work as well, shouldnt it? What > would the HttpRequestExecutor exactly do in addition? >
Most likely the AbstractSessionInputBuffer#fillBuffer() blocks because the server is expecting more input and therefore not sending any response back. This is the reason why I suspected either Content-Length or Transfer-Encoding request headers to be wrong due to incorrect handling of the hop-by-hop headers. There is no black magic inside HttpRequestExecutor. It merely implements client-side HTTP protocol handling logic on top of the basic HttpClientConnection transport. See for yourself: http://hc.apache.org/httpcomponents-core/httpcore/xref/org/apache/http/protocol/HttpRequestExecutor.html What is the reason for your unwillingness to use HttpRequestExecutor? Oleg > Thanks again, > Alexander > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
