5 ms·

I dont necessarily agree they should return a value, but I do have some issues with the api: - by default, you can't tell if a handler has already written to t

• morelisp 4y ago
  - by default, you can't read the body more than once This is a reasonable default - probably the only reasonable default. `TeeReader` and `MultiReader` are easily available if you want to spare the memory. (But you're right that the converse on the ResponseWriter isn't true, it's much more difficult to get your own implementation right.) - the http server accepts an unbounded number of connections. it'll just keep making goroutines as they come in. there's no way that I know of to apply back pressure. `net.Listener` is an interface you may implement as you choose. But in most cases a CPU limit is more than sufficient backpressure.
  • chrsig 4y ago
    > This is a reasonable default - probably the only reasonable default. `TeeReader` and `MultiReader` are easily available if you want to spare the memory. (But you're right that the converse on the ResponseWriter isn't true, it's much more difficult to get your own implementation right.) Fair enough > `net.Listener` is an interface you may implement as you choose Good point -- thanks, I hadn't considered to try and bound connections using a listener implementation. > But in most cases a CPU limit is more than sufficient backpressure. In many cases it's probably fine - but not all. The issue with letting CPU be the back pressure is that it'll happen _after_ the connection is established. Unless I'm mistaken, if a load balancer can't connect, it'll usually try another host, but if it connects and times out...there may have been some side effects, so it can't try another host.
    • morelisp 4y ago
      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.
      • chrsig 4y ago
        > 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