Re: CGI ponderings
Mark Anderson (mda@pure.com)
Mon, 19 Jun 1995 09:16:00 -0700
>That applies to the read() system call not perl's read() which actually
>calls stdio fread(). I believe that fread() _should_ deal with partial reads.
>
>The comments in CGI::Base say:
>
> # Perl read() relies on C stdio fread() to deal with incomplete
> # network reads. read() will block if trying to read too much.
Not a quote from a man page or kernel source :).
I'm pretty sure fread does nothing special in the kernel as compared to read.
It is just there for completeness for people using FILE*, which does user
process-side buffering, nothing to do with how the stream head in the kernel
is handled.
Think about how hard it would be for the kernel to do this. It has no
notion of the length of your message -- that is an application level notion,
which is why it has to be encoded in the message itself. The sender may
do multiple write()'s to send a single message. The message may be
fragmented into ip packets and reassembled, if sent across a network.
And so on. A select will succeed when there are *any* bytes available;
there is no guarantee that what you think of as the whole message is there
yet.
>At one point read_entity_body did something like this but after testing
>with some big POST bodies I removed it and this is the first complaint.
I'd suggest putting it back. You can probably reproduce the problem
by going across a network, doing multiple writes between sleeps, etc.
>p.s. If I do put in the looping code it will use read() not sysread()
>since mixing sysread() with $line=<$fh> style input used elsewhere
>will not work reliably.
I was only aware of this issue in output, but that does seem safest given the
large number unix's this may be running on.
-mda