On Tue, 2013-04-23 at 14:17 +0200, Francois-Xavier Bonnet wrote:
> Hi,
> 
> You should fix the client that sends this request. An incorrect
> content-length header value makes it impossible to reuse http connections
> and can lead to locked connections and timeouts for example.
> 
> In your case, I think disabling connection keep-alive could be a quick fix
> but this is not very good for performance.
> 

Another option would be to provide a more lenient message parser that
can silently skip empty lines preceding a valid request line. 

Oleg

> 
> 2013/4/23 Nir Dweck <[email protected]>
> 
> > Hi,
> > I have a question which involves both the code and the validity of an HTTP
> > message.
> > I am using httpcore-4.2.3.
> > I receive from a client an HTTP (HTTP/1.1) request with the following
> > headers:
> > Content-type: text/xml
> > Host: some host
> > User-agent: UA
> > Connection: keep-alive
> > Accept: text/xml
> > Content-Length: 109
> >
> > The entity is a an xml of of length of 109 bytes.
> > At the end of the xml there are two extra bytes with the value of 0x0d and
> > 0xoa (/r/n), these bytes are the 110'th and 111'th bytes.
> > In my code I call: *EntityUtils.toString(entity, "UTF-8");*
> > at the end of the handling of the request my server returns 200-OK to the
> > client.
> > the problem is that after I finish handling the request, the connection is
> > still open and I call *httpService.handleRequest(conn, context);*
> > This call sees the two extra bytes and returns 400-Bad request to the
> > sender.
> > Now my question are:
> >
> >    1. As far as I know when the Content-Length header is present
> >    it determines the length  of the entity body, so actually the message I
> > get
> >    is a bad message.
> >    2. Is there something I can do in my code to make it accept this
> >    message? Will calling *EntityUtils.consume(entity)* help?
> >
> > Thanks,
> > Nir
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to