mod_dav und 404-Problem mit Clients (Goliath, darin davfs)

Rektal

Here to stay

Registered: Dec 2002
Location: Inside
Posts: 4452

17.03.2004 - 14:26

ich hab folgendes Problem: Apache 1.3 mit mod_dav (Debian stable); mod_dav aktiviert, geschuetzt mit basic authentifizierung, funktioniert ohne Probleme mit z.B. Windows File-Explorer.

Wenn ich jetzt aber von einem Mac OS X - Rechner aus Versuche (mit Goliath oder davfs) schlaegt dies immer fehl (davfs meldet Fehler -34, Datei nicht vorhanden). Im Prinzip das, was sich mir am Server-Log wiederspiegelt; die Zugriffe der Mac OS X Software enthalten immer einen Slash am Ende; der Zugriff vom Windows File-Explorer nicht.

Log-Auszuege, funktioniert:
"PROPFIND /webdav HTTP/1.1" 207 1005 "-" "Microsoft Data Access...

Funktioniert nicht:
"PROPFIND /webdav/ HTTP/1.1" 404 213 "-" "Goliath/1.0 (Macintosh-Carbon;...

Ich habs auch mit telnet getestet; kann ich nur bestaetigen. Wenn ich mit Slash hinten dran den Zugriff schreibe, gehts nicht; ohne schon.

Ich hab auch verschiedene Angaben bei der URL der Client-Zugriffe formuliert (mit und ohne Slash eben); ohne Erfolg. Der File-Explorer von Windwos scheint den Slash immer zu "vergessen".

Hat jemand vielleicht eine Idee an was es liegen kann? Ich gehe mal davon aus, das die Art und Weise wie die Clients versuchen zuzugreifen nicht falsch ist sondern es an einer Webserver-Konfiguration liegt; ich aber keine Idee habe was dafuer verantwortlich sein koennte.

Die Einbindung sieht derzeit so aus:

Code:

Alias   /webdav <lokaler pfad>
<Location /webdav>
	DAV	On
	ForceType	text/plain
	AuthType	Basic
	AuthName	webdav
	AuthUserFile	<pfad zum userfile>
	require	valid-user
</Location>

Wenn ich GET verwende (mit und ohne Slash) bekomme ich folgendes:

(ohne Slash)

Code:

GET /webdav HTTP/1.1
Host: [url]www.meinhost.at[/url]

HTTP/1.1 301 Moved Permanently
Date: Mon, 24 Nov 2003 21:37:00 GMT
Location: [url]http://www.meinhost.at/webdav/[/url]
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

(mit Slash)

Code:

	
GET /webdav/ HTTP/1.1
Host: [url]www.meinhost.at[/url]

HTTP/1.1 200 OK
[... normaler inhalt kommt, in meinem Fall aufgrund von ForceType
text/plain die index.php im source]

Jetzt wo ich das probiert hab frage ich warum ein Zugriff auf /webdav ein redirect auf /webdav/ ergibt ...

Ich hab mal den Tipp bekommen, das koennte mit mod_dir zusammenliegen. Es aendert aber auch nichts wenn ichs deaktiviere. Und ich hab bei Gott keine Ahnung, warum der MacOS-client den Slash am Schluss macht, den ich als einizgen Unterschied erkennen kann. Auch wenn ich den trailing Slash nicht beim Verbindngen angebe, macht er immer einen.

SYSMATRIX

Legend
Legend

Registered: May 2000
Location: ~
Posts: 5020

17.03.2004 - 16:44

schon mal einen anderen DAV client versucht?
welche mod_dav version?

is zwar nicht das problem das du hast, aber aehnlich. der trailing slash scheint problembehaftet zu sein. laut meiner research im web scheint das wirklich windows only richtig gemacht zu sein (trailing slash wird mit und ohne angabe weggelassen).

quelle: http://www.webdav.org/mod_dav/problems.html):
Fixed in 0.9.4

*

DELETE on an empty collection fails, starting with 0.9.2.
*

MKCOL with a trailing slash on the URI fails. Similarly, COPY or MOVE with a trailing slash on the Destination fails.

mal in den source code reingeschaut und mit nach trailing slash gegreppt:

