Testsuite failure

Python 2.7.6 / macports, OS X 10.8.5, requests 2.2.1

```
======================================================================
FAIL: test_mixed_case_scheme_acceptable (test_requests.RequestsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "requests/test_requests.py", line 104, in test_mixed_case_scheme_acceptable
    assert r.status_code == 200, 'failed for scheme {0}'.format(scheme)
AssertionError: failed for scheme HTTP://
    'HTTP://httpbin.org/get' = 'HTTP://' + ParseResult(scheme='http', netloc='httpbin.org', path='/get', params='', query='', fragment='').netloc + ParseResult(scheme='http', netloc='httpbin.org', path='/get', params='', query='', fragment='').path
    <Response [404]> = <module 'requests' from 'requests/requests/__init__.pyc'>.Request('GET', 'HTTP://httpbin.org/get')
    <Response [404]> = <requests.sessions.Session object at 0x110931e10>.send(<Response [404]>.prepare())
>>  assert <Response [404]>.status_code == 200, 'failed for scheme {0}'.format('HTTP://')

-------------------- >> begin captured logging << --------------------
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1
requests.packages.urllib3.connectionpool: DEBUG: "GET http://httpbin.org/get HTTP/1.1" 200 212
requests.packages.urllib3.connectionpool: DEBUG: "GET HTTP://httpbin.org/get HTTP/1.1" 404 2963
--------------------- >> end captured logging << ---------------------

----------------------------------------------------------------------
Ran 1 test in 0.504s

FAILED (failures=1)
```


I can't reproduce this on my Mac (10.9.2, Python 2.7.6 (homebrew), Requests 2.2.1) and our continuous integration didn't fail either. Does this reproducibly fail for you?


yes, it is reproducible, however, only if Glimmerblocker (1.5.3) is activated.
All other programm (e.g. curl) can download from HTTP://httpbin.org/get

It seems the problem is that requests does not convert the scheme to lowercase.


I think this is Glimmerblocker's fault, actually. RFC 2616 states (emphasis mine):

> When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
> 
> A port that is empty or not given is equivalent to the default port for that URI-reference;
> Comparisons of host names MUST be case-insensitive;
> **Comparisons of scheme names MUST be case-insensitive**;
> An empty abs_path is equivalent to an abs_path of "/".

We've had trouble here in the past with scheme sensitivity, and concluded that we should allow schemes set weirdly as much as possible. Glimmerblocker is in violation of RFC 2616, we are not. =)

_With that said_, I wonder if we should be lowercasing schemes when we build URLs for proxies.


I agree it must be Glimmerblocker's fault.
But given most other programm lowercase the scheme (and I've seen other code checking only for 'http') it would be a useful workaround for broken proxies to lowercase it as well.


I don't understand how Glimmerblocker is causing our tests to fail.


We call [this method](http://docs.python.org/2/library/urllib.html#urllib.getproxies) that gets the proxies defined in the system so that we can route to them. I'd wager that Glimmerblocker appears in that list. When it does, we change the request URI from just the path to the full URI, causing Glimmerblocker to see the upper-cased scheme whereupon it chokes because it was badly written. =D


This bug has been fixed as a side-effect of https://github.com/t-8ch/requests/commit/54bf4dcaaa37a5a5efb77669d6e5ab68680de737