Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: AW: AW: AW: Problems with stale connection check and expect
 100-continue
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
In-Reply-To: 
 <653C8E101491144F9B644FFA6652F5E5060718FC@gtlbmlexs0006.bagmail.net>
References: 
	 <653C8E101491144F9B644FFA6652F5E50382E9D7@gtlbmlexs0006.bagmail.net>
	 <1306228310.1898.22.camel@ubuntu>
	 <653C8E101491144F9B644FFA6652F5E50382E9D8@gtlbmlexs0006.bagmail.net>
	 <653C8E101491144F9B644FFA6652F5E5060718F6@gtlbmlexs0006.bagmail.net>
	 <1306235753.1898.40.camel@ubuntu>
	 <653C8E101491144F9B644FFA6652F5E5060718F7@gtlbmlexs0006.bagmail.net>
	 <1306265568.12638.136.camel@ubuntu>
	 <653C8E101491144F9B644FFA6652F5E5060718FC@gtlbmlexs0006.bagmail.net>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 25 May 2011 13:01:03 +0200
Message-ID: <1306321263.1898.66.camel@ubuntu>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

On Wed, 2011-05-25 at 11:51 +0200, daniel.stucky@attensity.com wrote:
> Hi,
> 
> did some more debugging on HttpClient level:
> 
> 1) one thing I was not aware of is that 100-continue does not raise an exception if it does not get response from the server within the configured timeout but just sends the body. So this works as designed, I just had a different (in this case wrong) expectation.
> 
> 
> 2) The question still is why is no exception raised when the header is written to the connection in org.apache.http.protocol.HttpRequestExecutor#doSendRequest(...) but when the body is written?
> For 100-continue the code does execute
> 	conn.sendRequestHeader(request);
> 	...
> 	conn.flush();
> 	...
> 	conn.sendRequestEntity((HttpEntityEnclosingRequest) request);
> 
> After several indirections the flush() call ends at java.net.SocketOutputStream which does not override the flush() of it's superclasses, which is in fact an empty implementation. So is the header probably buffered and not actually sent? 

No-op flush() method in SocketOutputStream is perfectly fine, as there
is nothing to flush in the first place. SocketOutputStream does not
buffer any data. 


> If 100-continue is used the header must be sent directly so that a server may respond (remember may server is down an of course cannot respond, I would like to have an exception)
> 

Judging by the wireshark trace you had posted yesterday, the RST packet
was sent _after_ the request head was written out. The client's behavior
is perfectly reasonable. It transmits the request head containing the
except header to the server and goes into read operation expecting a
response of some sort. Naturally, there is no response. The client
resumes sending the request body after a timeout as requires by the HTTP
specification. Boom. SocketException is thrown.

The real question is why on earth the RST packet did not cause the read
operation to unblock and throw an exception. I cannot answer that
question. Maybe this is the expected behavior, maybe it is a bug in JRE.
I cannot say. Trying upgrading your JRE.

Oleg


> What are the differences of the requestWriter and the entityserializer used in org.apache.http.impl.AbstractHttpClientConnection ?
> 

RequestWriter is meant to write out request heads, EntitySerializer is
meant to write out request bodies.

Hope this helps

Oleg

> Thanks for your help,
> Daniel
> 
> -----Ursprüngliche Nachricht-----
> Von: Oleg Kalnichevski [mailto:olegk@apache.org] 
> Gesendet: Dienstag, 24. Mai 2011 21:33
> An: HttpClient User Discussion
> Betreff: Re: AW: AW: Problems with stale connection check and expect 100-continue
> 
> On Tue, 2011-05-24 at 18:44 +0200, daniel.stucky@attensity.com wrote:
> > Hi Oleg,
> > 
> > I used Wireshark to get some additional information. This is the 100-continue request and the response from the socket/OS.
> > 
> > 160	1.629973	127.0.1.1	127.0.1.1	TCP	47837 > 8030 [PSH, ACK] Seq=132 Ack=94 Win=273 Len=224 TSV=2404596 TSER=2404594
> > 
> > 0000   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00  ..............E.
> > 0010   01 14 f9 aa 40 00 40 06 40 37 7f 00 01 01 7f 00  ....@.@.@7......
> > 0020   01 01 ba dd 1f 5e db e0 45 90 dc 88 33 67 80 18  .....^..E...3g..
> > 0030   01 11 01 09 00 00 01 01 08 0a 00 24 b0 f4 00 24  ...........$...$
> > 0040   b0 f2 50 55 54 20 2f 72 65 70 6c 69 63 61 74 65  ..PUT /replicate
> > 0050   64 73 74 6f 72 65 2f 6f 62 6a 31 3f 74 6f 6b 65  dstore/obj1?toke
> > 0060   6e 3d 39 34 65 62 64 33 62 33 2d 32 61 36 66 2d  n=94ebd3b3-2a6f-
> > 0070   34 34 34 31 2d 39 65 38 39 2d 36 63 66 66 33 39  4441-9e89-6cff39
> > 0080   66 34 32 64 37 31 20 48 54 54 50 2f 31 2e 31 0d  f42d71 HTTP/1.1.
> > 0090   0a 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69  .Transfer-Encodi
> > 00a0   6e 67 3a 20 63 68 75 6e 6b 65 64 0d 0a 48 6f 73  ng: chunked..Hos
> > 00b0   74 3a 20 70 63 2d 30 32 31 2d 6c 6e 78 3a 38 30  t: pc-021-lnx:80
> > 00c0   33 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20  30..Connection: 
> > 00d0   4b 65 65 70 2d 41 6c 69 76 65 0d 0a 55 73 65 72  Keep-Alive..User
> > 00e0   2d 41 67 65 6e 74 3a 20 41 70 61 63 68 65 2d 48  -Agent: Apache-H
> > 00f0   74 74 70 43 6c 69 65 6e 74 2f 34 2e 31 20 28 6a  ttpClient/4.1 (j
> > 0100   61 76 61 20 31 2e 35 29 0d 0a 45 78 70 65 63 74  ava 1.5)..Expect
> > 0110   3a 20 31 30 30 2d 63 6f 6e 74 69 6e 75 65 0d 0a  : 100-continue..
> > 0120   0d 0a                                            ..
> > 
> > 
> > 
> > 161	1.630008	127.0.1.1	127.0.1.1	TCP	8030 > 47837 [RST] Seq=94 Win=0 Len=0
> > Expert Info (Chat/Sequence): Connection reset (RST)
> > 0000   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00  ..............E.
> > 0010   00 28 00 00 40 00 40 06 3a ce 7f 00 01 01 7f 00  .(..@.@.:.......
> > 0020   01 01 1f 5e ba dd dc 88 33 67 00 00 00 00 50 04  ...^....3g....P.
> > 0030   00 00 c5 b2 00 00    
> > 
> > 
> > It seems that the connection is reset but this is not recognized by HttpClient when doing 100-continue.
> > 
> 
> RST is a TCP level event that is meant to be handled by JRE. HttpClient
> has no control over TCP level events. It can only interact with the
> underlying networking stack though the Socket API and react to
> SocketExceptions in case of abnormal situations. If you see anything
> with the way HttpClient deals with Sockets and SocketExceptions, feel
> free to raise an issue in JIRA.
> 
> Oleg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org