Testsuite failure #1946

ttanner opened this Issue Mar 10, 2014 · 7 comments


None yet
3 participants

ttanner commented Mar 10, 2014

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):
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)

Lukasa commented Mar 10, 2014

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?

ttanner commented Mar 11, 2014

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.


Lukasa commented Mar 11, 2014

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.

ttanner commented Mar 11, 2014

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.


sigmavirus24 commented Mar 11, 2014

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


Lukasa commented Mar 11, 2014

We call this method 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

ttanner commented Nov 13, 2014

This bug has been fixed as a side-effect of t-8ch/requests@54bf4dc

@ttanner ttanner closed this Nov 13, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment