Asyncio's StreamReaderProtocol[1] often returns True from Protocol.eof_received(). This tells the Transport that "closing the transport is up to the protocol" [2]. However, StreamReaderProtocol does not call Transport.close(). More precisely, StreamReaderProtocol leaves the transport interaction to StreamReader. It calls StreamReader.feed_eof()[3]. But StreamReader does not call self._transport.close(). It only sets a self._eof flag, and awakens any of its functions which were waiting for data. 

The only occurrence of self._transport.close() occurs in StreamWriter[4]. There is none in StreamReader or StreamReaderProtocol.

I believe that the fix should be for StreamReader to call self._transport.close(). However, it may need to avoid this if StreamReaderProtocol._over_ssl is True, and I don't immediately see how it can tell this. Also, it may need to wait for anything waiting for self._waiter to run, before closing the Transport.
Or, maybe StreamReaderProtocol should not return True from Protocol.eof_received().

I discovered this when using a Transport of my own devising, which reads from a file instead of from a socket, with asyncio.streams.  The file did not close in the unit test. My transport duly called Protocol.eof_received(), but received a True in response, so did not close the file.

My workaround will probably be to not believe what Protocol.eof_received() tells me, and to close my transport regardless.

[1] Lib/asyncio.streams.StreamReaderProtocol.eof_received, line 259-266.
[2] 19.5.4.2.3. "Streaming protocols" <https://docs.python.org/3/library/asyncio-protocol.html>
[3] Lib/Lib/asyncio.streams.StreamReader.feed_eof, lines 419-421.
[4] Lib/Lib/asyncio.streams.StreamWriter.close, lines 316-317.

All line numbers are as of tag v3.7.0, commit 1bf9cc509326bc42cd8cb1650eb9bf64550d817e . 

Bug observed in v3.7.0. Not yet investigated in HEAD revision.