Go: x/net/webdav: schlägt bei defekten Links fehl

Erstellt am 27. Juni 2016  ·  3Kommentare  ·  Quelle: golang/go

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

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

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

Alle 3 Kommentare

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

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Miserlou picture Miserlou  ·  3Kommentare

jayhuang75 picture jayhuang75  ·  3Kommentare

myitcv picture myitcv  ·  3Kommentare

natefinch picture natefinch  ·  3Kommentare

bbodenmiller picture bbodenmiller  ·  3Kommentare