Upload of binary files
do-not-spam-ben.hutchings at businesswebsoftware.com
Fri Mar 14 14:18:02 CET 2003
In article <3e7101d7$0$49117$e4fe514c at news.xs4all.nl>, Irmen de Jong wrote:
> Peter Hansen wrote:
>>>This won't do. It is not guaranteed that a single read() returns
>>>all of your data.
>> Since when? I know with sockets you don't get a guarantee that
>> recv() gets all the data, but the docs on read() for a file
>> object say:
>> read ([size])
>> Read at most size bytes from the file (less if the read hits EOF before
>> obtaining size bytes). If the size argument is negative or omitted,
>> read all data until EOF is reached.
> I *may* indeed be wrong here, but consider this:
> I was thinking.. "from your CGI code you're actually reading from
> a socket, that's wrapped in a file-like object".
You are probably reading from a pipe, actually. HTTP/1.1 allows multiple
requests to be sent on the same socket, but a CGI process should only see
one of them. Therefore a web server that supports HTTP/1.1 will probably
send a single request to it down a pipe.
> Sockets behave like I said. So I thought: the read() behaves like this too.
> Even more so because there is no such thing as "EOF" on sockets.
There is on stream sockets. When your peer closes its socket, you see
that as EOF.
> How can the read() know when all data have been read?
> PS a read() on a *true* file would read everything, ofcourse, like
> you pointed out.
A read() on any file-like object should read everything. (Having said
that, EOF on a terminal might not be for real - the reader can ignore
it and the user can keep on typing.)
More information about the Python-list