On Wed, Jun 01, 2005 at 04:15:02PM +0200, [EMAIL PROTECTED] wrote: > ------- Additional Comments From [EMAIL PROTECTED] 2005-06-01 16:15 ------- > I don't have any patches and/or tested code. I was hoping you'd chime in ;) > > I concur on checking for rv != APR_EOF. > > For core_output_filter, looks like there are two paths, based on what we > originally found out for the file length (before truncation): > > a) big enough for sendfile > > not improved by file-bucket-read fix; I suspect sendfile caller will loop > since > we won't make any progress when calling sendfile (0 bytes written) > incidentally, I've seen a few loopers with sendfile enabled on HP-UX; > supposedly > that is NOT due to truncated file but instead something happening in network > layer; catching this no-progress-made scenario would exit the loop on the > HP-UX > scenario as well
Ah, interesting. The logic is there to return APR_EOF to the caller for the "made no progress" case for some of the implementations. Looks like the HP-UX, Solaris and possibly AIX implementations are missing it though. > b) not big enough for sendfile > > With the file-bucket-read fix we won't be misled by e->length since we do the > bucket read in the path you mentioned to find the length. rv will be APR_EOF > (not abnormal when reading a file) and length will be 0 (not abnormal when > reading a file). How do we know that something has gone wrong? Compare the > declared length of the file (e->length) with the length returned by > file-bucket-read? Hum, good questions. But: it *is* always an error for a FILE bucket to read() EOF from the file. That should never happen, because it must never attempt to read past the fixed segment of the file it represents. So maybe it's also correct for file_bucket_read to return APR_EOF if that's what it read. I'll have a play around with that. joe
