>>> On 13.05.2009 at 14:50, in message
>>> <[email protected]>, Oleg Kalnichevski
>>> <[email protected]> wrote:
>
> 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.
I am using a GET request, so there are no such headers. Basically I am getting
the same result with this code
HttpRequest req=new BasicHttpRequest("GET", "/");
Socket socket=new Socket("localhost", 80);
DefaultHttpClientConnection con=new DefaultHttpClientConnection();
con.bind(socket, new BasicHttpParams());
con.sendRequestHeader(req);
con.receiveResponseHeader();
Once I replace sendRequestHeader() with
socket.getOutputStream().write("GET / HTTP/1.0\r\n\r\n".getBytes());
it works.
So what could be missing?
>
> 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/protoc
> ol/HttpRequestExecutor.html
>
> What is the reason for your unwillingness to use HttpRequestExecutor?
What would be the advantage of it over sendRequestHeader() and
receiveResponseHeader(), in particular with a Reverse Proxy where one basically
only tunnels through status codes?
Apart from context parameters the sending processe seems to be rather similar,
I might debug it through the receiving to see what might differs.
Thanks again Oleg,
Alexander
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
