Add equivalent cURL --resolve flag

[theladyjaye]

Per cURL --help:

--resolve HOST:PORT:ADDRESS Force resolve of HOST:PORT to ADDRESS

(bypasses hosts file)

example usage:

http --resolve "www.foo.com:127.0.0.1" GET www.foo.com/whatever

OR

http --resolve "www.foo.com:8080:127.0.0.1" GET www.foo.com:8080/whatever

[jkbrzt]

I think you can achieve the same thing by explicitly setting the Host header:

http 127.0.0.1/whatever Host:www.foo.com

[CMCDragonkai]

The above trick doesn't work for HTTPS sites. We need a full resolve option similar to curl.

[MadMub]

I'm using httpie to test that I setup my DNS round-robin correctly. +1 for feature

[aztlan2k]

Just curious... This has been open for over a year now (since it was reopened)... any chance it's getting looked at? Seems like a useful feature to have.

[sigmavirus24]

The underlying software that HTTPie uses does not allow people to specify their own IP addresses for a specific host. It's unlikely it will be added there. So, @aztlan2k it's not likely this is being worked on. Sorry. :/

[ghost]

Hi! I've submitted some code and would appreciate any comments.

[ghost]

Just re-submitted via another PR. Would you mind to check?

[pcgeek86]

Any chance of getting this merged? @jakubroztocil

[gregfr]

That would be great to prepare site migration and avoid problems!

[dimisjim]

This can be achieved via dig +short <host> A. It's a DNS thing, not really HTTP

[lapo-luchini]

dig is used to query the DNS, the proposed --resove is used to force resolution of an address during an HTTP fetch (probably to a value the DNS server doesn't yet have but will have in the future, after this testing is done).
It's rather an alternative to editing /etc/hosts than it is to using dig (or drill, or similar).

[tn-osimis]

In case anybody is confused as to why this is needed "for HTTPS", it's specifically when TLS SNI (Server Name Indication) is used in place of the HTTP Host header to disambiguate connections (e.g. hostname-based L7 routing in reverse-proxies, or "virtual server" use-cases in general), which is extremely common.

In that context, resolving the IP beforehand isn't sufficient as it won't constitute a virtual server name expected by the actual server.

If an equivalent to --resolve isn't desirable for any reason, forcing the SNI value (e.g. --sni) would be an acceptable alternative IMO since we can already do the equivalent for plain HTTP (i.e. set the Host header value explicitly).

[segevfiner]

This can also be useful for absolute redirects (That include a full URL with a host name)

[Almad]

Looking into it, there are basically two options how to fix this:

• Work with requests/urllib3 to add support to the lower-level libraries. There is a PR for this at Add support for DNS hijacking urllib3/urllib3#1209 , which got abandoned during their "stale PR purge". Picking it up and working with urllib3 to add it is an option. Also see End to End TLS + SNI with proxy psf/requests#4293
• Monkeypatch sockets. This was proposed in #99 - add --resolve option #659

The strong preference would be for the first solution. Custom wrapping and monkeypatching often leads to unintended consequences as the Python interpreter and surrounding libraries develop and often leads to "hidden" bugs.

Help with getting the patch rolling for the urllib3 would be very welcome! Otherwise, we may look into it in the future, but other features have higher priority.

[hussam-qasem]

Greetings! I just realized this thread is over 10 years old.
Is the status (blocked by upstream) still current?
Thank you!!