1

I observe following scenario in WireShark:

scenario

The problem I see here is that after receiving [FIN, ACK] from server (4090) and acknowledging it (4092), http client attempts to send another HTTP request instead of immediately close (and probably reestablish) TCP connection. It looks like [FIN, ACK] is simply ignored by HTTP clients.

According to RFC 7230 (6.3), HTTP protocol specifies it's oven mechanism for persistent connection management using Connection headers. It works just fine, since it supported by both clients and servers.

However HTTP is usually run on top of TCP. TCP connection management have no idea about protocol on top and can be used independently from HTTP. But HTTP clients doesn't support handling this (and probably they shouldn't, it should be supported on socket level). However servers do utilize it, because it allows to gracefully close connection without sending additional HTTP request. For example nginx sends FIN package, when connection is timed out or on configuration reload.

NOTE When HTTP client receives RST from server it closes connection. And it seems to be done on socket level, since I can't find anything related to this in HTTP clients' source code.

  1. Is my understanding of situation correct? Ignoring FIN message by clients, while servers use it, seems to be completely wrong.
  2. Why RST is handled on socket level, but FIN is not?
  3. Is there any RFC/other standard on how HTTP clients should handle TCP connection closing?
  4. Is it nginx doing something non-standard or HTTP clients doesn't follow standard?

PS I'm able to reproduce it using HTTP clients in Python 2/3, Java and httperf utility written in C. So I believe it's common for HTTP clients to ignore FIN message. I want to understand why.

Yaroslav Admin
  • 1,098
  • 1
  • 10
  • 15
  • I am experiencing the same issue, have you found any solution? – Daniel Conde Marin Feb 07 '16 at 17:30
  • @DanielConde I decided to live with it. I didn't check further information, just my understanding. Sending `FIN` signal means "I'm not going to send any more data". That should close socket's reading stream on the client side. Since HTTP clients start waiting for input on reading stream only after sending a request it has no idea, that `FIN` signal arrived until it sends a request and goes to "waiting for response" state. – Yaroslav Admin Feb 08 '16 at 10:56
  • @DanielConde The possible improvement is to check, whether socket's reading stream is open before sending request, but `FIN` signal can arrive after check, but before actual request, so it doesn't solve problem completely. That's probably the reason, why it's not done in the clients. – Yaroslav Admin Feb 08 '16 at 10:56

0 Answers0