kwarg error when $http_proxy is set in environ

[aisk]

$ echo $http_proxy
some_proxy.com:1234

and run the requests example, I got this error:

Traceback (most recent call last):
  File "test.py", line 20, in <module>
    resp = requests.get(url)
  File "/usr/local/lib/python2.7/site-packages/requests/api.py", line 60, in get
    return request('get', url, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/api.py", line 49, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 457, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 569, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 362, in send
    timeout=timeout
  File "/usr/local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 511, in urlopen
    conn = self._get_conn(timeout=pool_timeout)
  File "/usr/local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 231, in _get_conn
    return conn or self._new_conn()
  File "/usr/local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 192, in _new_conn
    strict=self.strict, **self.conn_kw)
  File "/usr/local/lib/python2.7/site-packages/wsgi_intercept/requests_intercept.py", line 22, in __init__
    WSGI_HTTPConnection.__init__(self, *args, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'socket_options'

and the kwargs of wsgi_intercept/requests_intercept.py:HTTP_WSGIInterceptor.init is

{'strict': False, 'host': 'some_proxy.com', 'socket_options': [], 'timeout': <object object at 0x1028490e0>, 'port': 1234}

[cdent]

Thanks for the report. This ought to be relatively easy to clear up.

[cdent]

Actually this won't be as straightforward as I initially thought. The problem is that requests+urllib3 have already made the decision, prior to wsgi intercept getting involved, to make the socket call to the proxy host (as shown in your kwarg output above). No intercept has been set for that. So even if the code goes to the trouble of removing the unexpected socket_options keyword, the test code will still not work unless the caller set an intercept for the proxy host too.

I can go ahead and remove the keyword, but it feels like it leaves a bit of a gaping hole that needs to be acknowledged somehow. (the other libraries don't have this problem, more magic from requests...)

[aisk]

Can we add some document to point out that wsgi-intercept don't works with $http_proxy, and check is there http proxy is set when running, then throw a warning exception?

I think most wsgi-intercept use cases don't need proxy, but once it is set, user got a strange exception, and have to dig it into source code to find what happened.

(I have got the same problem one year after this issue was opened, and I've forgot it, then googled the error message and find this issue 😂)

[cdent]

This sounds like a good idea, but let me make sure I understand your suggestion. Your idea is that when running add_wsgi_intercept the code would check to see if http_proxy is set in the os.environ and if so raise either a warning or an exception?

Some questions on that:

• should it be a warning and continue or an exception and exit?
• should it happen on add_wsgi_intercept or when the intercept module is installed?
• if the latter should it always do it, or just with requests?

[aisk]

• I think raise exception and exit is a good choice, because the next code will exit either.
• Sorry I have no idea ....
• Other adapter have no issue with this, I think just with request is better.

[cdent]

@aisk if you could have a look at #35 and see if it will suit your needs, that would be very helpful. Thanks.

[aisk]

:+1: