Servicio HTTP y WebDAV con código 207: respuesta multiestado

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

1. 1

   Inspeccionar el cuerpo XML multistatus para listar cada URI en href y su código status interno

   Sin herramientas especiales

   Quién:

   Tú como persona desarrolladora o administradora revisando la traza HTTP del cliente o las herramientas de red.

   Cómo:

   Captura la respuesta HTTP 207 verificando que Content-Type sea application/xml o text/xml, abre el elemento raíz multistatus y recorre todos los bloques response extrayendo el identificador href y el código contenido en status o dentro de cada bloque propstat.

   Resultado que importa:

   Se separa el envoltorio HTTP 207 del resultado real devuelto para cada recurso o propiedad individual.

   Si todos los elementos status dentro de response o propstat contienen códigos 200 OK, 201 Created o 204 No Content, confirma que la operación múltiple se completó con éxito en todos los recursos.

   Si algún bloque response presenta un estado 4xx o 5xx (como 403, 404, 423, 424 o 507), confirma un fallo en ese href concreto e indica tratar ese código específico.

   Evidencia a conservar:

   Guarda el cuerpo XML completo de la respuesta 207 habiendo ocultado antes cabeceras Authorization, cookies o tokens.

   Evidencia: RFC 4918 - WebDAV

2. 2

   Distinguir el formato de estado de recurso completo frente al formato propstat de propiedades

   Sin herramientas especiales

   Quién:

   Tú analizando la estructura de los elementos response devueltos según el método WebDAV invocado.

   Cómo:

   Verifica si el método ejecutado fue de manipulación de recursos (DELETE, COPY, MOVE, LOCK), que devuelve un hijo directo href y un hijo status en cada response, o si fue PROPFIND / PROPPATCH, que agrupa las propiedades en uno o varios bloques propstat con sus propios elementos prop y status.

   Resultado que importa:

   Se comprueba que el parser del cliente lee la ruta XML correcta según el método WebDAV y que no aparecen códigos de la serie 100 dentro de response.

   Si el cliente buscaba un elemento status directo en una respuesta PROPFIND que usa propstat, confirma un defecto de parseo en el cliente y descarta un fallo del servidor WebDAV.

   Si el XML incluye descripciones en error o responsedescription junto a un estado 423 Locked o 424 Failed Dependency, indica identificar primero el recurso raíz que causó el bloqueo y no los nodos que fallaron en cascada por 424.

   Evidencia a conservar:

   Conserva el método HTTP enviado, las cabeceras Depth e If y el fragmento XML del bloque response o propstat afectado.

   Evidencia: RFC 4918 - WebDAV

3. 3

   Reproducir la operación sobre el único href que devolvió error interno fuera de la petición por lotes

   Sin herramientas especiales

   Quién:

   Tú desde un cliente WebDAV o consola de pruebas apuntando al recurso individual afectado.

   Cómo:

   Toma la URI exacta del elemento href que presentó el estado de error primario (descartando los que marquen 424 Failed Dependency por efecto colateral) y lanza una petición aislada sobre ese recurso verificando permisos, cabecera If con su lock token o cuota disponible.

   Resultado que importa:

   Se aísla el comportamiento del recurso conflictivo sin el ruido del resto de miembros de la colección.

   Si la petición individual devuelve directamente su código HTTP de error (por ejemplo 403 Forbidden o 423 Locked) y se resuelve al aportar el token o permiso adecuado, confirma que el 207 original solo encapsulaba ese rechazo puntual.

   Si el servidor devuelve un 207 con XML mal formado, sin elementos href obligatorios o con uso indebido de la cabecera Location, indica escalar la traza al equipo del servidor WebDAV.

   Evidencia a conservar:

   Registra la petición y respuesta del recurso individual junto con la marca temporal UTC.

   No elimines colecciones ni fuerces el desbloqueo (UNLOCK) de recursos compartidos en producción sin confirmar antes qué usuario o proceso posee el bloqueo.

   Evidencia: IANA HTTP Status Code Registry · RFC 4918 - WebDAV

Un código solo tiene significado dentro del producto y la versión correctos.

En el registro oficial HTTP de IANA y en RFC 4918 (WebDAV, secciones 11.1 y 13), el servidor devuelve el estado 207 (Multi-Status) para transmitir información sobre varios recursos cuando concurren distintos códigos de resultado en una consulta o petición (PROPFIND, PROPPATCH, COPY, MOVE, DELETE o LOCK). La entidad por defecto es un documento text/xml o application/xml con raíz multistatus y elementos response identificados por su URI en href. Como RFC 4918 permite usar 207 en éxito total, éxito parcial o fallo por bloqueo o token, el código 207 por sí solo nunca demuestra si la operación triunfó ni qué recurso falló sin leer el XML.

• Seguroadvertencia editorial

  Antes de compartir capturas o cuerpos XML de respuestas 207 con terceros o con soporte técnico, elimina las cabeceras Authorization, cookies de sesión y rutas privadas sensibles.

  Evidencia: RFC 4918 - WebDAV

• Precauciónverificada con fuente

  No trates nunca una respuesta HTTP 207 como confirmación de que todos los archivos o propiedades se guardaron o borraron: ignorar los códigos de error internos dentro de multistatus puede provocar pérdida silenciosa de sincronización.

  Evidencia: RFC 4918 - WebDAV

1. 1

   IANA HTTP Status Code Registry

   Internet Assigned Numbers Authority · 2025 · standard

2. 2

   RFC 4918 - WebDAV

   IETF / RFC Editor · 2007 · standard