Whether the lb can safely retry should depend on the HTTP method, in practice you can configure most lbs appropriately based on application knowledge as well. (I.e. a repeat POST might be "safe enough" on some endpoints.)
> The issue with letting CPU be the back pressure is that it'll happen _after_ the connection is established.
But this is true of anything the http.Server could have done. If you want an application-agnostic client to be sure it's safe to re-issue a POST, you have to stop it before the connection is open because as soon as it's open that data is coming through. Conversely, for anything (general or application-specific) the http.Server could have done after pickup, you could do in an early-stage handler for little to no additional overhead.
It feels like you're asking for something HTTP can't really do, so of course http.Server can't do it.
> It feels like you're asking for something HTTP can't really do, so of course http.Server can't do it.
This is a fair enough point. I wasn't being discerning enough with my critique of http.Server, and when writing my initial comment, and neglected that a custom net.Listener could be supplied.
> Whether the lb can safely retry should depend on the HTTP method
to be more precise with this statement whether the lb can safely retry _after an initial connection has been made_ should depend on the http method (e.g., GET and HEAD can be considered idempotent...whether they actually are is up to the server)
> But this is true of anything the http.Server could have done.
Yes - which is why I saw value in your mentioning that a customer listener may be supplied.
> If you want an application-agnostic client to be sure it's safe to re-issue a POST, you have to stop it before the connection is open because as soon as it's open that data is coming through.
This was exactly my point.
> Conversely, for anything (general or application-specific) the http.Server could have done after pickup, you could do in an early-stage handler for little to no additional overhead.
Yes, but since the listener accepted the connection, it can't be retried against a different host.
to recap:
I'm suggesting that there are times when it's appropriate to have a listener that circuit breaks to stop accepting connections. To your point, while the need exists, that's a concern of the tcp layer rather than the http layer, so not a fair criticism of http.Server
> The issue with letting CPU be the back pressure is that it'll happen _after_ the connection is established.
But this is true of anything the http.Server could have done. If you want an application-agnostic client to be sure it's safe to re-issue a POST, you have to stop it before the connection is open because as soon as it's open that data is coming through. Conversely, for anything (general or application-specific) the http.Server could have done after pickup, you could do in an early-stage handler for little to no additional overhead.
It feels like you're asking for something HTTP can't really do, so of course http.Server can't do it.