Upload of binary files

[Ben Hutchings]

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?
> 
> Irmen
> 
> 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.)