At 12:54 PM 2/11/2003, you wrote: >William A. Rowe, Jr. wrote: >>I'm very close to an outright veto of such a change, at this time... > >forget it. > >Not only is the binary interface to sendfile broken now, the source interface >is broken too. Since there was no mmn bump, there is no reasonable way a >module which ships independently from the core can write code to enable >sendfile with the new interface and expect the module to compile against >2.0.43 or earlier. > >I like the concept of disabling sendfile at runtime to handle the corner cases >like nfs and broken OSes. No argument there. But the existing code goes >beyond that. As things stand now, non-core module owners are screwed if they >want to use sendfile in the majority of cases where it works fine.
I suggest the following as a friendly compromise to avoid voting... introduce DISABLE, don't drop ENABLE (especially since your patch would *reverse* the meaning of the EnableSendfile directive for httpd 2.0.44 built against a newer apr!!!) Respect both flags unless both are passed to apr_file_open. If neither is specified, let the platform author of the apr_sendfile() code decide how *safe* it is to enable the feature. This could include context (such as the filesystem if they want to query it) or filesize (<2gb) or whatever choices are wise. ENABLE and DISABLE would both be explicit overrides to any sanity tests. Based on current bugzilla reports, httpd EnableSendfile should gain the 'default' state. So we could turn it on or off, or leave it up to APR. Bill
