On Wed, May 13, 2009 at 03:13:06PM +0200, Alexander M??ller wrote: > >>> 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? > >
Protocol version, for instance. HttpCore uses HTTP/1.1 per default. Oleg > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
