* An http session that ends with a TCP Reset sent by the server
@ 2013-06-13 10:23 Darren Hoo
0 siblings, 0 replies; 4+ messages in thread
From: Darren Hoo @ 2013-06-13 10:23 UTC (permalink / raw)
To: guile-user
I used web client to access a web service as what follows:
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
#<input-output: socket 11> #:method "GET" #:version (1 . 1)
#:keep-alive? #f #:headers () #:decode-body? #t # #f # #)
In web/response.scm:
310:2 3 (read-response-body #<<response> version: (1 . 1) code:
200 reason-phrase: "OK" headers: ((cache-control no-cache) (connection
close) (content-type text/html) (cont…>)
In unknown file:
2 (get-bytevector-all #<input:
r6rs-custom-binary-input-port 10b454c30>)
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 47 106 97 118 97 115 99 114 …) …)
In unknown file:
0 (get-bytevector-n! #<input-output: socket 11> #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 # …) …)
scheme@(guile-user) [1]>
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], seq 3473013508, win 65535, options [mss 1460,nop,wscale
4,nop,nop,TS val 931410271 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
[.], ack 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
[.], ack 521, win 65015, length 0
16:07:31.068523 IP 172.18.23.123.80 > 192.168.199.228.57353: Flags
[R], seq 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:
(1) the normal TCP close sequence using a FIN handshake, and
(2) an "abort" in which one or more RST segments are sent and
the connection state is immediately discarded.
The server responds with a body that contains an http redirect information but
ends with a RST packet which is case (2).
My question is how I can I handle this, ie, read the response body and
ignore the RST
in Guile without changing anything in libguile?
^ permalink raw reply [flat|nested] 4+ messages in thread* An http session that ends with a TCP Reset sent by the server
@ 2013-06-13 8:33 Darren Hoo
2013-06-14 16:21 ` Mark H Weaver
0 siblings, 1 reply; 4+ messages in thread
From: Darren Hoo @ 2013-06-13 8:33 UTC (permalink / raw)
To: guile-user
I use the web client module to access a web service as what follows
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 #<input-output: socket 11> #:method "GET" #:version (1 . 1) #:keep-alive? #f #:headers () #:decode-body? #t # #f # #)
In web/response.scm:
310:2 3 (read-response-body #<<response> version: (1 . 1) code: 200 reason-phrase: "OK" headers: ((cache-control no-cache) (connection close) (content-type text/html) (cont…>)
In unknown file:
2 (get-bytevector-all #<input: r6rs-custom-binary-input-port 10b454c30>)
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 47 106 97 118 97 115 99 114 …) …)
In unknown file:
0 (get-bytevector-n! #<input-output: socket 11> #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 # …) …)
scheme@(guile-user) [1]>
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], seq 3473013508, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 931410271 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 [.], ack 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 [.], ack 521, win 65015, length 0
16:07:31.068523 IP 172.18.23.123.80 > 192.168.199.228.57353: Flags [R], seq 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:
(1) the normal TCP close sequence using a FIN handshake, and
(2) an "abort" in which one or more RST segments are sent and
the connection state is immediately discarded.
The server responds with a body that contains an http redirect information but
ends with a RST packet which is case (2).
My question is how I can I handle this, ie, read the response body and ignore the RST
in Guile without changing anything in libguile?
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: An http session that ends with a TCP Reset sent by the server
2013-06-13 8:33 Darren Hoo
@ 2013-06-14 16:21 ` Mark H Weaver
2013-06-16 3:17 ` Darren Hoo
0 siblings, 1 reply; 4+ messages in thread
From: Mark H Weaver @ 2013-06-14 16:21 UTC (permalink / raw)
To: Darren Hoo; +Cc: guile-user
Hi,
Darren Hoo <darren.hoo@gmail.com> writes:
> I use the web client module to access a web service as what follows
>
> 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 #<input-output: socket 11> #:method "GET" #:version (1 . 1) #:keep-alive? #f #:headers () #:decode-body? #t # #f # #)
> In web/response.scm:
> 310:2 3 (read-response-body #<<response> version: (1 . 1) code: 200 reason-phrase: "OK" headers: ((cache-control no-cache) (connection close) (content-type text/html) (cont…>)
> In unknown file:
> 2 (get-bytevector-all #<input: r6rs-custom-binary-input-port 10b454c30>)
> 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 47 106 97 118 97 115 99 114 …) …)
> In unknown file:
> 0 (get-bytevector-n! #<input-output: socket 11> #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 # …) …)
> scheme@(guile-user) [1]>
>
> 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], seq 3473013508, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 931410271 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 [.], ack 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 [.], ack 521, win 65015, length 0
> 16:07:31.068523 IP 172.18.23.123.80 > 192.168.199.228.57353: Flags [R], seq 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:
> (1) the normal TCP close sequence using a FIN handshake, and
> (2) an "abort" in which one or more RST segments are sent and
> the connection state is immediately discarded.
>
> The server responds with a body that contains an http redirect information 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 ignore 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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: An http session that ends with a TCP Reset sent by the server
2013-06-14 16:21 ` Mark H Weaver
@ 2013-06-16 3:17 ` Darren Hoo
0 siblings, 0 replies; 4+ messages in thread
From: Darren Hoo @ 2013-06-16 3:17 UTC (permalink / raw)
To: guile-user
Mark H Weaver <mhw@netris.org> writes:
Hi Mark,
Thanks,
>
> 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.
Yes it is violateing the protocol. Sorry to have not mentioned that the
response recieved is from the firewall not the real server.
> 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 ignore 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?
>
Yes, both curl and brower receive RST but do not report anything
conceivable to the user.
I think there's no elegant way to deal with this condition with Guile,
maybe I should try other alternative to work around this.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-06-16 3:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-13 10:23 An http session that ends with a TCP Reset sent by the server Darren Hoo
-- strict thread matches above, loose matches on Subject: below --
2013-06-13 8:33 Darren Hoo
2013-06-14 16:21 ` Mark H Weaver
2013-06-16 3:17 ` Darren Hoo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).