[Web-SIG] Prototype of wsgi.input.readline().

Graham Dumpleton graham.dumpleton at gmail.com
Wed Jan 30 11:08:21 CET 2008


As I think we all know, no one implements readline() for wsgi.input as
defined in the WSGI specification. The reason for this is that stuff
like cgi.FieldStorage would refuse to work and would just generate an
exception. This is because cgi.FieldStorage expects to pass an
argument to readline().

So, although this is linked in the issues list for possible amendments
to WSGI specification, there hasn't that I recall been a discussion on
how readline() would be defined in any amendment or future version.

In particular, would the specification be changed to either:

1. readline(size) where size argument is mandatory, or:

2. readline(size=-1) where size argument is optional.

If the size argument is made mandatory, then it would parallel how
read() function is defined, but this in itself would mean
cgi.FieldStorage would break.

This is because cgi.FieldStorage actually calls readline() with no
argument as well as an argument in different places in the code.

If we allow the argument to be optional however, we run into the same
portability problems that would exist with some WSGI adapters which do
not simulate EOF on input when all request content is read.

Specifically, if user code calls readline() with no argument but the
last line of the file wasn't terminated with a EOL, then it would
hang.

As it is, cgi.FieldStorage only works on systems which do not simulate
EOF because the content format it is decoding has its own concept of
end of stream marker and cgi.FieldStorage implementation specifically
looks for that. The cgi.FieldStorage implementation certainly doesn't
track how much input it has read in and progressively change the size
argument to readline() on that basis.

Any other code which uses readline() with no argument would similarly
have to depend on some concept of an end of stream marker in the
content, because one can't rely on getting an empty string when input
is exhausted,

In some respects this highlights the inconsistency of the read()
argument not being optional. This is because one of the reasons for
not allowing read() argument to be optional is that it would be
problematical for implementations that do not simulate EOF, yet the
same issue exists with readline() and an optional argument has to be
allowed for that because of how cgi.FieldStorage is implemented.

Graham


More information about the Web-SIG mailing list