Re: Split error codes in two

[Jana Iyengar <[e-mail]>]

>
> I'm less convinced that STOP_SENDING is HTTP-specific.  To my mind, it's
> the wire expression of a read_close(), just as RST_STREAM is the wire
> expression of a write_close().  If we'd gone the advisory route, it would
> be an HTTP-ism.  (Or at least, the mandated behavior would be at the HTTP
> layer.)  However, if we think other applications aren't ever going to want
> to close a read stream....


TCP allows for read_close() with shutdown(socket, RD), and it basically
means that TCP will send a RST to subsequent incoming data on that socket
from the peer. The expectation is that the application knows to not send
data to a peer that has issued a read_close().

What we're talking about here is different than a read_close(), since it's
an instruction to the peer to stop sending. This is only useful if I don't
want to stop sending but want only the peer to stop sending.... and the
driving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use
case odd, but I don't know that there's really a need for this otherwise.
I'm not very married on this point, but I'm wary of providing a knob that
really doesn't have a strong use case.