5 ms·

Yes, it is a misuse of a TCP reset. The RFCs are very clear about when to use a TCP reset. You can't use a reset just because you want to be fast or don't feel

by scurvy 10y ago

Yes, it is a misuse of a TCP reset. The RFCs are very clear about when to use a TCP reset. You can't use a reset just because you want to be fast or don't feel like sending any more data. Resets are for something abnormal happening. A timeout isn't abnormal to a TCP connection. It's part of the process.

Dylan16807 10y ago
So what are you supposed to do?
dsp1234 10y ago
RFC 1122[0] says: 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. and A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection. If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost. So this behavior seems fine unless another RFC specifically prevents it. [0] - https://tools.ietf.org/html/rfc1122#section-4.2.2.13 https://tools.ietf.org/html/rfc1122#section-4.2.2.13
DanielDent 10y ago
It's absolutely a misuse and causes all kinds of assumptions which the RFCs make about how people write their software to become invalid. It's also a simple and state-free way of influencing other devices on the network. Arbor is an interesting example - when doing DDoS mitigation, an approach which doesn't require a lot of resources or statefulness is extremely useful. On one hand, I want to agree with you: this is terrible and makes everyone else's life harder. On the other hand, maybe its TCP's resource requirements that are at fault.
arielb1 10y ago
Closing the connection would cause the client to believe that the file has been fully downloaded - resulting in a truncated file. Not good. HTTP does not have a way of sending an error in-mid-transfer, so a TCP reset has to suffice. The other option would be to blackhole the connection, but that would be worse for both sides.
- nunwuo 10y ago
  > Closing the connection would cause the client to believe that the file has been fully downloaded - resulting in a truncated file. Not good. That's not correct. Both Content-Length and the chunked encoding scheme would allow the client to know that the connection was terminated before the end of stream was reached.

by scurvy 10y ago

Dylan16807 10y ago

So what are you supposed to do?

dsp1234 10y ago

RFC 1122[0] says: 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. and A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection. If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost. So this behavior seems fine unless another RFC specifically prevents it. [0] - https://tools.ietf.org/html/rfc1122#section-4.2.2.13 https://tools.ietf.org/html/rfc1122#section-4.2.2.13

DanielDent 10y ago

It's absolutely a misuse and causes all kinds of assumptions which the RFCs make about how people write their software to become invalid. It's also a simple and state-free way of influencing other devices on the network. Arbor is an interesting example - when doing DDoS mitigation, an approach which doesn't require a lot of resources or statefulness is extremely useful. On one hand, I want to agree with you: this is terrible and makes everyone else's life harder. On the other hand, maybe its TCP's resource requirements that are at fault.

arielb1 10y ago

Closing the connection would cause the client to believe that the file has been fully downloaded - resulting in a truncated file. Not good. HTTP does not have a way of sending an error in-mid-transfer, so a TCP reset has to suffice. The other option would be to blackhole the connection, but that would be worse for both sides.

nunwuo 10y ago
> Closing the connection would cause the client to believe that the file has been fully downloaded - resulting in a truncated file. Not good. That's not correct. Both Content-Length and the chunked encoding scheme would allow the client to know that the connection was terminated before the end of stream was reached.