[Patches] [ python-Patches-945642 ] nonblocking i/o with ssl socket
not working at all
SourceForge.net
noreply at sourceforge.net
Sat Jul 10 21:12:15 CEST 2004
Patches item #945642, was opened at 2004-04-30 18:14
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470
Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Tino Lange (tinolange)
Assigned to: Nobody/Anonymous (nobody)
Summary: nonblocking i/o with ssl socket not working at all
Initial Comment:
Hi!
Unfortunately the applied patches #675750 and #676472
(End of January by G. Talvola / B. Laurie / G. v.
Rossum) for timeout-sockets in version 1.09 and 1.10 to
Modules/_ssl.c broke the nonblocking SSL I/O.
In fact sslobj.read() became *always* blocking -
whether the underlying socket is blocking or
nonblocking doesn't matter at all.
In Python < 2.3 this has worked correctly, starting
with 2.3, 2.3.x up to the current CVS it doesn't work
anymore.
Attached is a sample:
0) [ Preparation ]
Please run stunnel on your machine to have a SSL service:
/usr/sbin/stunnel -p /path/to/some/cert -f -d 4711 -r 4712
1) [ Server ]
Please run the easy server.py
2) [Client showing the bug]
Please run the client - and see how it hangs when you
use Python2.3.
Also attached is a diff against the current _ssl.c
which shows how to correct that behaviour while also
having the possibilities from the above timeout patches.
I carefully tested it, please review and test yourself
and finally check-in.
If you have questions, please don't hesitate to ask me.
I really would like to see that not only in 2.4, but
also (if possible together with patch #909007 from S.
Nicolary) in a 2.3.4 release. Otherwise 2.3.x wasn't at
all able to handle nonblocking SSL connections properly.
Thanks and cheers,
Tino
----------------------------------------------------------------------
>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 15:12
Message:
Logged In: YES
user_id=11375
The test programs don't work for me, either with or without the patch.
They both crash with 'error:140770FC:SSL routines:
SSL23_GET_SERVER_HELLO:unknown protocol'. What should I be seeing?
----------------------------------------------------------------------
Comment By: Tino Lange (tinolange)
Date: 2004-05-11 18:20
Message:
Logged In: YES
user_id=212920
OK. Fine :-)
Please find below in file
"patch_honoring_the_style_guide.diff" an slightly changed
version of my original patch that follows the PEP7 better
(for the single else statements containg only one commad
without parantheses) - but still honors the rest of the file
also.
Only the formatting has changed a little bit, no content.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-05-11 13:17
Message:
Logged In: YES
user_id=357491
The way you showed it, Tino, is correct. And I didn't realize the file was
not following the spec.
At this point, though, since we are trying to get someone to check this in
before 2.3.4 goes out the door I wouldn't worry about it too much. Going
in and fixing the syntax afterwards is not a huge deal.
So if you have the time, great. Otherwise, because we have this
possible time constraint and whom ever wrote the file in the first place
didn't follow it, I wouldn't not worry about it too much.
----------------------------------------------------------------------
Comment By: Tino Lange (tinolange)
Date: 2004-05-11 03:53
Message:
Logged In: YES
user_id=212920
Thanks for the hint.
I guess --in the context of _ssl.c -- you only complain
about the lines:
} else sockstate = SOCKET_OPERATION_OK;
or? Is that right?
I think all the other else's are consistent - at least with
the rest of the file - and some others I looked into (for
example _bsddb.c).
Or do you think that I shall reformat all the other else's
in the file? Also those that are not from me?
Really following the PEP it should look like:
if (foo) {
...
}
else if (otherfoo) {
...
}
else {
...
}
instead of
if (foo) {
...
} else if (otherfoo) {
...
} else {
...
}
everywhere, or?
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-05-10 21:10
Message:
Logged In: YES
user_id=357491
A style nit: put 'else' statements on their own line. See PEP 7 (http://
www.python.org/peps/pep-0007.html) on C code guidelines.
But I am no network programmer so I have no clue if the solution is
good.
----------------------------------------------------------------------
Comment By: Jesper ´JJ´ Jurcenoks (jesperjurcenoks)
Date: 2004-05-03 14:14
Message:
Logged In: YES
user_id=1033524
Hi Tino.
I'll take your word for it. I though your ssl was based on the
included SocketServer.py
Cheers JJ
----------------------------------------------------------------------
Comment By: Tino Lange (tinolange)
Date: 2004-05-02 04:40
Message:
Logged In: YES
user_id=212920
Hi JJ,
I just scanned your SocketServer.py - and I really don't see
how this class might help? You don't offer a better
sslob.read() there, don't you?
So how could it help (besides maybe making my example
"server.py nicer).
If I put a sslobj on top of a socket object it is blocking
in 2.3, 2.3.x and higher. As proven in my example: Making
the underlying socket nonblocking has no effect - because
SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE from the
SSL_xxx() functions in the C-Library do not break out of the
while loop that was introduced in the above mentioned patches.
Cheers,
Tino
----------------------------------------------------------------------
Comment By: Jesper ´JJ´ Jurcenoks (jesperjurcenoks)
Date: 2004-05-01 22:46
Message:
Logged In: YES
user_id=1033524
Hi Tino.
I just submitted a nonblocking SocketServer.py, it might just
solve your problem.
JJ
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470
More information about the Patches
mailing list