> I've got this other thing I'm hung up on. A response > to an OPTIONS method should not return a content type. > Apache by default does not return one for this > method. I can't seem to find a way to disable sending > a content-type header line. I was hoping calling > rflush would work, but no. > > I looked at the mod_dav.c code and they noted the same > problem in their comments. Apparently, > ap_send_http_header() just sends the content-type > anyway. Is this just a feature of the Apache libraries?
there's a separate ap_send_http_options method for handling the OPTIONS method (as well as ap_send_http_trace for handling TRACE). what ap_send_http_options does is create an Allow header and return OK. one of the few examples of this is mod_proxy, which simply calls this method followed by ap_finalize_request_protocol. this sends an EOS bucket, which (I think) prevents additional headers from being added to the stream. at least that's what the note in send_http_options says :) unfortunately, neither one of these methods is available to mod_perl at the moment. however, you might be able to fake it a bit by inserting the logic from those calls manually in your content handler. start with constructing the Allow header yourself and adding it to $r->headers_out. then, create an eos bucket and insert it into the filter stream. something like this (untested) my $bb = APR::Brigade->new($r->pool, $r->connection->bucket_alloc); $bb->insert_tail(APR::Bucket::eos_create($r->connection->bucket_alloc)); $r->output_filters->pass_brigade($bb); give it a whirl and report back if it works :) HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
