From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: An http session that ends with a TCP Reset sent by the server Date: Fri, 14 Jun 2013 12:21:44 -0400 Message-ID: <87zjusd5nr.fsf@tines.lan> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1371226950 19292 80.91.229.3 (14 Jun 2013 16:22:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Jun 2013 16:22:30 +0000 (UTC) Cc: guile-user@gnu.org To: Darren Hoo Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jun 14 18:22:28 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UnWle-0001RS-G0 for guile-user@m.gmane.org; Fri, 14 Jun 2013 18:22:26 +0200 Original-Received: from localhost ([::1]:57372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnWle-0008Rg-2p for guile-user@m.gmane.org; Fri, 14 Jun 2013 12:22:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnWlR-0008H1-8E for guile-user@gnu.org; Fri, 14 Jun 2013 12:22:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UnWlP-0003sA-TK for guile-user@gnu.org; Fri, 14 Jun 2013 12:22:13 -0400 Original-Received: from world.peace.net ([96.39.62.75]:59665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnWlP-0003p4-P5 for guile-user@gnu.org; Fri, 14 Jun 2013 12:22:11 -0400 Original-Received: from 209-6-92-20.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.92.20] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UnWl7-0005nY-1X; Fri, 14 Jun 2013 12:21:53 -0400 In-Reply-To: (Darren Hoo's message of "Thu, 13 Jun 2013 16:33:49 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10439 Archived-At: Hi, Darren Hoo writes: > I use the web client module to access a web service as what follows=20 > > scheme@(guile-user)> (use-modules (web client)) > scheme@(guile-user)> (http-get "http://172.18.23.123/") > ERROR: In procedure get-bytevector-n!: > ERROR: In procedure fport_fill_input: Connection reset by peer > > Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. > scheme@(guile-user) [1]> ,bt > In web/client.scm: > 230:12 4 (request "http://172.18.23.123/" #:body #f #:port # #:method "GET" #:version (1 . 1) #:keep-alive? #f #:header= s () #:decode-body? #t # #f # #) > In web/response.scm: > 310:2 3 (read-response-body #< version: (1 . 1) code: 200 = reason-phrase: "OK" headers: ((cache-control no-cache) (connection close) (= content-type text/html) (cont=E2=80=A6>) > In unknown file: > 2 (get-bytevector-all #) > In web/response.scm: > 249:4 1 (read! #vu8(60 104 116 109 108 62 13 10 60 104 101 97 100 62= 13 10 60 115 99 114 105 112 116 32 116 121 112 101 61 34 116 101 120 116 4= 7 106 97 118 97 115 99 114 =E2=80=A6) =E2=80=A6) > In unknown file: > 0 (get-bytevector-n! # #vu8(60 104 11= 6 109 108 62 13 10 60 104 101 97 100 62 13 10 60 115 99 114 105 112 116 32 = 116 121 112 101 61 34 116 # =E2=80=A6) =E2=80=A6) > scheme@(guile-user) [1]>=20 > > tcpdump shows that the server ends the http session abruptly with a RST: > > 16:07:31.060489 IP 192.168.199.228.57353 > 172.18.23.123.80: Flags [S], s= eq 3473013508, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 931= 410271 ecr 0,sackOK,eol], length 0 > 16:07:31.064571 IP 172.18.23.123.80 > 192.168.199.228.57353: Flags [S.], = seq 4261252364, ack 3473013509, win 1024, options [mss 1024], length 0 > 16:07:31.064635 IP 192.168.199.228.57353 > 172.18.23.123.80: Flags [.], a= ck 1, win 65535, length 0 > 16:07:31.064923 IP 192.168.199.228.57353 > 172.18.23.123.80: Flags [P.], = seq 1:60, ack 1, win 65535, length 59 > 16:07:31.066022 IP 172.18.23.123.80 > 192.168.199.228.57353: Flags [P.], = seq 1:521, ack 60, win 1024, length 520 > 16:07:31.066075 IP 192.168.199.228.57353 > 172.18.23.123.80: Flags [.], a= ck 521, win 65015, length 0 > 16:07:31.068523 IP 172.18.23.123.80 > 192.168.199.228.57353: Flags [R], s= eq 4261252885, win 1024, length 0 > > This seems compliant with RFC 1122: > > 4.2.2.13 Closing a Connection: RFC-793 Section 3.5 > > A TCP connection may terminate in two ways:=20 > (1) the normal TCP close sequence using a FIN handshake, and= =20 > (2) an "abort" in which one or more RST segments are sent and= =20 > the connection state is immediately discarded.=20 > > The server responds with a body that contains an http redirect informatio= n but > ends with a RST packet which is case (2). While it is true that the RFCs allow a TCP connection to be "aborted" by a RST segment, this is an error condition. It's not a proper way to end an HTTP connection under normal circumstances. I believe the server you are trying to talk to is violating the HTTP protocol. Among other things, I believe that a RST segment may cause the receiving side to discard any input buffers that have not yet been read by the client. I see nothing in RFC 2616 that allows this behavior. In fact, section 10.4 explicitly mentions the danger that resetting the connection may cause data loss. > My question is how I can I handle this, ie, read the response body and ig= nore the RST > in Guile without changing anything in libguile? I'm sorry, but I don't see an easy way to work around this problem (which doesn't necessarily mean it can't be done). Out of curiosity, do you know what software is running on this server? Have you checked to see whether the server resets the connection when talking to a different HTTP client? Regards, Mark