SSLObject breaks read semantics

[ellisj]

BPO	1291446

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-09-04.01:33:47.470>
created_at = <Date 2005-09-14.22:28:27.000>
labels = ['library']
title = 'SSLObject breaks read semantics'
updated_at = <Date 2008-09-05.17:43:05.679>
user = 'https://bugs.python.org/ellisj'

bugs.python.org fields:

activity = <Date 2008-09-05.17:43:05.679>
actor = 'ellisj'
assignee = 'janssen'
closed = True
closed_date = <Date 2008-09-04.01:33:47.470>
closer = 'janssen'
components = ['Library (Lib)']
creation = <Date 2005-09-14.22:28:27.000>
creator = 'ellisj'
dependencies = []
files = []
hgrepos = []
issue_num = 1291446
keywords = []
message_count = 8.0
messages = ['60815', '72451', '72481', '72482', '72516', '72518', '72610', '72613']
nosy_count = 2.0
nosy_names = ['janssen', 'ellisj']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1291446'
versions = ['Python 2.4']

[ellisj]

f = socket.ssl(sock)
f.read(n)

doesn't always return n bytes, even if the connection
remains open! in particular, it seems to reproducibly
return less than n bytes if the read would span the
boundary between units of 16KB of data.

We've had to work around this with code like the following:

        pieces = []
        while n > 0:
            got = self.realfile.read(n)
            if not got:
                break
            pieces.append(got)
            n -= len(got)
        return ''.join(pieces)

[janssen]

I think I'm going to close this. file.read(N) is not guaranteed to
return N bytes, it's guaranteed to return at most N bytes.

[ellisj]

This is incorrect. Perhaps you are thinking of a raw socket read; a
_file-like-object_ read is supposed to return the amount of data
requested, unless (a) the socket is in non-blocking mode, or (b) if EOF
is reached first. Normal socket.makefile observes this, but SSLObject
does not.

[ellisj]

s/raw socket read/raw socket recv/

[janssen]

The way I read the documentation, file.read() (and that's what we're
talking about) is still not guaranteed to read all the bytes of the
file. But, you're right, that is the accepted semantics. So the
documentation should change, too.

However, the "read" method on an SSLSocket, which is not a file()
subclass, is *not* guaranteed to return N bytes, it's guaranteed to
return at most N bytes. Call "makefile" on SSLSocket if you need a
file-like object.

[ellisj]

Here is the exact SSLObject.read documentation from 2.5 (although the
bug was filed against 2.4, and 2.6 will be out soon, the docs are the
same):

-----

read([n])

If n is provided, read n bytes from the SSL connection, otherwise read
until EOF. The return value is a string of the bytes read.

-----

This is not ambiguous. Similarly, help(file.read) is not ambiguous.
(The "at most" part in the first line of file.read is later explained
to apply to non-blocking reads.)

If you want to claim "well, it's not a file-like object" then (a) it
shouldn't have file-like methods (socket-like send and recv are the
obvious choices instead of write and read), (b) you need to fix your
docs. But since god knows how many programs are out there expecting
the semantics explained by the existing docs, I think just fixing the
bug in the code is better than defining away the problem.

(Obviously socket.makefile won't work on an object that doesn't
implement a socket-like interface, so that's a non-option.)

[janssen]

Ah, sorry. I was looking at the 2.6 documentation, not the 2.5
documentation. In 2.6 (which is what the new SSL code is for),
documentation of socket.ssl has been removed entirely, along with the
text that you cite, although the functionality from 2.5 socket.ssl is
still provided for backwards compatibility. In 2.6, the ssl.SSLSocket
type is a subclass of socket.socket, so you call "makefile" on it to get
a file-like object for reading and writing.

If you'd like to submit a patch for 2.5 and 2.6, I think this is
backwards-compatible enough to qualify as a fix, not a feature enhancement.

[ellisj]

Ah, great. I was wondering why you kept talking about SSLSocket
instead of SSLObject. "New API in 2.6" is good enough for me. Thanks!