One other thing I have forgotten to mention. The error log has this in it when those buckets don't come out correctly:
[info] (70014)End of file found: core_output_filter: writing data to the network If flush buckets are inserted, as I said before, the message goes away. This is line 4206 of server/core.c. Sidenote: On my system, emulate_sendfile seems to be used (RHL 9) in this whole process. I'm pretty sure this version of Linux has sendfile support, not sure why it is not used. Probably some other test in core_output_filter is making sure of that. Also worth noting is another interesting effect. First, I open up the file I want to send out with apr_file_open. If I then obtain the file descriptor of it (thanks Cliff!) with apr_os_file_get, dup it with dup(fd) and then fdopen(fd,"r") it (huh!), I have another FILE pointer I can use for some other stuff (i.e. scanning the file with Flex). However, this other use actually brings the file position pointer to EOF. Given the dup() call, the postion of the original file is also at EOF. If I don't have this: rewind(fp); just before this: ap_pass_brigade(r->output_filters,bb); in my code, I get nothing at all out (i.e. 0 bytes apart from headers) and the above mentioned [info] in the error log (even with flush buckets). So, somehow, somewhere core_output_filter code is getting upset by the fact that EOF was reached, although that shouldn't make any difference given that the code for sending file buckets out should position itself where needed in order to fetch the appropriate data. Or at least that's what I think :-) Hope this helps in debugging... Quoting Cliff Woolley <[EMAIL PROTECTED]>: > On Sun, 10 Aug 2003, Bojan Smojver wrote: > > > Just wanted to ask if you guys need me to open up a bug in Bugzilla for > > this? > > No need... I'll be looking at it tomorrow. If it were going to be > longer-term, I'd ask you to. Thanks for the additional details and test > module! > > --Cliff > > -- Bojan
