| Reply | « Previous Thread | Next Thread » |
|
Hi all,
I've been unable to get https connections working. Here's what i've tried (from bt_console): >>> import urllib >>> urllib.urlretrieve("https://host/path","C:\\filename") and the interpreter on the phone exits >>> import httplib >>> conn = httplib.HTTPSConnection("host") >>> conn.request("GET","/path") >>> resp = conn.getresponse() and the interpreter on the phone hangs Non-https equivalents of the above do work. Has anyone gotten https to work? How? Thanks. |
|
I tried with socket too:
>>> import socket >>> s = socket.socket(socket.AF_INET,socket.SOCK_STREAM) >>> s.connect(("host",443)) >>> ssls = socket.ssl(s) >>> ssls.write("GET / HTTP/1.0\r\n\r\n") 18 >>> data = ssls.read(1024) and the interpreter on the phone exits |
|
Which model phone are you trying this on? I'm pretty sure the SSL stuff only works on SDK 2.x and newer devices (ie., when the OS started shipping with SSL libraries.)
|
| eriksmartt |
| View Public Profile |
| Find all posts by eriksmartt |
|
It's 6630. Software version 2.39.129.
Https conncetions do work with the phones browser. |
|
I also see it on a 6630 (HK firmware, from expansys - is there an easy way to ask it for the version? it wasn't in settings-about...) urllib can open and .read random http pages, but https://www.amazon.com (for example) causes the interpreter app to exit.
Note that I'm trying this over the bt_console connection - I haven't tried it locally, but I hope that doesn't make a difference, since I expect to be doing *all* of my development that way (at least until I find a bt keyboard driver :-) Is there any app failure logging on the phone? |
|
Looks like it happens at the lowest layer, if that wasn't already obvious:
Code:
>>> from e32socket import *
>>> es = socket(AF_INET, SOCK_STREAM)
>>> es.connect(("147.243.138.170", 443))
>>> ses = ssl(es)
*crash*
|
|
I think some of the problems stem from SSL Objects read() behaviour. On 6630 read(n) blocks if n bytes are not available from the connection. read() (without n parameter supplied) crashes the interpreter. So, if you're careful not to try to read more than is available from the connection, you can read from ssl connection.
But for example httplib.SSLFile.read() and readline() assume non-blocking behaviour from SSL object. Does this have something to do with no support for non-blocking sockets? |
|
Seems like there is a genuine bug in our SSL support.
Sorry on behalf of the whole team for ignoring this for this long -- almost six months without a proper response to a reported interpreter crash is simply not acceptable. We'll see what we can do to fix both this bug and our internal process for responding to bug reports so that this kind of oversight will not happen again. |
|
Just for reference: the tracking number for this bug is #207.
|
| Reply | « Previous Thread | Next Thread » |
| Thread Tools | Search this Thread |
|---|---|
| Rate This Thread | |