diff mbox series

http: add custom hostname to IP address resolves

Message ID 20220502083639.610279-1-chriscool@tuxfamily.org (mailing list archive)
State New, archived
Headers show
Series http: add custom hostname to IP address resolves | expand

Commit Message

Christian Couder May 2, 2022, 8:36 a.m. UTC
Libcurl has a CURLOPT_RESOLVE easy option that allows
hostname resolve information in the following form to
be passed:

	[+]HOST:PORT:ADDRESS[,ADDRESS]

This way, redirects and everything operating against the
HOST+PORT will use the provided ADDRESS(s).

The following form is also allowed to stop using these
resolves:

	-HOST:PORT

Let's add a corresponding "http.hostResolve" config
option that takes advantage of CURLOPT_RESOLVE.

Each value configured for the "http.hostResolve" key
is passed "as is" to curl through CURLOPT_RESOLVE, so it
should be in one of the above 2 forms. This keeps the
implementation simple and makes us consistent with
libcurl's CURLOPT_RESOLVE, and with curl's corresponding
`--resolve` command line option.

The implementation is similar to what is done for the
"http.extraHeader" config option, except that we use
CURLOPT_RESOLVE only in get_active_slot() which is
called by all the HTTP request sending functions.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---

I am not sure if some tests could/should be added. Ideas about how to
test this are welcome.

Documentation/config/http.txt | 16 ++++++++++++++++
 http.c                        | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 48 insertions(+)

Comments

Junio C Hamano May 2, 2022, 7:04 p.m. UTC | #1
Christian Couder <christian.couder@gmail.com> writes:

> Subject: Re: [PATCH] http: add custom hostname to IP address resolves

I can guess what you means, but I am not able to quite parse the
above.  I guess the phrase that makes me hiccup when I read is
"resolve" used as a noun.

> Libcurl has a CURLOPT_RESOLVE easy option that allows
> hostname resolve information in the following form to

The same here, "... allows the result of hostname resolution in the
following format ...", perhaps?

> be passed:
>
> 	[+]HOST:PORT:ADDRESS[,ADDRESS]
>
> This way, redirects and everything operating against the
> HOST+PORT will use the provided ADDRESS(s).
>
> The following form is also allowed to stop using these
> resolves:
>
> 	-HOST:PORT

The above is a reasonable summary of CURLOPT_RESOLVE documentation
that is appropriate to have here for those of us who are not
familiar with it.  For those of us who may want to learn more, it
would help to have an URL to the canonical documentation page, e.g.
https://curl.se/libcurl/c/CURLOPT_RESOLVE.html but it is not
required.  People should be able to find it easily.

> Let's add a corresponding "http.hostResolve" config
> option that takes advantage of CURLOPT_RESOLVE.

CURLOPT_RESOLVE allows us to feed cURL a list of these <host,port>
-> <address> mappings, so we use that mechansim to feed the values
listed on the multi-valued configuration variable (spell it out as
such, by the way, instead of saying "config option", which may give
a false impression that it is a last-one-wins single string with
many such mapping entries on it).

OK.

> Each value configured for the "http.hostResolve" key
> is passed "as is" to curl through CURLOPT_RESOLVE, so it
> should be in one of the above 2 forms. This keeps the
> implementation simple and makes us consistent with
> libcurl's CURLOPT_RESOLVE, and with curl's corresponding
> `--resolve` command line option.

OK.

> I am not sure if some tests could/should be added. Ideas about how to
> test this are welcome.

It should.  Perhaps invent a totally bogus domain name, map that to
localhost ::1, run a test server locally, and try to clone from that
bogus domain?

> +http.hostResolve::

Is "host" a good prefix for it?  

In the context of HTTP(s), if there is no other thing than host that
we resolve, "http.resolve" may be sufficient.  For those who are
looking for CURLOPT_RESOLVE equivalent, "http.curloptResolve" may
make it easier to find.

