(Option to) show which IP is being connected to

[abh]

My applications often have numerous IPs (CDNs, etc), so showing which IP is being connected to is helpful.

(Along the same lines, an option to connect to a particular IP could also be helpful; along the lines of the -x or --resolv options from curl).

[davecheney]

Sounds good to me. For the first request something like

Connected to {{ .raddr.String() }}

Should do at the end of the conn.Dial phase (t2 or t3, i don't remember offhand). Please make the words "Connected to " green, and the output of raddr.String() cyan.

For the second, if you want to implement -x, go for it.

On Sun, Sep 25, 2016 at 6:10 AM, Ask Bjørn Hansen notifications@github.com wrote:

My applications often have numerous IPs (CDNs, etc), so showing which IP is being connected to is helpful.

(Along the same lines, an option to connect to a particular IP could also be helpful; along the lines of the -x or --resolv options from curl).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/davecheney/httpstat/issues/36, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA3gqgfmbkifhCdYTSGtEWIywqXOjks5qtYOjgaJpZM4KFu8u .

[davecheney]

Adding the -x flag should wait until #31 or #37 is merged.

[davecheney]

@abh @ble if you want to add -x, now's the time.

[ble]

-x is the same as --proxy for cURL; if we want to be cURL-like, I think this falls under issue #67. cf. https://curl.haxx.se/docs/manpage.html#-x

--resolve is kind of curious. If I understand the cURL manual correctly, it basically overrides DNS for one or more authorities (host-port pairs for the non-pedantic). cf. https://curl.haxx.se/docs/manpage.html#--resolve

@davecheney what do you think of adding --resolve?

[ble]

nb. looks like making an equivalent to --resolve requires the ability to have multiple --resolve flags in one command line. Could change that to one comma-separated string, I guess.

[freeformz]

@ble it's possibly to do multiples of the same arg with flag, but it wouldn't be gnu long args compatible though

[ble]

@freeformz that's cool, can you point me at an example?

[freeformz]

@ble See -H handling on master.

[davecheney]

SGTM. One less flag and possibly more consistency to handle this via -H Host ...

[abh]

--resolv is different than -H, obviously. It's not just the opposite though, in TLS/SNI scenarios it's hard to do the override with -H 'Host: ...' and likewise in redirect chains.

[davecheney]

Can you show an example using curl and httpstat to show where they differ. Thanks

On Tue, 27 Sep 2016, 09:00 Ask Bjørn Hansen notifications@github.com wrote:

--resolv is different than -H, obviously. It's not just the opposite though, in TLS/SNI scenarios it's hard to do the override with -H 'Host: ...' and likewise in redirect chains.

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/davecheney/httpstat/issues/36#issuecomment-249722299, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA5hdYR0Efz7ndOJpRURTmPihckylks5quE6RgaJpZM4KFu8u .

[abh]

I want to test connecting to a particular IP with SNI www.google.com; with curl this is possible:

$ curl --resolv www.google.com:443:172.217.24.100 https://www.google.com/

But not with httpstat:

$ httpstat -H 'Host: www.google.com' https://172.217.24.100

Connected to 172.217.24.100:443
2016/09/27 07:47:23 unable to negotiate TLS handshake: x509: cannot validate certificate for 172.217.24.100 because it doesn't contain any IP SANs

It works with redirect chains, too:

$ curl -vL --resolv mail.google.com:443:172.217.24.100 mail.ntppool.org

Or you can do dumb stuff like having one host for the SNI header and something else for the Host header:

$ curl -H 'Host: mail.google.com' --resolv www.google.com:443:172.217.24.100 https://www.google.com/

The -x option in curl is a little different because it says "send all the requests through the specified proxy, so you get "GET http://www.google.com/ HTTP/1.1" and "CONNECT www.google.com:443" etc type stuff. For some quick tests this is sufficient (in particular if your server supports being an HTTP proxy), but it's not nearly as accurate in using resolv.

[davecheney]

I've updated the issue to reflect the work remaining.

note to implementors: Curl's flag is called --resolve, but we'll probably have to come up with a different single character flag name to avoid taking a dependency for something that supports GNU flags.

[ble]

So you'd prefer a single character flag to -resolve?

[davecheney]

Yes, let's not get into the -wierd -single -hypen=modes -t -h -e go flag package uses

On Tue, 27 Sep 2016, 22:18 Ben Ellis notifications@github.com wrote:

So you'd prefer a single character flag to -resolve?

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/davecheney/httpstat/issues/36#issuecomment-249848301, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA038jo8JsAG6MVbOk4gxa7zaCFFsks5quQmsgaJpZM4KFu8u .

[davecheney]

@ble/@moorereason if you want to tackle this please send a PR before 1 October. With that said, I'm thinking that with the merge of #7, this is not a trivial exercise.

[ble]

That implementation of -R looks pretty good. Do we want to support multiple -Rs as curl does? Seems it would only be relevant with redirects.

[moorereason]

@ble, the verdict is still out on adding the -R option. See the discussion in #96. If we end up adding it, we could support multiples.