Go: x/net/webdav: falla en enlaces rotos

Creado en 27 jun. 2016 · 3Comentarios · Fuente: golang/go

Cuando intento enumerar un directorio que contiene un enlace roto, aparece un error no informativo:

$ 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

Esto es lo que obtengo del servidor webdav:

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

El error proviene de file.go [1] donde llama a stat en el archivo de enlace roto, pero creo que tal vez debería manejarse en webdav.go walkFn [2].

No estoy seguro de lo que se debe imprimir / devolver, pero esperaría obtener la lista completa del directorio (es decir, en mi opinión, webdav no debería enamorarse de esto) con este enlace marcado como roto de alguna manera.

[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

Fuente

enoodle

Comentario más útil

Acabo de encontrar este problema. Lo arreglé localmente simplemente devolviendo cero cuando recibía un error aquí https://github.com/golang/net/blob/master/webdav/webdav.go#L557.

Probé el mismo caso de uso con la implementación de Apache y, en el caso de un enlace simbólico roto, se descarta silenciosamente.

No sé si es una solución lo suficientemente buena, pero el comportamiento de hoy también es incorrecto.
Aquí hay un rastro de wireshark de la respuesta defectuosa

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

En Webdav Spec se dice que

En el caso de allprop y propname, si un principal no tiene la
derecho a saber si existe una propiedad en particular, entonces la propiedad
debe ser silenciosamente excluido de la respuesta.

No sé si esto se aplica en nuestro caso de uso.

skritchz en 15 mar. 2017

👍2

Todos 3 comentarios