Go: x/net/webdav : échoue sur les liens cassés

Créé le 27 juin 2016 · 3Commentaires · Source: golang/go

Lorsque j'essaie de répertorier un répertoire contenant un lien rompu, j'obtiens une erreur non informative :

$ 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

Voici ce que j'obtiens du serveur webdav :

2016/06/27 14:52:42 http: multiple response.WriteHeader calls

L'erreur vient de file.go [1] où elle appelle stat sur le fichier de lien cassé mais je pense que cela devrait peut-être être géré dans webdav.go walkFn [2].

Je ne suis pas sûr moi-même de ce qui devrait être imprimé / renvoyé, mais je m'attendrais à obtenir la liste complète des répertoires (c'est-à-dire que Webdav ne devrait pas écraser cela à mon avis) avec ce lien marqué d'une manière ou d'une autre.

[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

Source

enoodle

Commentaire le plus utile

Je viens de rencontrer ce problème. Je l'ai corrigé localement en renvoyant simplement nil lors de l'obtention d'une erreur ici https://github.com/golang/net/blob/master/webdav/webdav.go#L557.

J'ai testé le même cas d'utilisation avec l'implémentation d'Apache et dans le cas d'un lien symbolique cassé, il est ignoré en silence.

Je ne sais pas si c'est une solution assez bonne, mais le comportement d'aujourd'hui est également incorrect.
Voici une trace wireshark de la réponse défectueuse

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

Dans le Webdav Spec, il est dit que

Dans le cas de allprop et propname, si un principal n'a pas le
droit de savoir si une propriété particulière existe, alors la propriété
devraient être silencieusement exclus de la réponse.

Je ne sais pas si cela s'applique à notre cas d'utilisation

skritchz le 15 mars 2017

👍2

Tous les 3 commentaires