Forum Discussion

dIone_24797's avatar
dIone_24797
Icon for Nimbostratus rankNimbostratus
Nov 14, 2013

One Connect not keeping connection open on HTTP 204 No Content

We have an application that returns a 'HTTP 204 No Content' response on 99% of all requests. These connections are being kept open and reused on the client side of the F5. The problem is the Load Balancer closes these connections on the server side right after the HTTP 204 RESPONSE is received from the server. When we send a HTTP 200 the connection is kept open and reused(normal One Connect operation).

 

Is there an iRule that we can apply to the VIP to keep the connection open even when the Server returns a 'HTTP 204 No Content'?

 

Thanks

 

  • What evidence do you have it's the load balancer closing connections server-side rather than the server please?

     

  • I have wireshark captures on both sides. Connections are staying open on client side and closing/opening on server side per request/response.

     

    Server side is being closed after a HTTP 204 is sent.(FIN from LB to close connection) I have confirmed that FIN is not coming from the Client.

     

  • What version of HTTP is being used on the server side please (by the servers)? What's the OneConnect parameters?

     

  • Hmmmm. I wonder if someone has misinterpreted the RFC;

    10.2.5 204 No Content

    The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.
    
    If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.
    
    The 204 response MUST NOT include a message-body, **and thus is always terminated by the first empty line after the header fields**. 
    
  • My reading of that RFC is not that the connection should be closed after a 204, rather that the 204 response is terminated (potentially leaving the connection available to be re-used) - I don't see that it varies the Keeaplive behaviour at all from say a 200.

     

    • dIone_24797's avatar
      dIone_24797
      Icon for Nimbostratus rankNimbostratus
      It is certainly unclear in the RFC. Our F5 is closing the connection on every 204 on the server side. Here is a dump of the traffic flow showing the close after every 204. No. Time Source Destination Protocol Length Info 119 0.103542 173.241.249.22 10.130.3.15 TCP 78 13330 > http [SYN] Seq=0 Win=4380 Len=0 MSS=1460 WS=1 TSval=940561079 TSecr=0 SACK_PERM=1 Frame 119: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) Ethernet II, Src: F5Networ_32:d6:87 (00:23:e9:32:d6:87), Dst: Vmware_8e:21:d2 (00:50:56:8e:21:d2) Internet Protocol Version 4, Src: 173.241.249.22 (173.241.249.22), Dst: 10.130.3.15 (10.130.3.15) Transmission Control Protocol, Src Port: 13330 (13330), Dst Port: http (80), Seq: 0, Len: 0 No. Time Source Destination Protocol Length Info 120 0.103552 10.130.3.15 173.241.249.22 TCP 62 http > 13330 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=1024 Frame 120: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) Ethernet II, Src: Vmware_8e:21:d2 (00:50:56:8e:21:d2), Dst: F5Networ_32:d6:87 (00:23:e9:32:d6:87) Internet Protocol Version 4, Src: 10.130.3.15 (10.130.3.15), Dst: 173.241.249.22 (173.241.249.22) Transmission Control Protocol, Src Port: http (80), Dst Port: 13330 (13330), Seq: 0, Ack: 1, Len: 0 No. Time Source Destination Protocol Length Info 121 0.104006 173.241.249.22 10.130.3.15 TCP 60 13330 > http [ACK] Seq=1 Ack=1 Win=4380 Len=0 Frame 121: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: F5Networ_32:d6:87 (00:23:e9:32:d6:87), Dst: Vmware_8e:21:d2 (00:50:56:8e:21:d2) Internet Protocol Version 4, Src: 173.241.249.22 (173.241.249.22), Dst: 10.130.3.15 (10.130.3.15) Transmission Control Protocol, Src Port: 13330 (13330), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Length Info 123 0.105814 173.241.249.22 10.130.3.15 HTTP 908 POST / HTTP/1.1 (application/octet-stream) Frame 123: 908 bytes on wire (7264 bits), 908 bytes captured (7264 bits) Ethernet II, Src: F5Networ_32:d6:87 (00:23:e9:32:d6:87), Dst: Vmware_8e:21:d2 (00:50:56:8e:21:d2) Internet Protocol Version 4, Src: 173.241.249.22 (173.241.249.22), Dst: 10.130.3.15 (10.130.3.15) Transmission Control Protocol, Src Port: 13330 (13330), Dst Port: http (80), Seq: 1, Ack: 1, Len: 854 Hypertext Transfer Protocol Media Type No. Time Source Destination Protocol Length Info 124 0.105830 10.130.3.15 173.241.249.22 TCP 54 http > 13330 [ACK] Seq=1 Ack=855 Win=8192 Len=0 Frame 124: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: Vmware_8e:21:d2 (00:50:56:8e:21:d2), Dst: F5Networ_32:d6:87 (00:23:e9:32:d6:87) Internet Protocol Version 4, Src: 10.130.3.15 (10.130.3.15), Dst: 173.241.249.22 (173.241.249.22) Transmission Control Protocol, Src Port: http (80), Dst Port: 13330 (13330), Seq: 1, Ack: 855, Len: 0 No. Time Source Destination Protocol Length Info 126 0.113417 10.130.3.15 173.241.249.22 HTTP 185 HTTP/1.1 204 No Content Frame 126: 185 bytes on wire (1480 bits), 185 bytes captured (1480 bits) Ethernet II, Src: Vmware_8e:21:d2 (00:50:56:8e:21:d2), Dst: F5Networ_32:d6:87 (00:23:e9:32:d6:87) Internet Protocol Version 4, Src: 10.130.3.15 (10.130.3.15), Dst: 173.241.249.22 (173.241.249.22) Transmission Control Protocol, Src Port: http (80), Dst Port: 13330 (13330), Seq: 1, Ack: 855, Len: 131 Hypertext Transfer Protocol No. Time Source Destination Protocol Length Info 127 0.114416 173.241.249.22 10.130.3.15 TCP 60 13330 > http [ACK] Seq=855 Ack=132 Win=4511 Len=0 Frame 127: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: F5Networ_32:d6:87 (00:23:e9:32:d6:87), Dst: Vmware_8e:21:d2 (00:50:56:8e:21:d2) Internet Protocol Version 4, Src: 173.241.249.22 (173.241.249.22), Dst: 10.130.3.15 (10.130.3.15) Transmission Control Protocol, Src Port: 13330 (13330), Dst Port: http (80), Seq: 855, Ack: 132, Len: 0 No. Time Source Destination Protocol Length Info 141 0.122574 173.241.249.22 10.130.3.15 TCP 60 13330 > http [FIN, ACK] Seq=855 Ack=132 Win=4511 Len=0 Frame 141: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: F5Networ_32:d6:87 (00:23:e9:32:d6:87), Dst: Vmware_8e:21:d2 (00:50:56:8e:21:d2) Internet Protocol Version 4, Src: 173.241.249.22 (173.241.249.22), Dst: 10.130.3.15 (10.130.3.15) Transmission Control Protocol, Src Port: 13330 (13330), Dst Port: http (80), Seq: 855, Ack: 132, Len: 0 No. Time Source Destination Protocol Length Info 142 0.124206 10.130.3.15 173.241.249.22 TCP 54 http > 13330 [FIN, ACK] Seq=132 Ack=856 Win=8192 Len=0 Frame 142: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: Vmware_8e:21:d2 (00:50:56:8e:21:d2), Dst: F5Networ_32:d6:87 (00:23:e9:32:d6:87) Internet Protocol Version 4, Src: 10.130.3.15 (10.130.3.15), Dst: 173.241.249.22 (173.241.249.22) Transmission Control Protocol, Src Port: http (80), Dst Port: 13330 (13330), Seq: 132, Ack: 856, Len: 0 No. Time Source Destination Protocol Length Info 143 0.124366 173.241.249.22 10.130.3.15 TCP 60 13330 > http [ACK] Seq=856 Ack=133 Win=4511 Len=0 Frame 143: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: F5Networ_32:d6:87 (00:23:e9:32:d6:87), Dst: Vmware_8e:21:d2 (00:50:56:8e:21:d2) Internet Protocol Version 4, Src: 173.241.249.22 (173.241.249.22), Dst: 10.130.3.15 (10.130.3.15) Transmission Control Protocol, Src Port: 13330 (13330), Dst Port: http (80), Seq: 856, Ack: 133, Len: 0
  • By default, Oneconnect is not used when the HTTP status code is anything besides 200 or 206. You can reconfigure that "oneconnect status reuse" parameter here in the web UI: