Allow non-latin1 credentials

Referring to #1926
Maybe I am wrong, but my understanding was that header fields must be latin-1 encoded.
This is awlays true for Basic Authentication headers, since base64 encoded strings consist of plain ascii.  
I would think however that `<username>:<password>` may contain special characters, as long as client and server assume the same encoding (for example utf8).

This code currently encodes the credentials:

``` py
def _basic_auth_str(username, password):
    """Returns a Basic Auth string."""

    authstr = 'Basic ' + to_native_string(
        b64encode(('%s:%s' % (username, password)).encode('latin1')).strip()
    )

    return authstr
```

but could be changed to encode the base64 header string instead:

``` py
        ...
        b64encode(('%s:%s' % (username, password))).encode('latin1').strip()
```


I _think_ I'm ok with this change. I think we need to confirm it functions as expected on Python 3, though.


> I think we need to confirm it functions as expected on Python 3, though.

Did you address _me_ with '_we_'?

I guess there should be tests that pass username and passwords as binary strings, unicode, and mixed.
(The `.encode('latin1')` could probably be replaced by `.encode(ascii)` to point out that it's purpose is now only to convert the `b64encode()` result to a binary ascii sequence.)

Anyway, my main concern would be a risk analysis, since I am not 100% sure what the consequences of this change will be.  
The current implementation (if I understand correctly) would make it impossible to pass a Chinese username, for example. My suggested change would allow the client to pass any string if he decides to use UTF-8.

The problem seems to be due to a gap in the original spec . I looked around a bit and found some references:

http://stackoverflow.com/a/7243567/19166 , which seems to refer to this latest version https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-07

Maybe you want to discuss with your team.


> Did you address me with 'we'?

I addressed the collective world of people paying attention to this bug. =) It was code for "I have identified this missing work item but do not have time to deal with it right now."

> https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-07

That draft has expired, sadly.

I don't think this change is in violation of any RFC, I think it's reasonable. I may want to try to test it with a few other UAs and see what they do, e.g. curl, before deciding on this as a proposal.


Cool :) There is no hurry from my side, since we currently pass the credentials directly using `headers` instead of `auth`. 
Thanks for taking the time and working on a really great library!

(Btw, draft 07 will expire sept.'15)


Ok, this change doesn't work. On Python 3, `b64encode` takes a bytestring. This means the encode _has_ to happen first.

On balance, I think using Latin1 for this space of the code is roughly right, until such time as the `charset` enhancement to Basic Auth lands.


Ok, I see. 
My original idea was, to let the caller choose its preferred encoding by (optionally) passing bytestrings to the `auth` argument. But then the `"%s"` approach breaks on Py3:

``` py
>>> user = b"joe"
>>> password = b"secret"
>>> "%s:%s" % (user, password)
"b'joe':b'secret'"
>>> 
```

Maybe s.th. like this could work:

``` py
b64encode(to_binary(username) + to_binary(":") + to_binary(password)).strip()
```

where `to_binary(x)` encodes unicode using latin1 but is a no-op if _x_ is a already a binarystring.
But i am not sure if it is worth the effort...

Simply allowing to override the 'latin1' default encoding in your original code could be a simpler solution.
Or we may simply close this PR :)


I think if there is really a concern about Latin 1, users should override the auth logic themselves and provide the header manually. With requests things like this are all about trade-offs, and in this case I reckon we hit about 80% of the use-case here with none of the complexity.

At this point, unless there's any objections, I think this might be fine as-is.


no objections, we may close it (not sure if Western Europe + US users make up for 80% though ;-)