Re: [PATCH v3] http: add custom hostname to IP address resolutions

From: Carlo Arenas <carenas@gmail.com>
Date: May 12, 2022, 11:55 UTC
Message-ID: <CAPUEsphmN+1FVdQSX3GoRYQBh33XdR+nN-WAPZdtZmMsBAfazg@mail.gmail.com>
In-Reply-To: <CAP8UFD2F=5RsB_WVOHKmzJsD9UJgZ2YM_yreTur2_huAAJ=+Vw@mail.gmail.com>

On Thu, May 12, 2022 at 1:30 AM Christian Couder <christian.couder@gmail.com> wrote:

Show 11 quoted lines

> On Tue, May 10, 2022 at 8:20 PM Carlo Arenas <carenas@gmail.com> wrote:
> > I also think it might be a little confusing (and probably warranted of
> > an advice message) if git will decide based on a configuration
> > somewhere in its resolution tree that the IP I am connecting is
> > different than the one I expect it to use through the system
> > configured resolution mechanism for such a thing.
>
> I would be Ok to add an advice message or another kind of message
> telling users that the IP used is based on the config variable. It
> could break scripts parsing Git's output though (even if it's bad
> practice to do so).

Only if they added that config option, which is an obscure one that nobody should be using anyway, so very unlikely, right? I also think that breaking my script could be avoided by turning off the advice (as suggested previously), and I MIGHT want to have my script broken if I picked up this config by mistake.

> So we would need to decide the kind of message and
> its content. Suggestions welcome.

I am not good at wording those, but I would think something innocuous like :

  "curl override detected to point name %s to %s instead of using DNS"

Show 8 quoted lines

> > I assume that if you want to use this frequently, having that advice
> > disabled in your global config wouldn't be a hassle, but it might be
> > useful to know that I am interacting with a potentially different IP
> > when referring to some host by name in my local repo, maybe because I
> > forgot to change that setting after some debugging.
>
> Yeah, maybe. On the other hand GIT_CURL_VERBOSE might already be the
> canonical way to debug this and might already tell about this.

of course, but that is mostly used when debugging HTTP issues, not when your DNS seems to have gone nuts, and you are looking at your screen in disbelief because the code you were working on before lunch and having released is now suddenly in production.

Show 17 quoted lines

> Yeah, it does:
>
> <= Recv header:
> == Info: Connection #0 to host gitbogusexamplehost.com left intact
> == Info: RESOLVE gitbogusexamplehost.com:5551 is - old addresses discarded!
> == Info: Added gitbogusexamplehost.com:5551:127.0.0.1 to DNS cache
> == Info: Couldn't find host gitbogusexamplehost.com in the .netrc
> file; using defaults
> == Info: Found bundle for host gitbogusexamplehost.com: 0x5556d2bd1340
> [serially]
> == Info: Can not multiplex, even if we wanted to!
> == Info: Re-using existing connection! (#0) with host gitbogusexamplehost.com
> == Info: Connected to gitbogusexamplehost.com (127.0.0.1) port 5551 (#0)
>
> I agree it might not be very clear that it's because
> "http.curloptResolve" is used though. But maybe we could output a more
> explicit warning message only if GIT_CURL_VERBOSE is set.

As I pointed in my example I can see this being useful also for some web developing which are mostly concerned about JavaScript and might not be aware of the OSI layer stack and how to get an HTTP packet dump, so I would think better done even when GIT_CURL_VERBOSE is not set.

Show 5 quoted lines

> > I am sure all those folks that forget to edit their /etc/hosts after
> > they are done with their local site versions might instead use this
> > and then be happy to be warned about it later.
>
> Do you mean that those folks might like a config option ;-)

Yes, and I think it is not THAT of an obscure config option if it even has documentation as well ;)

Carlo