Hi Ortwin I think you are right.
> 1. First POST request without body. Fine. Connection is keep-alive. > 2. Second POST request with body. Fine, but the connection breaks > prematurely (don't know why). This may be another bug. I often see in the logs "I/O exception" and retry attempt on both HttpPost and HttpGet methods. This seem to be only fatal for HttpPost and InputStreamEntity. > 3. Client detects the faulty connection and retries. > 4. Client sends headers, but can't send the body because the stream has > already been exhausted. > 5. Server looses patience waiting for the missing entity body and throws > HTTP 400. > > When the client retries the entity body stream has already been consumed. > An InputStream can not be reconstructed after is has been read (we don't > buffer). There is no way the request can be retried. > > Actually the client should know that and not retry in this case. Oleg, this > looks like a bug to me. IMHO the InputStream could only be consumed if it is possible to write to the socket. This way even POST with InputStreamEntity could be retried. If you can't eve write HTTP request headers then there is no need to read from the stream. But maybe you can write headers but no body :-o. Best regards -- Martin Zdila CTO M-Way Solutions Slovakia s.r.o. Letna 27, 040 01 Kosice Slovakia tel:+421-908-363-848 mailto:[EMAIL PROTECTED] http://www.mwaysolutions.com xmpp:[EMAIL PROTECTED] (Jabber) skype:m.zdila --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
