The Host header is ignored?

I am unable to create a request using a relative path, even when I set the Host header.

`requests.exceptions.MissingSchema: Invalid URL '/wiki/List_of_HTTP_header_fields': No schema supplied. Perhaps you meant http:///wiki/List_of_HTTP_header_fields?`

I expect to be able to configure a Host header and use it in my request:

    headers = {'Host':  'en.wikipedia.org/wiki' }
    
    resp = requests.get("/List_of_HTTP_header_fields",  headers=headers)
    resp = requests.get("/Virtual_hosting", headers=headers)

> The domain name of the server (for virtual hosting), and the TCP port number on which the server is listening. The port number may be omitted if the port is the standard port for the service requested. (Mandatory since HTTP/1.1)



Thanks for this!

I don't know why you expect to be able to do this: Requests has never allowed this, and never documented that it would be possible. We very intentionally require that users provide absolute URIs so there is no ambiguity: for example, in your examples above should Requests be using HTTP or HTTPS?

This is just not how Requests works. 

I expected this to work as it is part of the protocol (HTTP/1.1):

> The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:

       GET /pub/WWW/TheProject.html HTTP/1.1
       Host: www.w3.org

I can see how this is a can of worms from a security perspective and it deserves a warning. But when I set a hostname manually following the spec I do expect it to work. 

You know way more about the subject then I do, so I really appreciate your feedback. Either way the error messaging can be improved as I clearly did not intent to go here: `http:///wiki/List_of_HTTP_header_fields` (Check for forward slash character?)

Requests is a high-level HTTP library: it performs a number of transformations for you. Ultimately, if you want to be able to craft low-level HTTP requests like this, Requests is not the tool for you: its value comes entirely from providing high-level abstractions and transforming them into the low-level Python bytes format.

Specifically, if you do `requests.get('http://host/some/path')`, that will lead to Requests sending:

```
GET /some/path HTTP/1.1
Host: host
```

In general, Requests does not introspect user headers: they are considered to be opaque bytes from our perspective. URLs, however, are structured data, and thus make a much better way to provide us with information about the host you want.

That is cool, I did not realise Requests is automatically generating the Host header. I assumed the Host header was empty and Requests kept full path in the GET command.

I think this issue needs two action points:

1. Update [Request Manual Custom Headers](http://docs.python-requests.org/en/master/user/quickstart/#custom-headers) to include Host headers info:

- Authorization headers set with headers= will be overridden if credentials are specified in .netrc, which in turn will be overridden by the auth= parameter.
- Authorization headers will be removed if you get redirected off-host.
- Proxy-Authorization headers will be overridden by proxy credentials provided in the URL.
- Content-Length headers will be overridden when we can determine the length of the content.
- Host headers will be removed, they are automatically generated by Requests.

2. Create seperate error to make `Invalid URL` more clear. Checking for single forward slash should make clear user is trying to use relative path? Something like `No host found in URL`

Host headers will not be removed: we will let you override them, we just don't let them affect our processing at all. But yes, a PR that adds a note about Host headers to that section is a good idea. 

As to `Invalid URL`, we can certainly do it, but I'm not sure how useful it is. This really doesn't come up very often, as evidenced by the fact that this is the first time in the seven year history of this project that anyone has had this problem. Still, I'm happy to review a pull request adding that to see how it looks.