This is a re-submission of old bug (mod_cgi/PR#4490, 1999) that was once confirmed but was lost for some unknown reason (probably during transition to new bug database?). The problem resides in following code in mod_cgi.c: if (r->method_number == M_OPTIONS) { /* 99 out of 100 CGI scripts, this is all they support */ r->allowed |= (1 << M_GET); r->allowed |= (1 << M_POST); return DECLINED; } This code obviously prevents userland CGI to handle OPTIONS request. Because of this code, I've been unable to release/distribute CGI-based WebDAV provider script as WebDAV protocol requires service endpoint to handle OPTIONS request properly. This same report was once submitted to apache-bugdb list in 1999 and seems to have been confirmed and almost got accepted. You can read how last conversation went in the following URL: http://www.geocrawler.com/mail/thread.php3?subject=mod_cgi%2F4490% 3A+mod_cgi+prevents+handling+of+OPTIONS+requests&list=192 It seems the last piece needed to get the fix done is a submission of a patch, and here I'm submitting it. You can download the patch from http://www.imasy.or.jp/~tai/temp/mod_cgi.c.patch This patch will add "ScriptTrapOptions (on|off)" directive, which allows user to control whether CGI script will handle OPTIONS request or not. Just FYI, during googling, I also found Zope people is also hit by this bug. In fact, author of the patch below is the one who have submitted last bug report on this issue. http://www.zope.org/Members/Brian/Misc/mod_cgi_webdav_patch.html His patch simply removes above code block, whereas mine adds new diretive to control the behavior. If this patch gets accepted, I will also submit a report for apache-2.0, as mod_cgi.c in 2.0 also has this code.
Created attachment 4116 [details] Patch to configure whether userland CGI could handle OPTIONS request.
Created attachment 4117 [details] Patch to configure whether userland CGI could handle OPTIONS request.
I'm going through the bug db to make sure patches are findable. Please see http://httpd.apache.org/dev/patches.html
Created attachment 11102 [details] Fixed for the Windows Update problem
Just a thought -- requiring extra configuration will be onerous for some users (e.g., those at certain hosting providers). Rather than adding a configuration directive, why not require the script that wants to handle OPTIONS to just emit an Apache-Specified HTTP header that gets consumed? E.g., print "Status: 200 OK" print "Handling-OPTIONS: 1" print "Allow: GET, POST" ...
Did you ever submit a report for 2.0? Can't seem to find anything, and 2.0.53 seems to have the same problem.
Hmm, never mind the previous suggestion; if the script had side effects, they'd still take place, which won't be good.
Wow, it's been long time since I submitted this one... No, I haven't submitted patch for 2.0. At that time, 2.0 was not really for production, so I simply waited for 1.3 patch to get in. It 2005 now, so maybe I should push this patch for 2.0 - I guess developers are more active on 2.0 than on 1.3.
I'd just like to add that it's been awhile and it would be nice if the patch was accepted.
Also known as http://archive.apache.org/gnats/4490 This misfeature was supposed to be deleted almost immediately following its addition to the server, as described in <http://mail-archives.apache.org/mod_mbox/httpd-dev/199608.mbox/%3c9608132318.aa12603@paris.ics.uci.edu%3e> Yep, that's Aug 1996. In fact, I thought that I had deleted it, and if this issue had been under "core" I would have noticed it a long long time ago. Oh well... The block has now been deleted from all active branches of httpd (1.3.35, 2.0.56, 2.1+). Thanks for sending in the more complicated patches, but I feel that CGI scripts should be able to handle all methods by now (or be fixed to do so properly). ....Roy