Beim Versuch, ein Verzeichnis aufzulisten, das einen defekten Link enthält, erhalte ich einen nicht informativen Fehler:
$ cadaver webdav://localhost:5555/api/v1/content
dav:/api/v1/content/> ls etc
Listing collection `/api/v1/content/etc/': failed:
XML parse error at line 1: junk after document element
Das bekomme ich vom Webdav-Server:
2016/06/27 14:52:42 http: multiple response.WriteHeader calls
Der Fehler kommt von file.go [1], wo es stat für die defekte Link-Datei aufruft, aber ich denke, dass es vielleicht in webdav.go walkFn [2] behandelt werden sollte.
Ich bin mir selbst nicht sicher, was gedruckt / zurückgegeben werden soll, aber ich würde erwarten, die vollständige Verzeichnisliste zu erhalten (dh Webdav sollte meiner Meinung nach nicht darauf eingehen) mit diesem Link, der irgendwie als defekt markiert ist.
[1] https://github.com/golang/net/blob/master/webdav/file.go#L779
[2] https://github.com/golang/net/blob/master/webdav/webdav.go#L527
/cc @simon3z
Ich stoße gerade auf dieses Problem. Ich habe es lokal behoben, indem ich einfach Null zurückgegeben habe, wenn hier ein Fehler angezeigt wurde https://github.com/golang/net/blob/master/webdav/webdav.go#L557.
Ich habe den gleichen Anwendungsfall mit der Apache-Implementierung getestet und im Falle eines defekten Symbollinks wird er stillschweigend verworfen.
Ich weiß nicht, ob es eine ausreichend gute Lösung ist, aber das heutige Verhalten ist auch falsch.
Hier ist eine Wireshark-Spur der fehlerhaften Antwort
Host: 10.21.59.204
Depth: 1
Content-Type: application/xml
Apply-To-Redirect-Ref: T
Accept-Encoding: gzip, deflate
User-Agent: gvfs/1.28.2
Accept-Language: en-us, en;q=0.9
Connection: Keep-Alive
Content-Length: 235
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:creationdate/>
<D:displayname/>
<D:getcontentlength/>
<D:getcontenttype/>
<D:getetag/>
<D:getlastmodified/>
<D:resourcetype/>
</D:prop>
</D:propfind>HTTP/1.1 207 status code 207
Content-Type: text/xml; charset=utf-8
Date: Wed, 15 Mar 2017 09:00:40 GMT
Content-Length: 610
<?xml version="1.0" encoding="UTF-8"?><D:multistatus xmlns:D="DAV:"><D:response><D:href>/dav</D:href><D:propstat><D:prop><D:displayname></D:displayname><D:getlastmodified>Wed, 15 Mar 2017 08:59:55 GMT</D:getlastmodified><D:resourcetype><D:collection xmlns:D="DAV:"/></D:resourcetype></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propstat><D:propstat><D:prop><D:creationdate></D:creationdate><D:getcontentlength></D:getcontentlength><D:getcontenttype></D:getcontenttype><D:getetag></D:getetag></D:prop><D:status>HTTP/1.1 404 Not Found</D:status></D:propstat></D:response></D:multistatus>Internal Server Error
In der Webdav Spec heißt es, dass
Im Fall von allprop und propname, wenn ein Prinzipal nicht über die
Recht zu wissen, ob eine bestimmte Eigenschaft existiert, dann die Eigenschaft
sollten stillschweigend von der Antwort ausgeschlossen werden.
Ich weiß nicht, ob dies in unserem Anwendungsfall zutrifft
Ich denke, ein 4XX
Statuscode sollte zurückgegeben werden, wenn auf defekte Links zugegriffen wird, genauer gesagt 403 Forbidden
für Links, die mit Zielen außerhalb der Berechtigung verknüpft sind, und 404 Not Found
für verlinkte Links zu nicht existierenden Zielen.
Derzeit werden Fehler, die von FileSystem.OpenFile
oder File.Stat
, in http.StatusInternalServerError
und verursachen "http: überflüssige Antwort.WriteHeader-Aufruf von golang.org/x/net/webdav.(*Handler) .ServeHTTP (webdav.go:74)"
Änderung https://golang.org/cl/249797 erwähnt dieses Problem: webdav: ignore os.PathError in PROPFIND
Hilfreichster Kommentar
Ich stoße gerade auf dieses Problem. Ich habe es lokal behoben, indem ich einfach Null zurückgegeben habe, wenn hier ein Fehler angezeigt wurde https://github.com/golang/net/blob/master/webdav/webdav.go#L557.
Ich habe den gleichen Anwendungsfall mit der Apache-Implementierung getestet und im Falle eines defekten Symbollinks wird er stillschweigend verworfen.
Ich weiß nicht, ob es eine ausreichend gute Lösung ist, aber das heutige Verhalten ist auch falsch.
Hier ist eine Wireshark-Spur der fehlerhaften Antwort
In der Webdav Spec heißt es, dass
Ich weiß nicht, ob dies in unserem Anwendungsfall zutrifft