We enjoy using http.Transport as it gives us a real solid HTTP client functionality and faithful protocol implementation. The connection pooling/management is also bundled into http.Transport. That's the part I'd like to discuss. The http.Transport connection management takes a stance on a few areas. For example,
- it does not limit the number of *active* connections - it reuses available connections in a LIFO manner There are real needs and use cases where we need a different behavior there. We may want to limit the number of active connections. We may want to have a different connection pooling policy (e.g. FIFO). But today it is not possible if you use http.Transport. The only option is to implement the HTTP client, but we like the protocol implementation that exists in http.Transport. This is probably more of a go 2 suggestion, but it would be great if these policies are configurable first of all so that we can realize different policies than the current hard-coded ones. Even better, it would be awesome if the connection management aspect of http.Transport is separated from the protocol aspect of http.Transport and become pluggable. Then we could choose to provide a different connection management implementation and mix it with the protocol support of http.Transport. Thoughts? Regards, Sangjin -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
