Summary of the main supported types as I see them, whether documented, undocumented, or only working by accident:

* None
* Bytes-like sequences, e.g. bytes(), bytearray. I believe Content-Length is actually automatically set for all these types.
* Arbitrary bytes-like objects, including array.array("I") and ctypes structures, if custom Content-Length provided (HTTP over TCP only)
* str() objects, to be automatically encoded with Latin-1
* File reader objects not supporting stat(), e.g. BytesIO
* File with valid stat().st_size, i.e. not named pipes
* Binary file reader
* Text file reader with mode attribute without a "b", automatically encoded with Latin-1
* Any iterable of bytes-like sequences
* Any iterable of arbitrary bytes-like objects (HTTP over TCP only)

Arbitrary bytes-like objects are not properly supported by SSLSocket.sendall(). After all, the non-SSL socket.sendall() documentation does not explicitly mention supporting arbitrary bytes-like objects either, though it does seem to support them in practice.

Suggested documentation fixes and additions:
* Clarify Content-Length is added for all sequence objects, not just “string or bytes objects”
* Warn that a custom Content-Length should be provided with non-bytes sequences, and with special files like named pipes, since the len() or stat() call will give the wrong value
* end_headers() should mention byte string rather than just “string”, since it does not (yet) accept Latin-1 text strings
* end_headers() should not mention sending in the same packet either, since separate sendall() calls are made for all cases; see Issue 23302
* send() should clarify what it accepts
* Either omit mentioning arbitrary bytes-like objects, or add support to SSLSocket.sendall() and document support by non-SSL socket.sendall()

I would support encoding iterables of str() objects for consistency. The patch for Issue 23350 already does this, although I am starting to question the wisdom of special-casing lists and tuples in that patch.