Code: PHP

    /*
    ** Prepare the input URI. We want the URI to never have a trailing slash.
    **
    ** When URIs are placed into the dav_if_header structure, they are
    ** guaranteed to never have a trailing slash. If the URIs are equivalent,
    ** then it doesn't matter if they both lack a trailing slash -- they're
    ** still equivalent.
    **
    ** Note: we could also ensure that a trailing slash is present on both
    ** URIs, but the majority of URIs provided to us via a resource walk
    ** will not contain that trailing slash.
    */
    uri = resource->uri;
    uri_len = strlen(uri);
    if (uri[uri_len - 1] == '/') {
	dav_set_bufsize(p, pbuf, uri_len);
	memcpy(pbuf->buf, uri, uri_len);
	pbuf->buf[--uri_len] = '\0';
	uri = pbuf->buf;
    }

vielleicht könntest du dich mit einer BrowserMatch direktive helfen?

Rektal

Here to stay

Registered: Dec 2002
Location: Inside
Posts: 4452

17.03.2004 - 18:04

Hmm .. also den Client kann ich mir nicht aussuchen. Ich mein, es sollen halt andere Leute von uns in der Firma die WebDAV Resourcen ansprechen koennen. Manche haben MacOS X und das hat ja ein eingebautes DAVFS.

Die Version ist 1.0.3 (?), naja es ist eben das woody Debian package

Ok, ich werd das mal mit den sourcen checken und eine self-compiled version probieren. Irgendwie hab ich das bis jetzt nicht in erwaegung gezogen weil ich so compile-faul bin. Scheint aber eine gute Idee zu sein, thx.

Btw, was genau meinst du mit der BrowserMatch-Direktive? Das verhalten von mod_dav selbst kann ich ja bez. des Trailing-Slash nicht veraendern.

An was ich auch gedacht habe, waere, mit mod_rewrite dir Requests umzuschreiben. Aber ich denke eher mal checken ob das Problem nicht wikrlich an mod_dav liegt waere schlauer.

Rektal

Here to stay

Registered: Dec 2002
Location: Inside
Posts: 4452

18.03.2004 - 21:30

Ahm, also, die letzte Apache 1.x mod_dav source version die ich gefunden habe matcht mti denen von Debian-woody.

Noch jemand vorschlaege ...?

Rektal

Here to stay

Registered: Dec 2002
Location: Inside
Posts: 4452

28.03.2004 - 20:06

Push.

Weiter Hints sind erwuenscht

Rektal Here to stay Registered: Dec 2002 Location: Inside Posts: 4452	17.03.2004 - 14:26 ich hab folgendes Problem: Apache 1.3 mit mod_dav (Debian stable); mod_dav aktiviert, geschuetzt mit basic authentifizierung, funktioniert ohne Probleme mit z.B. Windows File-Explorer. Wenn ich jetzt aber von einem Mac OS X - Rechner aus Versuche (mit Goliath oder davfs) schlaegt dies immer fehl (davfs meldet Fehler -34, Datei nicht vorhanden). Im Prinzip das, was sich mir am Server-Log wiederspiegelt; die Zugriffe der Mac OS X Software enthalten immer einen Slash am Ende; der Zugriff vom Windows File-Explorer nicht. Log-Auszuege, funktioniert: "PROPFIND /webdav HTTP/1.1" 207 1005 "-" "Microsoft Data Access... Funktioniert nicht: "PROPFIND /webdav/ HTTP/1.1" 404 213 "-" "Goliath/1.0 (Macintosh-Carbon;... Ich habs auch mit telnet getestet; kann ich nur bestaetigen. Wenn ich mit Slash hinten dran den Zugriff schreibe, gehts nicht; ohne schon. Ich hab auch verschiedene Angaben bei der URL der Client-Zugriffe formuliert (mit und ohne Slash eben); ohne Erfolg. Der File-Explorer von Windwos scheint den Slash immer zu "vergessen". Hat jemand vielleicht eine Idee an was es liegen kann? Ich gehe mal davon aus, das die Art und Weise wie die Clients versuchen zuzugreifen nicht falsch ist sondern es an einer Webserver-Konfiguration liegt; ich aber keine Idee habe was dafuer verantwortlich sein koennte. Die Einbindung sieht derzeit so aus: Code: `Alias /webdav <lokaler pfad> <Location /webdav> DAV On ForceType text/plain AuthType Basic AuthName webdav AuthUserFile <pfad zum userfile> require valid-user </Location>` Wenn ich GET verwende (mit und ohne Slash) bekomme ich folgendes: (ohne Slash) Code: `GET /webdav HTTP/1.1 Host: [url]www.meinhost.at[/url] HTTP/1.1 301 Moved Permanently Date: Mon, 24 Nov 2003 21:37:00 GMT Location: [url]http://www.meinhost.at/webdav/[/url] Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1` (mit Slash) Code: `GET /webdav/ HTTP/1.1 Host: [url]www.meinhost.at[/url] HTTP/1.1 200 OK [... normaler inhalt kommt, in meinem Fall aufgrund von ForceType text/plain die index.php im source]` Jetzt wo ich das probiert hab frage ich warum ein Zugriff auf /webdav ein redirect auf /webdav/ ergibt ... Ich hab mal den Tipp bekommen, das koennte mit mod_dir zusammenliegen. Es aendert aber auch nichts wenn ichs deaktiviere. Und ich hab bei Gott keine Ahnung, warum der MacOS-client den Slash am Schluss macht, den ich als einizgen Unterschied erkennen kann. Auch wenn ich den trailing Slash nicht beim Verbindngen angebe, macht er immer einen.
SYSMATRIX Legend Legend Registered: May 2000 Location: ~ Posts: 5020	17.03.2004 - 16:44 schon mal einen anderen DAV client versucht? welche mod_dav version? is zwar nicht das problem das du hast, aber aehnlich. der trailing slash scheint problembehaftet zu sein. laut meiner research im web scheint das wirklich windows only richtig gemacht zu sein (trailing slash wird mit und ohne angabe weggelassen). quelle: http://www.webdav.org/mod_dav/problems.html): Fixed in 0.9.4 * DELETE on an empty collection fails, starting with 0.9.2. * MKCOL with a trailing slash on the URI fails. Similarly, COPY or MOVE with a trailing slash on the Destination fails. mal in den source code reingeschaut und mit nach trailing slash gegreppt: Code: PHP /* Prepare the input URI. We want the URI to never have a trailing slash. When URIs are placed into the dav_if_header structure, they are guaranteed to never have a trailing slash. If the URIs are equivalent, then it doesn't matter if they both lack a trailing slash -- they're still equivalent. Note: we could also ensure that a trailing slash is present on both URIs, but the majority of URIs provided to us via a resource walk will not contain that trailing slash. */ uri = resource->uri; uri_len = strlen(uri); if (uri[uri_len - 1] == '/') { dav_set_bufsize(p, pbuf, uri_len); memcpy(pbuf->buf, uri, uri_len); pbuf->buf[--uri_len] = '\0'; uri = pbuf->buf; } vielleicht könntest du dich mit einer BrowserMatch direktive helfen?
Rektal Here to stay Registered: Dec 2002 Location: Inside Posts: 4452	17.03.2004 - 18:04 Hmm .. also den Client kann ich mir nicht aussuchen. Ich mein, es sollen halt andere Leute von uns in der Firma die WebDAV Resourcen ansprechen koennen. Manche haben MacOS X und das hat ja ein eingebautes DAVFS. Die Version ist 1.0.3 (?), naja es ist eben das woody Debian package Ok, ich werd das mal mit den sourcen checken und eine self-compiled version probieren. Irgendwie hab ich das bis jetzt nicht in erwaegung gezogen weil ich so compile-faul bin. Scheint aber eine gute Idee zu sein, thx. Btw, was genau meinst du mit der BrowserMatch-Direktive? Das verhalten von mod_dav selbst kann ich ja bez. des Trailing-Slash nicht veraendern. An was ich auch gedacht habe, waere, mit mod_rewrite dir Requests umzuschreiben. Aber ich denke eher mal checken ob das Problem nicht wikrlich an mod_dav liegt waere schlauer.
Rektal Here to stay Registered: Dec 2002 Location: Inside Posts: 4452	18.03.2004 - 21:30 Ahm, also, die letzte Apache 1.x mod_dav source version die ich gefunden habe matcht mti denen von Debian-woody. Noch jemand vorschlaege ...?
Rektal Here to stay Registered: Dec 2002 Location: Inside Posts: 4452	28.03.2004 - 20:06 Push. Weiter Hints sind erwuenscht

mod_dav und 404-Problem mit Clients (Goliath, darin davfs)

Forum Index > Software > Linux and other OS

Rektal

SYSMATRIX

Rektal

Rektal

Rektal