UnicodeDecodeError on redirect response rfc1804 to non ascii location

This issue happend to me on our production servers while requesting URL from the wild using requests.

When a server returns redirect response that follows rfc1808 (i.e. Location: //URI) and the URI contains non ASCII chars, requests fails with UnicodeDecodeError. 

This issue only happens on python2 (in python3 unicode is the default text string so all headers encoded into unicode, including the Location header).

test to reproduce:

```python
def test_redirect_rfc1808_to_non_ascii_location():
    def redirect_resp_handler(sock):
        request_content = consume_socket_content(sock, timeout=0.5)
        sock.send(text_301)
        return request_content

    close_server = threading.Event()
    server = Server(redirect_resp_handler, wait_to_close_event=close_server)
    text_301 = (
        u'HTTP/1.1 301 Moved Permanently\r\n'
        u'Location: //{0}:{1}/?Š\r\n'
        u'\r\n'.format(server.host, server.port)
    ).encode('utf8')

    with server as (host, port):
        url = u'http://{0}:{1}/'.format(host, port)
        r = requests.head(url=url, allow_redirects=True)
        assert r.status_code == 200
        assert len(r.history) == 1
        assert r.history[0].status_code == 301
        close_server.set()
```

AFAIK from [here](http://stackoverflow.com/questions/4400678/what-character-encoding-should-i-use-for-a-http-header), header fields should be US-ASCII encoded and must not contain non-ASCII chars, but the internet is a wild place so this things happen.

IMHO its the server response to return the location in urlencoded format but requests shouldn't fail on this error (maybe more informative error) or at least be consistent with python2 and python3 behavior.

**I can create a PR for fixing the issue but I'm not sure what is the best solution**, options are (what I can think of):
1. raise custom exception when Location field is not ASCII (might be inconsistent with previous versions)
2. try encode the Location field to utf8 and raise exception if encoding fails
3. on python2 decode all headers into unicode, similar to python3 (might break previous versions compatibility)

**stacktrace (on master branch):**

```python
UnicodeDecodeError                        Traceback (most recent call last)
<ipython-input-4-24640a4df79e> in <module>()
----> 1 resp = requests.head('https://www.autobazar.eu/skoda-fabia-19-tdi-pd-rs-id9323271.html', allow_redirects=True)

/home/shmulik/so/requests/requests/api.py in head(url, **kwargs)
     96 
     97     kwargs.setdefault('allow_redirects', False)
---> 98     return request('head', url, **kwargs)
     99 
    100 

/home/shmulik/so/requests/requests/api.py in request(method, url, **kwargs)
     56     # cases, and look like a memory leak in others.
     57     with sessions.Session() as session:
---> 58         return session.request(method=method, url=url, **kwargs)
     59 
     60 

/home/shmulik/so/requests/requests/sessions.py in request(self, method, url, params, data, headers, cookies, files, auth, timeout, allow_redirects, proxies, hooks, stream, verify, cert, json)
    496         }
    497         send_kwargs.update(settings)
--> 498         resp = self.send(prep, **send_kwargs)
    499 
    500         return resp

/home/shmulik/so/requests/requests/sessions.py in send(self, request, **kwargs)
    638 
    639         # Resolve redirects if allowed.
--> 640         history = [resp for resp in gen] if allow_redirects else []
    641 
    642         # Shuffle things around if there's history.

/home/shmulik/so/requests/requests/sessions.py in resolve_redirects(self, resp, req, stream, timeout, verify, cert, proxies, **adapter_kwargs)
    123             if url.startswith('//'):
    124                 parsed_rurl = urlparse(resp.url)
--> 125                 url = '%s:%s' % (parsed_rurl.scheme, url)
    126 
    127             # The scheme should be lower case...

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 120: ordinal not in range(128)
```

example response running curl  (I removed the real url):

```bash
$ curl -vvv "http://some-url.com"
....
< HTTP/1.1 301 Moved Permanently
< Server: Apache
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Location: //some-url.com/Š
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
```


Thanks,
Shmulik

Thanks for this detailed report! This is a dupe of #3888: that has some discussions about how we might handle this if you're interested in supplying a patch. Additional suggestions on that thread would be welcomed if you don't like any of the proposed approaches. 

thanks for the quick reply! missed it when searching the issues.

Although its related to the Location header issue, when further digging into requests, I think it might be more of encoding issue.

looking at the following code (from [here](https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L122))

```python
            # Handle redirection without scheme (see: RFC 1808 Section 4)
            if url.startswith('//'):
                parsed_rurl = urlparse(resp.url)
                url = '%s:%s' % (parsed_rurl.scheme, url)
``` 

on python2, `urlparse(u'http://google.com').scheme` is a unicode string.
for `urlparse('http://google.com').scheme` is an str.

on python2, when the original URL is unicode, it is parsed as `str % (unicode, str)` and the error occurs.
on python3, it is parsed as `str % (str, str)` and all is fine.

IMHO, this specific issue (on  handling RFC1808) can be fixed by adding `to_native_string(parsed_rurl.scheme)`.

```python
            # Handle redirection without scheme (see: RFC 1808 Section 4)
            if url.startswith('//'):
                parsed_rurl = urlparse(resp.url)
                url = '%s:%s' % (to_native_string(parsed_rurl.scheme), url)
```

please tell me what you think, if you think it is relevant I can open some PR with the change and the test.

Thanks,
Shmulik

As #3888 notes, it's an encoding issue that affects headers generally: it just tends to manifest most noticeably here.

However, you're right that certain manifestations can be resolved by preventing an automatic decode of the header string on Python 2. I'd be willing to review and merge a PR for that failure that includes a test. 😁