Should use the user-provided Host header for SNI #414
Comments
|
The easiest way to get this to work in the short term is to update your hosts file to point to the host in question. This will enable you to avoid needing to set the Host header as well. In the longer term, I could see some value in HTTPie doing something similar to what curl does, or possibly even something a bit simpler that just works for SNI if we're happy to let people keep setting custom Host headers. Note, however, that a lot of other things will get done wrong if you set a custom host header. For example, httpie probably won't handle cookies the way you expect. So using the hosts file is the better solution in the general case. Works for all your other tools too! |
|
Good point about cookies! What about then? I don't like curl's I don't like the /etc/hosts solution because:
|
|
Yeah, curl's --resolve solution may be overkill in this case.
You can use the HOSTALIASES environment variable to point at a file in your own part of the namespace that is used as a hosts file. That allows you to do something like |
|
Thank you, I didn't know about HOSTALIASES! (It still feels like extra work, compared to a command-line argument. Would you look favorably upon a pull request that implemented a |
|
I am not a maintainer of httpie, so I can't speak for @jkbrzt. However, the idea certainly doesn't bother me. =) |
|
NB: the suggested |
|
HOSTALIASES only works for "name[s] consist[ing] of a single component, that is, contains no dot", ref: http://man7.org/linux/man-pages/man7/hostname.7.html |
|
|
Unless this is done, the SNI server name will not be sent, often making the curl/httpie command have different behaviour than the original request (most often in the form of failing to establish a TLS connection). With this change, we always use the original host, fixing this failure. However, if the original host is a domain, it may sometimes resolve to a different IP address later on. In curl, we solve this problem by forcing it to connect to the original IP using `--resolve`. For httpie there is currently no easy solution (see: httpie/cli#414).
Unless this is done, the SNI server name will not be sent, often making the curl/httpie command have different behaviour than the original request (most often in the form of failing to establish a TLS connection). With this change, we always use the original host, fixing this failure. However, if the original host is a domain, it may sometimes resolve to a different IP address later on. In curl, we solve this problem by forcing it to connect to the original IP using `--resolve`. For httpie there is currently no easy solution (see: httpie/cli#414).
Unless this is done, the SNI server name will not be sent, often making the curl/httpie command have different behaviour than the original request (most often in the form of failing to establish a TLS connection). With this change, we always use the original host, fixing this failure. However, if the original host is a domain, it may sometimes resolve to a different IP address later on. In curl, we solve this problem by forcing it to connect to the original IP using `--resolve`. For httpie there is currently no easy solution (see: httpie/cli#414).
…4307) Use original flow host instead of IP when exporting to curl/httpie. Unless this is done, the SNI server name will not be sent, often making the curl/httpie command have different behaviour than the original request (most often in the form of failing to establish a TLS connection). With this change, we always use the original host, fixing this failure. However, if the original host is a domain, it may sometimes resolve to a different IP address later on. In curl, we solve this problem by forcing it to connect to the original IP using `--resolve`. For httpie there is currently no easy solution (see: httpie/cli#414).
|
Sad this looks stale, something like |
|
Related: #99 (comment) |
|
I'm looking for a way to specify different hosts for connection, TLS and HTTP. Something like, where I expect the client connect to the IP of the |
I'm trying to test Apache configuration in a Vagrant VM that forwards port 8443 to VM's port 443. The command I'm running is:
and I get a 400 Bad Request from Apache, because
I think httpie should use the user-provided Host header for the SSL negotiation, or perhaps even provide a command-line option to explicitly specify a hostname to use in SNI.
The text was updated successfully, but these errors were encountered: