GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
PyOpenSSL would make it possible use SNI on versions of python:
The connection made by PyOpenSSL does not implement the makefile()-Method.
This is used by httplib. Stacktrace:
Traceback (most recent call last):
File "/home/t-8ch/Projekte/urllib3/test/with_dummyserver/test_https.py", line 24, in test_simple
File "/home/t-8ch/Projekte/urllib3/urllib3/request.py", line 67, in request
File "/home/t-8ch/Projekte/urllib3/urllib3/request.py", line 80, in request_encode_url
return self.urlopen(method, url, **urlopen_kw)
File "/home/t-8ch/Projekte/urllib3/urllib3/connectionpool.py", line 417, in urlopen
File "/home/t-8ch/Projekte/urllib3/urllib3/connectionpool.py", line 279, in _make_request
httplib_response = conn.getresponse()
File "/usr/lib/python3.2/http/client.py", line 1047, in getresponse
response = self.response_class(self.sock, method=self._method)
File "/usr/lib/python3.2/http/client.py", line 281, in __init__
self.fp = sock.makefile("rb")
NotImplementedError: Cannot make file object of SSL.Connection
Ideas to cope with this:
I am in favour of the last point.
One more idea:
Upside of this option is that it's a reasonable small step towards #58 and it doesn't require vendoring in additional external code.
Also a question: What are our primary reasons for using PyOpenSSL? I understand it brings SNI to Python 2.x, but is there anything else we really need?
My reasoning went quite close along the line "There a are people stuck on python2, and we just introduced a second SSL-backend so why not stuff one more in."
pyOpenSSL has support for some generic crypto and random stuff and interface closer to the C-API of openssl. As python3.2 introduced an API, which is modelled after the one of openssl itself this doesn't matter really much.
Replacing the response class sounds interesting.
Fair enough. I guess this issue is relatively low priority for now. You or anyone else is welcome to take a crack at it if you're feeling inspired. :)
For the record: Do you want to keep the API of the original HTTPResponse?
https://github.com/benoitc/http-parser seems to be halfway there
Do you mean the original urllib3 HTTPResponse or httplib HTTPResponse?
It's obviously preferable to keep whatever compatibility we already have, but I'm very open to solid API improvements at the cost of breaking backwards compatibility. Ideally there would be a transition period before complete deprecation.
I've looked at http-parser and I definitely like it. The downside is that we'll be introducing an install-time dependency, but there are big upsides in performance and dropping the dependency on httplib. Though I don't feel it'd be worth introducing the dependency unless we drop the httplib dependency (ie. #58).
Can we please move this to high priority.
There aren't so much priorities in this project as much as how soon things are likely to get done, which depends on whether the people who need this feature are willing to implement it. :)
It might be possible to use a little subclass of http://docs.python.org/library/io.html#io.IOBase to implement an object that could sensibly returned by makefile().
I have tried something like this.
(Following code is python3)
httplib always calls makefile() like this: sock.makefile("rb")
I then took the makefile() implementation from socket.py and ripped out all
The whole function would then be condensed down to:
return io.BufferedReader(SocketIO(socket, "r"), io.DEFAULT_BUFFER_SIZE)
But of course this wouldn't work.
Should be done with #156?!
Well, it's optional in a contrib module. Up to you guys how you interpret that. :P
I think the contrib module fits perfectly. Closing.