> +	Hostname resolve information that will be used first when sending
> +	HTTP requests.  This information should be in one of the following
> +	forms:
> +
> +	- [+]HOST:PORT:ADDRESS[,ADDRESS]
> +	- -HOST:PORT
> +
> ++
> +The first form redirects all requests to the given `HOST:PORT`
> +to the provided `ADDRESS`(s). The second form clears all previous
> +config values for that `HOST:PORT` combination.  To allow easy
> +overriding of all the settings inherited from the system config,
> +an empty value will reset all resolve information to the empty
> +list.

If I understand your use case correctly, this is not something you
would want to hardcode in your configuration files for long term, is
it?  I am wondering if we want to mention the expected use case here
as well, something like

    This is designed to be used primarily from the command line
    configuration variable override, e.g.

	$ git -c http.resolve=example.com:443:127.0.0.1 \
	    clone https://example.com/user/project.git

perhaps?  Not a suggestion, but soliciting thoughts.

> diff --git a/http.c b/http.c
> index 229da4d148..e9cc46ee52 100644
> --- a/http.c
> +++ b/http.c
> @@ -128,6 +128,9 @@ static struct curl_slist *pragma_header;
>  static struct curl_slist *no_pragma_header;
>  static struct string_list extra_http_headers = STRING_LIST_INIT_DUP;
>  
> +static struct curl_slist *host_resolves;
> +static struct string_list http_host_resolve = STRING_LIST_INIT_DUP;
> +
>  static struct active_request_slot *active_queue_head;
>  
>  static char *cached_accept_language;
> @@ -393,6 +396,17 @@ static int http_options(const char *var, const char *value, void *cb)
>  		return 0;
>  	}
>  
> +	if (!strcmp("http.hostresolve", var)) {
> +		if (!value) {
> +			return config_error_nonbool(var);
> +		} else if (!*value) {
> +			string_list_clear(&http_host_resolve, 0);


OK, this is a way to "clear" the list of entries accumulated on this
multi-valued configuration variable so far.  And it is documented in
the above, too.  Good.

> +		} else {
> +			string_list_append(&http_host_resolve, value);
> +		}
> +		return 0;
> +	}
> +
>  	if (!strcmp("http.followredirects", var)) {
>  		if (value && !strcmp(value, "initial"))
>  			http_follow_config = HTTP_FOLLOW_INITIAL;
> @@ -985,6 +999,17 @@ static void set_from_env(const char **var, const char *envname)
>  		*var = val;
>  }
>  
> +static struct curl_slist *http_copy_host_resolve(void)
> +{
> +	struct curl_slist *hosts = NULL;
> +	const struct string_list_item *item;
> +
> +	for_each_string_list_item(item, &http_host_resolve)
> +		hosts = curl_slist_append(hosts, item->string);
> +
> +	return hosts;
> +}
> +
>  void http_init(struct remote *remote, const char *url, int proactive_auth)
>  {
>  	char *low_speed_limit;
> @@ -1048,6 +1073,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
>  	no_pragma_header = curl_slist_append(http_copy_default_headers(),
>  		"Pragma:");
>  
> +	host_resolves = http_copy_host_resolve();

This is curious.  I imagined that the reason why you keep the
original in a string_list and copy it to a curl_slist was perhaps
because you'll lose the latter every time you make a curl request,
but it does not appear to be the case.  You http_init() just once
and then the same CURL *curl instance will be reused until you clear
it with http_cleanup().  So I do not see offhand the need to have
the string_list at all.

Does it work equally well if you used curl_slist_append() in
http_options() and maintain ONLY the curl_slist version of the
host_resolve list?  That would make it unnecessary to keep
http_host_resolve and add http_copy_host_resolve() function, no?

Thanks.
Christian Couder May 4, 2022, 10:07 a.m. UTC | #2
On Mon, May 2, 2022 at 9:04 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > Subject: Re: [PATCH] http: add custom hostname to IP address resolves
>
> I can guess what you means, but I am not able to quite parse the
> above.  I guess the phrase that makes me hiccup when I read is
> "resolve" used as a noun.

Ok, I will use "http: add custom hostname to IP address resolutions"
in the next version then.

> > Libcurl has a CURLOPT_RESOLVE easy option that allows
> > hostname resolve information in the following form to
>
> The same here, "... allows the result of hostname resolution in the
> following format ...", perhaps?

Ok, I will use your suggestion.

> > be passed:
> >
> >       [+]HOST:PORT:ADDRESS[,ADDRESS]
> >
> > This way, redirects and everything operating against the
> > HOST+PORT will use the provided ADDRESS(s).
> >
> > The following form is also allowed to stop using these
> > resolves:
> >
> >       -HOST:PORT
>
> The above is a reasonable summary of CURLOPT_RESOLVE documentation
> that is appropriate to have here for those of us who are not
> familiar with it.  For those of us who may want to learn more, it
> would help to have an URL to the canonical documentation page, e.g.
> https://curl.se/libcurl/c/CURLOPT_RESOLVE.html but it is not
> required.  People should be able to find it easily.

Yeah, I also thought that it wasn't required, but I will add it
anyway, as I agree it could be useful and hopefully it doesn't change
very often.

> > Let's add a corresponding "http.hostResolve" config
> > option that takes advantage of CURLOPT_RESOLVE.
>
> CURLOPT_RESOLVE allows us to feed cURL a list of these <host,port>
> -> <address> mappings, so we use that mechansim to feed the values
> listed on the multi-valued configuration variable (spell it out as
> such, by the way, instead of saying "config option", which may give
> a false impression that it is a last-one-wins single string with
> many such mapping entries on it).
>
> OK.
>
> > Each value configured for the "http.hostResolve" key
> > is passed "as is" to curl through CURLOPT_RESOLVE, so it
> > should be in one of the above 2 forms. This keeps the
> > implementation simple and makes us consistent with
> > libcurl's CURLOPT_RESOLVE, and with curl's corresponding
> > `--resolve` command line option.
>
> OK.
>
> > I am not sure if some tests could/should be added. Ideas about how to
> > test this are welcome.
>
> It should.  Perhaps invent a totally bogus domain name, map that to
> localhost ::1, run a test server locally, and try to clone from that
> bogus domain?

Ok, I will add a simple test like this.

> > +http.hostResolve::
>
> Is "host" a good prefix for it?
>
> In the context of HTTP(s), if there is no other thing than host that
> we resolve, "http.resolve" may be sufficient.  For those who are
> looking for CURLOPT_RESOLVE equivalent, "http.curloptResolve" may
> make it easier to find.

I am Ok with just "http.resolve". I think using "curlopt" is perhaps
going into too many details about the implementation of the feature,
which could theoretically change if we ever decided to use something
other than curl.

> > +     Hostname resolve information that will be used first when sending
> > +     HTTP requests.  This information should be in one of the following
> > +     forms:
> > +
> > +     - [+]HOST:PORT:ADDRESS[,ADDRESS]
> > +     - -HOST:PORT
> > +
> > ++
> > +The first form redirects all requests to the given `HOST:PORT`
> > +to the provided `ADDRESS`(s). The second form clears all previous
> > +config values for that `HOST:PORT` combination.  To allow easy
> > +overriding of all the settings inherited from the system config,
> > +an empty value will reset all resolve information to the empty
> > +list.
>
> If I understand your use case correctly, this is not something you
> would want to hardcode in your configuration files for long term, is
> it?

Right, but I wonder if there are other use cases where people would
like to hardcode it, for example on a private network where IP
addresses rarely change. Also a config option makes it more consistent
with "http.extraHeaders" and other such options.

> I am wondering if we want to mention the expected use case here
> as well, something like
>
>     This is designed to be used primarily from the command line
>     configuration variable override, e.g.
>
>         $ git -c http.resolve=example.com:443:127.0.0.1 \
>             clone https://example.com/user/project.git
>
> perhaps?  Not a suggestion, but soliciting thoughts.

I am also interested in others' thoughts about this. If no one thinks
that a config option could be useful, I am Ok with making it a
"--resolve" command line option that can be passed to any Git command
similar to "-c <name>=<value>":

git --resolve=... <command> [<args>]

> > diff --git a/http.c b/http.c
> > index 229da4d148..e9cc46ee52 100644
> > --- a/http.c
> > +++ b/http.c
> > @@ -128,6 +128,9 @@ static struct curl_slist *pragma_header;
> >  static struct curl_slist *no_pragma_header;
> >  static struct string_list extra_http_headers = STRING_LIST_INIT_DUP;
> >
> > +static struct curl_slist *host_resolves;
> > +static struct string_list http_host_resolve = STRING_LIST_INIT_DUP;
> > +
> >  static struct active_request_slot *active_queue_head;
> >
> >  static char *cached_accept_language;
> > @@ -393,6 +396,17 @@ static int http_options(const char *var, const char *value, void *cb)
> >               return 0;
> >       }
> >
> > +     if (!strcmp("http.hostresolve", var)) {
> > +             if (!value) {
> > +                     return config_error_nonbool(var);
> > +             } else if (!*value) {
> > +                     string_list_clear(&http_host_resolve, 0);
>
> OK, this is a way to "clear" the list of entries accumulated on this
> multi-valued configuration variable so far.  And it is documented in
> the above, too.  Good.
>
> > +             } else {
> > +                     string_list_append(&http_host_resolve, value);
> > +             }
> > +             return 0;
> > +     }
> > +
> >       if (!strcmp("http.followredirects", var)) {
> >               if (value && !strcmp(value, "initial"))
> >                       http_follow_config = HTTP_FOLLOW_INITIAL;
> > @@ -985,6 +999,17 @@ static void set_from_env(const char **var, const char *envname)
> >               *var = val;
> >  }
> >
> > +static struct curl_slist *http_copy_host_resolve(void)
> > +{
> > +     struct curl_slist *hosts = NULL;
> > +     const struct string_list_item *item;
> > +
> > +     for_each_string_list_item(item, &http_host_resolve)
> > +             hosts = curl_slist_append(hosts, item->string);
> > +
> > +     return hosts;
> > +}
> > +
> >  void http_init(struct remote *remote, const char *url, int proactive_auth)
> >  {
> >       char *low_speed_limit;
> > @@ -1048,6 +1073,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
> >       no_pragma_header = curl_slist_append(http_copy_default_headers(),
> >               "Pragma:");
> >
> > +     host_resolves = http_copy_host_resolve();
>
> This is curious.  I imagined that the reason why you keep the
> original in a string_list and copy it to a curl_slist was perhaps
> because you'll lose the latter every time you make a curl request,
> but it does not appear to be the case.  You http_init() just once
> and then the same CURL *curl instance will be reused until you clear
> it with http_cleanup().  So I do not see offhand the need to have
> the string_list at all.

Ok, I will remove it.

> Does it work equally well if you used curl_slist_append() in
> http_options() and maintain ONLY the curl_slist version of the
> host_resolve list?  That would make it unnecessary to keep
> http_host_resolve and add http_copy_host_resolve() function, no?

Yeah, right. I will remove http_host_resolve and http_copy_host_resolve().

Thanks!
Junio C Hamano May 4, 2022, 2:34 p.m. UTC | #3
Christian Couder <christian.couder@gmail.com> writes:

>> The above is a reasonable summary of CURLOPT_RESOLVE documentation
>> that is appropriate to have here for those of us who are not
>> familiar with it.  For those of us who may want to learn more, it
>> would help to have an URL to the canonical documentation page, e.g.
>> https://curl.se/libcurl/c/CURLOPT_RESOLVE.html but it is not
>> required.  People should be able to find it easily.
>
> Yeah, I also thought that it wasn't required, but I will add it
> anyway, as I agree it could be useful and hopefully it doesn't change
> very often.

Ah, I didn't consider the URL going stale at all.  Forcing readers
to look for the keyword certainly is a way to avoid it, but they
will do that once they realize URL went stale, so there is not a
strong incentive to avoid recording the now-current URL, I would
think.

>> > +http.hostResolve::
>>
>> Is "host" a good prefix for it?
>>
>> In the context of HTTP(s), if there is no other thing than host that
>> we resolve, "http.resolve" may be sufficient.  For those who are
>> looking for CURLOPT_RESOLVE equivalent, "http.curloptResolve" may
>> make it easier to find.
>
> I am Ok with just "http.resolve". I think using "curlopt" is perhaps
> going into too many details about the implementation of the feature,
> which could theoretically change if we ever decided to use something
> other than curl.

You may want to step back a bit and rethink.

Even if we decide to rewrite that part of the system not to depend
on cURL, end-user facing documented interface, i.e. how the mappings
are given to the system, will stay with us, and it is clear that it
was modeled after CURLOPT_RESOLVE---well, it was stolen from them
verbatim ;-).

So we may wean ourselves off of cURL, but CURLOPT_RESOLVE will stay
with us for this particular feature.

>> I am wondering if we want to mention the expected use case here
>> as well, something like
>>
>>     This is designed to be used primarily from the command line
>>     configuration variable override, e.g.
>>
>>         $ git -c http.resolve=example.com:443:127.0.0.1 \
>>             clone https://example.com/user/project.git
>>
>> perhaps?  Not a suggestion, but soliciting thoughts.
>
> I am also interested in others' thoughts about this. If no one thinks
> that a config option could be useful, I am Ok with making it a
> "--resolve" command line option that can be passed to any Git command
> similar to "-c <name>=<value>":
>
> git --resolve=... <command> [<args>]

Absolutely not.

"git [push|fetch|clone|ls-remote] --dns-pre-resolve=..." that is
*NOT* git wide, but is only for transport commands might be a
possibility, but even then, you'd need to invent a way to do the
same for non cURL transports (we want to be able to pin the IP when
going over SSH to a certain host, for the same reason) if we promote
it to an officially supported command line option.

Unless we do that, it is probably better to leave it as an obscure
configuration meant to help server operators.  At least, with the
name of the configuration variable prefixed with http.*, we have a
valid excuse when somebody complains "the feature does not do
anything for git:// transport".

Thanks.
Christian Couder May 5, 2022, 10:48 a.m. UTC | #4
On Wed, May 4, 2022 at 4:34 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:

> > I am Ok with just "http.resolve". I think using "curlopt" is perhaps
> > going into too many details about the implementation of the feature,
> > which could theoretically change if we ever decided to use something
> > other than curl.
>
> You may want to step back a bit and rethink.
>
> Even if we decide to rewrite that part of the system not to depend
> on cURL, end-user facing documented interface, i.e. how the mappings
> are given to the system, will stay with us, and it is clear that it
> was modeled after CURLOPT_RESOLVE---well, it was stolen from them
> verbatim ;-).
>
> So we may wean ourselves off of cURL, but CURLOPT_RESOLVE will stay
> with us for this particular feature.

Yeah, the CURLOPT_RESOLVE format will stay with us, so Ok, I will
rename it "http.curloptResolve" in the next iteration then.

> >> I am wondering if we want to mention the expected use case here
> >> as well, something like
> >>
> >>     This is designed to be used primarily from the command line
> >>     configuration variable override, e.g.
> >>
> >>         $ git -c http.resolve=example.com:443:127.0.0.1 \
> >>             clone https://example.com/user/project.git
> >>
> >> perhaps?  Not a suggestion, but soliciting thoughts.
> >
> > I am also interested in others' thoughts about this. If no one thinks
> > that a config option could be useful, I am Ok with making it a
> > "--resolve" command line option that can be passed to any Git command
> > similar to "-c <name>=<value>":
> >
> > git --resolve=... <command> [<args>]
>
> Absolutely not.
>
> "git [push|fetch|clone|ls-remote] --dns-pre-resolve=..." that is
> *NOT* git wide, but is only for transport commands might be a
> possibility, but even then, you'd need to invent a way to do the
> same for non cURL transports (we want to be able to pin the IP when
> going over SSH to a certain host, for the same reason) if we promote
> it to an officially supported command line option.

