
Ich habe die folgende Anweisung in meinem Apache httpd.conf
:
<LimitExcept OPTIONS PROPFIND REPORT>
deny from all
</LimitExcept>
OPTIONS
und PROPFIND
funktioniert wie erwartet, gibt aber REPORT
zurück 400: Bad Request
. Entfernen Sie LimitExcept
alles zusammen und alles funktioniert wie erwartet.
Irgendwelche Ideen, warum das so sein könnte?
(Siehemeine Frage hierum zu sehen, was ich versuche zu tun).
Das Zugriffsprotokoll zeigt:
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
Das Fehlerprotokoll zeigt:
[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
Aktualisieren
<LimitExcept>
Ok, eine schnelle Überprüfung zeigt, dass die URL mit oder ohne REPORT
gleich bleibt. So sieht das Protokoll ohne aus <LimitExcept>
(alles andere in der Konfiguration bleibt gleich):
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
(Beachten Sie, dass diese URL eine vom Befehl generierte Subversion-URL ist svn log
– ich bin nicht derjenige, der !svn
sie hinzufügt)
Der komplette VirtualHost /logs/
sieht folgendermaßen aus:
<Location /logs/>
DAV svn
SVNParentPath C:\SVN
<LimitExcept OPTIONS PROPFIND REPORT>
deny from all
</LimitExcept>
</Location>
Antwort1
So sieht das neueste mod_dav.c in 2.2.15 aus (der Kürze halber bearbeitet):
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;
}
Mein Bauchgefühl sagt mir also, dass ap_xml_parse_input(r, &doc)) doc=NULL belässt, da auf den fragwürdigen Dokumentnamen nicht zugegriffen werden kann (er enthält ein !??) und es eine 400-Fehlermeldung zurückgibt:
"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
...es scheint, als liege das Problem darin, wie virtuelle /logs/ aus dem access_log diesem Verzeichnis im error_log zugeordnet werden und ob es geeignete Zugriffskontrollen gibt, die das Lesen der Ressourcen vom Speicherort ermöglichen. Als Nächstes müssen wir uns alle diese Konfigurationsinformationen ansehen.