2

I have the following directive in my Apache httpd.conf:

<LimitExcept OPTIONS PROPFIND REPORT>
   deny from all
</LimitExcept>

OPTIONS and PROPFIND work as expected, but REPORT returns 400: Bad Request. Remove the LimitExcept alltogether and everything works as expected.

Any ideas on why this might be?

(Please see my question here to see what I'm trying to do).

The access log shows:

192.168.161.1 - - [21/Jun/2010:08:42:26 +1000] "REPORT /logs/MV101Apps/!svn/bc/7699/MyApp/MyApps.edp HTTP/1.1" 400 101

The error log shows:

[Mon Jun 21 08:42:26 2010] [error] [client 192.168.161.1] client denied by server configuration: C:/Program Files/CollabNet/Subversion Server/httpd/htdocs/logs

Update

Ok, a quick inspection reveals that either with or without the <LimitExcept> the REPORT URL stays the same. This is what the log looks like without the <LimitExcept> (everything else in the config stayed the same):

192.168.161.1 - - [22/Jun/2010:21:03:42 +1000] "REPORT /logs/MV101Apps/!svn/bc/7821/MyApp/MyApps.edp HTTP/1.1" 200 115

(note that that URL is a Subversion URL as generated by the command svn log - I'm not the one adding the !svn to it)

The complete VirutalHost for /logs/ looks like this:

<Location /logs/>
   DAV svn
   SVNParentPath C:\SVN
   <LimitExcept OPTIONS PROPFIND REPORT>
       deny from all
   </LimitExcept>
</Location>
Community
  • 1
Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
  • Got any output in your apache error log? Oh, and adding 'apache' without the '2' might help to get others to see this question. – Wrikken Jun 18 '10 at 13:49
  • @Wrikken - good thinking, don't know why I didn't already do that. I'll attach it to the question on Monday. – Mark Henderson Jun 18 '10 at 22:59

1 Answers1

3

This is what the latest mod_dav.c looks like in 2.2.15 (edited for brevity):

static int dav_method_report(request_rec *r)
{
  int result;
  apr_xml_doc *doc;

  if ((result = ap_xml_parse_input(r, &doc)) != OK)
    return result;
  if (doc == NULL) {
    return HTTP_BAD_REQUEST;
  }

So, my gut instinct is that ap_xml_parse_input(r, &doc)) is leaving doc=NULL; based on not being able to access that questionable doc name (it has a ! in it??) and spitting back a 400:

"REPORT /logs/MV101Apps/!svn/bc/7699/MyApp/MyApps.edp HTTP/1.1"

...

client denied by server configuration: C:/Program Files/CollabNet/Subversion Server/httpd/htdocs/logs

...it smells like the problem lies in how virtual /logs/ from the access_log is mapped to this directory in error_log, and if there are proper access controls to allow the resources to be read from the location. We need to see all that config info next.

  • Impressive research there, +1 – pauska Jun 22 '10 at 10:27
  • thinking further, the default value of result in the function ap_xml_parse_input (server/util_xml.c) is HTTP_BAD_REQUEST as well, so it could actually be failing at the initial parsing step. Looking at the function this can be from several different types of read errors as well as parsing... –  Jun 22 '10 at 10:49
  • Wow, impressive, thanks. Thing is if I remove the `` everything works perfectly, even though no other methods are used besides the three listed. I don't know if the SVN URL stays the same though, I'll need to inspect the logs to find out... – Mark Henderson Jun 22 '10 at 10:56
  • Just so I can be sure to post the right info (Apache isn't my forte), "We need to see that config info" - which part of the config would you like to see? the `/logs/` VirtualHost? – Mark Henderson Jun 22 '10 at 10:58
  • Could `ap_xml_parse_input` be re-interrogating Apache and trying to invoke a method that's not included in the ``? – Mark Henderson Jun 22 '10 at 11:11
  • Looking through `util_xml.c`'s `ap_xml_parse_input` there's a few return paths that could return a `HTTP_BAD_REQUEST` (as that's its initial value). Apart from that I don't know enough about the function to draw any logical conclusions except that I'm not seeing any XML Parser errors being logged on the system (but maybe the logging level isn't detailed enough... hmm) – Mark Henderson Jun 22 '10 at 11:21
  • Have you tried adding GET to the LimitExcept clause to see if that works to debug? I'm just wondering if some internal operation of the REPORT command (internal subrequest) uses a GET and because of your setup you are denying GET, leading to the error (which is more like a 403 forbidden but is being represented to us as a 400 because of the way they coded the module) - try it once and just see if it works. –  Jun 28 '10 at 05:07