On Wed, May 13, 2009 at 03:18:12PM +0200, Oleg Kalnichevski wrote:
> 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);
And flushing the buffer might also be useful ;-)
con.flush();
Oleg
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]