Ok with renaming and implementing it only in transport commands. I
don't want, and I don't think it should be necessary, to invent a way
to do the same for non cURL transports though. I think it should be Ok
with the doc saying that the option has only been implemented for
HTTP(S) yet and will have no effect when other transports are used.

If there is a simple way to do the same thing for ssh, then I might
take a look at it later. For "file" or bundle transports, I don't
think it makes sense, and the "git" transport is not used much in big
hosting services where this feature is likely to be used.

> Unless we do that, it is probably better to leave it as an obscure
> configuration meant to help server operators.  At least, with the
> name of the configuration variable prefixed with http.*, we have a
> valid excuse when somebody complains "the feature does not do
> anything for git:// transport".

I am happy with leaving it as an obscure configuration meant to help
server operators. So I will just rename it "http.curloptResolve" in
the next iteration.

Thanks!
Carlo Marcelo Arenas Belón May 5, 2022, 11:16 a.m. UTC | #5
On Thu, May 05, 2022 at 12:48:50PM +0200, Christian Couder wrote:
> On Wed, May 4, 2022 at 4:34 PM Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > I am also interested in others' thoughts about this. If no one thinks
> > > that a config option could be useful, I am Ok with making it a
> > > "--resolve" command line option that can be passed to any Git command
> > > similar to "-c <name>=<value>":
> > >
> > > git --resolve=... <command> [<args>]
> >
> > Absolutely not.
> >
> > "git [push|fetch|clone|ls-remote] --dns-pre-resolve=..." that is
> > *NOT* git wide, but is only for transport commands might be a
> > possibility, but even then, you'd need to invent a way to do the
> > same for non cURL transports (we want to be able to pin the IP when
> > going over SSH to a certain host, for the same reason) if we promote
> > it to an officially supported command line option.
> 
> Ok with renaming and implementing it only in transport commands. I
> don't want, and I don't think it should be necessary, to invent a way
> to do the same for non cURL transports though. I think it should be Ok
> with the doc saying that the option has only been implemented for
> HTTP(S) yet and will have no effect when other transports are used.

