One of the direct consequences for instance is that the first WSGI request object that starts consuming for data is the one that ends up being the only one that can have it.
Protocols like HTTP that lack length-prefixing of messages have some unfortunate implications for streams of messages.
1. The reader of the first message must buffer. Since it doesn't know how much it should read, it may buffer too much, and consume some of the second message from the stream.
2. The reader of the second message needs access to the stream, plus that extra data.
3. If your stream is a non-seekable file descriptor like a socket, there's no way to rewind, or somehow put that extra data back onto the original stream. This forces you to either (a) convey the stream + extra data, which is less natural or (b) create a new stream for the second message reader, copy the extra data to it, and then copy (in userspace!) data from the original stream into the new stream.
Take a look at any cgi or fastcgi implementation and you'll see something like 3b.
It sucks, and I think makes a good argument for using length-prefixed messages in your internal protocols (or whatever ones you can control).
Protocols like HTTP that lack length-prefixing of messages have some unfortunate implications for streams of messages.
1. The reader of the first message must buffer. Since it doesn't know how much it should read, it may buffer too much, and consume some of the second message from the stream.
2. The reader of the second message needs access to the stream, plus that extra data.
3. If your stream is a non-seekable file descriptor like a socket, there's no way to rewind, or somehow put that extra data back onto the original stream. This forces you to either (a) convey the stream + extra data, which is less natural or (b) create a new stream for the second message reader, copy the extra data to it, and then copy (in userspace!) data from the original stream into the new stream.
Take a look at any cgi or fastcgi implementation and you'll see something like 3b.
It sucks, and I think makes a good argument for using length-prefixed messages in your internal protocols (or whatever ones you can control).