There will be a FIN, you are instructing the server to close the connection, you are sending "Connection: close" in the HTTP/1.1 header. If the connection is lost, you will receive a callback. If you can't wait, start a timer...
Nevertheless, if you still want to close on client side, you can do so as you are doing now, but if the RST breaks something (it shouldn't), you can start a timer, stopped on server closure or error, and firing closure on expiration. On 03/03/2016 01:14 a.m., Sergio R. Caprile wrote: > The piggybacked SYN in frame 4 is considered part of the stream and so > the sequence number in frame 5 is one more than what you would expect. > The RST flag is also a correct response because you close the connection > before the stack can process the FIN (what it would do after you return > ERR_OK, and will call you again to inform you of the closure) > RFC1192 4.4.2.13 > https://tools.ietf.org/html/rfc1122#page-87 > > I'm not sure if the FIN can be considered part of the stream, but I've > found references to that, and lwIP seems to be doing so. > > If this is true, the test I suggested should end with the expected FIN > ACK on the client side. > -- Sergio R. Caprile, Human Being, Bs.As., Argentina http://www.scaprile.ldir.com.ar/ _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
