transport.RoundTripper feature request

[David Birdsong]

I noticed that transport.RoundTripper shares a lot w/ the stdlib http.Transport, but is missing a critical feature that I've come to rely on: ResponseHeaderTimeout.

Would you consider adding it? I've whipped up a simple implementation on a feature branch of my fork: https://github.com/davidbirdsong/goproxy/commit/a3bc052d6649f0ddbeda4454c08322f4f3613003

Mind taking a look and providing any feedback or whether you'd consider a PR?

[Elazar Leibovich]

Hi,

The transport was an attempt to support ICY streams, see https://github.com/elazarl/goproxy/issues/3

It is not currently used, and was left for backwards compatibility.

I'm not sure whether currently investing in it is a good idea, and if we are, we should rebase it to the latest transport from the standard library.

What prevents you from simply using the roundtripper from the standard library?

--
You received this message because you are subscribed to the Google Groups "goproxy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to goproxy-dev...@googlegroups.com.
To post to this group, send email to gopro...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/goproxy-dev/24be37e6-005c-42b9-b8bc-a1f2babd7a64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Birdsong]

On Wed, Apr 15, 2015 at 10:06 PM, Elazar Leibovich <ela...@gmail.com> wrote:

Hi,

The transport was an attempt to support ICY streams, see https://github.com/elazarl/goproxy/issues/3

It is not currently used, and was left for backwards compatibility.

I'm not sure whether currently investing in it is a good idea, and if we are, we should rebase it to the latest transport from the standard library.

What prevents you from simply using the roundtripper from the standard library?

I'm writing a forward proxy and have a few requirements:

- log ip address for remote address (not just name)

- connection re-use to cut down on handshakes

- log connection re-use counts (nice to have, not totally required)

- response header timeouts

- FUTURE requirement of respecting DNS TTL's that close connections gracefully, re-resolve, and reconnect

The standard lib provides 2/5, but makes the remaining quite hard to achieve with it's internals a bit walled off. For instance, it provides header timeouts, but no way of checking against the error that's eventually returned by the roundtripper against a known error since the error is not exported from http/transport.go

I'm hesitant to try to reimplement a roundtripper from scratch--in particular getting the connection pooling/caching correct is a bit daunting to undertake.

transport.Transport seemed like a good start with DetailedRoundTrip already in place to report back connection-level information like net.TCPAddr