I think it will be better if git aborts with an error if it is used for
a transport that it doesn't support, instead of relying in the documentation,
though.
 
> If there is a simple way to do the same thing for ssh, then I might
> take a look at it later. For "file" or bundle transports, I don't
> think it makes sense, and the "git" transport is not used much in big
> hosting services where this feature is likely to be used.

This seems definitely useful also for ssh which is also used in big
hosting services.

Ironically, I think would be even more useful for the "git" transport
specially because it doesn't have other protections to rely on that
would help prevent spoofing (like TLS), which might be also why it is
not that widely used anymore.

Carlo
Christian Couder May 9, 2022, 3:40 p.m. UTC | #6
On Thu, May 5, 2022 at 1:16 PM Carlo Marcelo Arenas Belón
<carenas@gmail.com> wrote:
> On Thu, May 05, 2022 at 12:48:50PM +0200, Christian Couder wrote:

> > Ok with renaming and implementing it only in transport commands. I
> > don't want, and I don't think it should be necessary, to invent a way
> > to do the same for non cURL transports though. I think it should be Ok
> > with the doc saying that the option has only been implemented for
> > HTTP(S) yet and will have no effect when other transports are used.
>
> I think it will be better if git aborts with an error if it is used for
> a transport that it doesn't support, instead of relying in the documentation,
> though.

This has drawbacks, as this is likely to be called through scripts or
apps and the calling code would have to be a bit more complex as
passing the option couldn't be done independently of the transport/URL
used.

Anyway until others complain, I prefer to leave it as an obscure
configuration called "http.curloptResolve" and meant to help server
operators as Junio says. This avoids wondering about such issues.

> > If there is a simple way to do the same thing for ssh, then I might
> > take a look at it later. For "file" or bundle transports, I don't
> > think it makes sense, and the "git" transport is not used much in big
> > hosting services where this feature is likely to be used.
>
> This seems definitely useful also for ssh which is also used in big
> hosting services.

I am not sure it is as useful for ssh. And maybe someone will take a
look at implementing it if that's the case.

> Ironically, I think would be even more useful for the "git" transport
> specially because it doesn't have other protections to rely on that
> would help prevent spoofing (like TLS), which might be also why it is
> not that widely used anymore.

Yeah, more secure alternatives have taken over for good.
diff mbox series

Patch

diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt
index 7003661c0d..37b293a73b 100644
--- a/Documentation/config/http.txt
+++ b/Documentation/config/http.txt
@@ -98,6 +98,22 @@  http.version::
 	- HTTP/2
 	- HTTP/1.1
 
+http.hostResolve::
+	Hostname resolve information that will be used first when sending
+	HTTP requests.  This information should be in one of the following
+	forms:
+
+	- [+]HOST:PORT:ADDRESS[,ADDRESS]
+	- -HOST:PORT
+
++
+The first form redirects all requests to the given `HOST:PORT`
+to the provided `ADDRESS`(s). The second form clears all previous
+config values for that `HOST:PORT` combination.  To allow easy
+overriding of all the settings inherited from the system config,
+an empty value will reset all resolve information to the empty
+list.
+
 http.sslVersion::
 	The SSL version to use when negotiating an SSL connection, if you
 	want to force the default.  The available and default version
diff --git a/http.c b/http.c
index 229da4d148..e9cc46ee52 100644
--- a/http.c
+++ b/http.c
@@ -128,6 +128,9 @@  static struct curl_slist *pragma_header;
 static struct curl_slist *no_pragma_header;
 static struct string_list extra_http_headers = STRING_LIST_INIT_DUP;
 
+static struct curl_slist *host_resolves;
+static struct string_list http_host_resolve = STRING_LIST_INIT_DUP;
+
 static struct active_request_slot *active_queue_head;
 
 static char *cached_accept_language;
@@ -393,6 +396,17 @@  static int http_options(const char *var, const char *value, void *cb)
 		return 0;
 	}
 
+	if (!strcmp("http.hostresolve", var)) {
+		if (!value) {
+			return config_error_nonbool(var);
+		} else if (!*value) {
+			string_list_clear(&http_host_resolve, 0);
+		} else {
+			string_list_append(&http_host_resolve, value);
+		}
+		return 0;
+	}
+
 	if (!strcmp("http.followredirects", var)) {
 		if (value && !strcmp(value, "initial"))
 			http_follow_config = HTTP_FOLLOW_INITIAL;
@@ -985,6 +999,17 @@  static void set_from_env(const char **var, const char *envname)
 		*var = val;
 }
 
+static struct curl_slist *http_copy_host_resolve(void)
+{
+	struct curl_slist *hosts = NULL;
+	const struct string_list_item *item;
+
+	for_each_string_list_item(item, &http_host_resolve)
+		hosts = curl_slist_append(hosts, item->string);
+
+	return hosts;
+}
+
 void http_init(struct remote *remote, const char *url, int proactive_auth)
 {
 	char *low_speed_limit;
@@ -1048,6 +1073,8 @@  void http_init(struct remote *remote, const char *url, int proactive_auth)
 	no_pragma_header = curl_slist_append(http_copy_default_headers(),
 		"Pragma:");
 
+	host_resolves = http_copy_host_resolve();
+
 	{
 		char *http_max_requests = getenv("GIT_HTTP_MAX_REQUESTS");
 		if (http_max_requests != NULL)
@@ -1124,6 +1151,7 @@  void http_cleanup(void)
 	curl_global_cleanup();
 
 	string_list_clear(&extra_http_headers, 0);
+	string_list_clear(&http_host_resolve, 0);
 
 	curl_slist_free_all(pragma_header);
 	pragma_header = NULL;
@@ -1131,6 +1159,9 @@  void http_cleanup(void)
 	curl_slist_free_all(no_pragma_header);
 	no_pragma_header = NULL;
 
+	curl_slist_free_all(host_resolves);
+	host_resolves = NULL;
+
 	if (curl_http_proxy) {
 		free((void *)curl_http_proxy);
 		curl_http_proxy = NULL;
@@ -1211,6 +1242,7 @@  struct active_request_slot *get_active_slot(void)
 	if (curl_save_cookies)
 		curl_easy_setopt(slot->curl, CURLOPT_COOKIEJAR, curl_cookie_file);
 	curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header);
+	curl_easy_setopt(slot->curl, CURLOPT_RESOLVE, host_resolves);
 	curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, curl_errorstr);
 	curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, NULL);
 	curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, NULL);