Whitepace characters surrounding a URL should be ignored

It might be beneficial to unite the behavior with other tools (including browsers) and start ignoring whitespaces surrounding a URL. See the examples:

```
$ curl -s "https://github.com/ " -o /dev/null -w "%{http_code}"; echo
200

$ python -c 'import urllib2; print(urllib2.urlopen("https://github.com/ ").getcode())'
200

$ python -c 'import requests; print(requests.get("https://github.com/ ").status_code)'
404
```

Also, W3C [defines](https://www.w3.org/TR/2012/WD-html5-20121025/links.html#attr-hyperlink-href) the `a` tag's `href` attribute as...

> The href attribute on a and area elements must have a value that is a valid URL potentially surrounded by spaces.

Where _URL potentially surrounded by spaces_ is [defined](https://www.w3.org/TR/2012/WD-html5-20121025/urls.html#valid-url-potentially-surrounded-by-spaces) as...

> A string is a valid non-empty URL potentially surrounded by spaces if, after stripping leading and trailing whitespace from it, it is a valid non-empty URL.

I know this is not a killer argument for the requests library but it would be beneficial if it behaved the same way as the other approaches. It would also make HTML processing with requests (and e.g. beautifulsoup4) easier.


I have no objection to calling `strip` on a URL that's passed into requests.


Do we currently `%20` these?


Yes.


> I have no objection to calling strip on a URL that's passed into requests.

Do you mean the requests should do it or the caller?

I may be very well mistaken but it might be enough to add a `url.strip()` call to the [`PreparedRequest.prepare_url()` method](https://github.com/kennethreitz/requests/blob/master/requests/models.py#L324), right?


I mean that I have no objection to requests doing that.


I'm prone to saying that calling `strip()` is fine as well, but it does also seem a bit silly to do that — I hardly doubt that this issue comes up very often, and the user is very explicitly specifying that there is a space in the URL. 

I suppose, if someone wants a space at the end of a URL, they'll just have to `%20` it themselves.

I am also prone to having us send the URL they provided us with, though (our current behavior). A URL ending in a space is perfectly valid. By stripping, we're assuming a correction for a user mistake. 


I can't say how often this comes up but I encountered it while rewriting my code from using `urllib2` to `requests`. What worked before, didn't work with `requests` anymore and that's how I found the issue.

The `strip()` isn't really supposed to help those who _want to_ have spaces in their URLs but those who need to process such HTML :)


We are an HTTP library, not an HTML library :)

However, this may make things easier for some humans. 


Of course I know, that's why I mentioned this not being a strong argument for `requests` in the original post. But as you say, it makes things easier.

Of course I can call the `strip()` myself. It only seems easier the other way and since urllib2 (and others) do it, I thought it would be nice to have it in `requests` as well.


I'm fine with us doing it; it won't hurt anything. But, I think it's dumb. 

The whole thing, that is, not your suggestion @geckon :)


Eh, my webbrowser does it. I'm in.


So this could break people who expect us to percent encode the space at the end of a string, can we please not BGB merge this to 2.x and instead put it off until 3.x?


> Eh, my webbrowser does it. I'm in.

Yep, I mentioned browsers in my original post as well.


@geckon sorry I missed that!


Generally, my experience with HTTP via web browser is _fantastic_, so I modeled a lot of the design around those experiences. So, in this case, this is definitely something we should be doing. 


Closing since this merged to `proposed/3.0.0` and will be released with 3.0