During my work just now on the method number changes, I found that the Allow: header was not being returned by the OPTIONS request. Tracing the code showed that it *was* inserting the proper header into r->headers_out. However, it was doing that for a redirect, and the headers never made it out the pipe.
[ I updated back to an hour before my commit and tried that: still no Allow: header, so it wasn't my changes... ] This is happening for the Allow: header in an OPTIONS request, but I believe it will also happen for any response that doesn't have a body. I think this is what is happening: * I did an OPTIONS for "/" * mod_negotiation did an internal redirect to /index.html.en * the Allow: header was added to r->headers_out * the request was finalized by ap_internal_redirect() * the normal operation of ap_finalize_request_protocol() is to send an EOS bucket. this prods HEADER_OUT to send the headers. * however, since the internal redirect is a subrequest, it gets an "EOS chomper" filter on it. the EOS is never delivered, and the headers are never sent. * somewhere in the unwinding process, the main request is finalized, and it gets an EOS which flushes the *main* request headers. which are, of course, quite wrong. Hmm. I just tried to do some testing with an "index.cgi" file. I added index.cgi to the DirectoryIndex directive, and then did the AddHandler for .cgi -> cgi-script. It would not run the index.cgi script(!). Maybe I misconfigured, but that is definitely a big-time regression in functionality. Not sure where *that* one fails. I know that index.cgi type stuff also requires an internal redirect, but I'm out of time to dig into that one, too. Cheers, -g -- Greg Stein, http://www.lyra.org/
