요약

  • WebDAV 바인딩은 여러 URI가 하나의 리소스에 도달할 수 있게 합니다. 해당 리소스가 컬렉션이라면, 두 번째 바인딩은 같은 하위 항목들을 다른 경로로 노출할 수 있고, 심지어 순환을 만들 수도 있습니다.
  • 바인딩을 인식하는Depth: infinityPROPFIND에서는 컬렉션에 대한 하나의 바인딩이 200으로 보고됩니다. 이후의 바인딩들은 208 Already Reported로 계속 보이지만, 그 하위 항목들은 다시 열거되지 않습니다.
  • DAV:resource-id는 바뀌는 경로 아래에서 안정적인 리소스 식별성을 제공합니다. 올바른 클라이언트는 공유된 컬렉션을 한 번만 확장하면서도 모든 바인딩 간선을 보존합니다. 인식하지 못하는 클라이언트는 압축된 구조를 해석하지 못한 채 508을 통해 루프 실패를 받게 됩니다.

두 개의 문이 하나의 방으로 열리도록 허용되었다

이름표가 붙은 두 개의 문이 있는 기록 보관소를 상상해 보십시오. 각 문은 실재하고, 서로 다른 복도에 속하며, 둘 다 같은 기록실로 열립니다. 어느 한쪽 문을 제거하면 기록 보관소의 동선이 바뀌지만, 다른 문이 남아 있는 한 그 방이 사라지지는 않습니다.

이제 목록 시스템에게 모든 복도를 걸어 각 문 아래의 모든 캐비닛을 나열하라고 해 보십시오. 경로를 대상 자체로 취급하면 같은 방을 두 번 목록화하게 됩니다. 방의 복도 하나가 조상으로 되돌아간다면 목록은 끝나지 않을 수 있습니다. 방을 인식한 순간 두 번째 경로를 그냥 삭제하면, 건물을 왜곡한 유한한 목록이 만들어집니다.

HTTP 208은 빠져 있던 네 번째 선택지를 표현했습니다. 두 번째 문을 기록하되, 그것이 이미 확장된 방에 도달함을 증명하고, 방의 하위 항목을 다시 걷지는 마십시오.

그 결과는 트리 열거도 아니고, 공격적인 중복 제거도 아니었습니다. 두 종류의 식별성으로 보고된 그래프였습니다.

WebDAV는 이미 컬렉션 결과를 복수형으로 만들어 두었다

RFC 4918, 즉 2007년 WebDAV 사양은 컬렉션을 경로 세그먼트와 리소스 사이의 매핑과 그 컬렉션에 놓인 속성으로 기술합니다. 따라서 멤버 이름은 리소스 그 자체가 아닙니다. 요청이 리소스에 도달하는 경로의 일부입니다.

PROPFIND는 클라이언트가 깊이 0, 1 또는 무한대에서 속성을 살펴보도록 합니다. 무한 깊이 요청은 컬렉션과 모든 하위 항목을 요구합니다. 결과는 멤버마다 중첩된 HTTP 응답이 아닙니다. 서버는href와 속성 상태를 가진 평평한DAV:response항목들로 이루어진 전체 207 Multi-Status 문서를 반환합니다.

이 구조는 이미 클라이언트에게 외부 전송 결과와 내부 계정을 분리하도록 요구했습니다. 전체 207에는 여러 상태가 섞여 있을 수 있었습니다. 클라이언트는 응답 전체를 하나의 판정으로 취급하는 대신 각 response와 각propstat를 점검해야 했습니다.

RFC 4918은 또한 하나의 리소스가 여러 URI로 식별될 수 있음을 인정했습니다. 다만 아직 제공하지 않은 것은 기존 리소스에 대한 새 접근 경로를 만드는 데 전념하는 클라이언트 메서드였습니다.

BIND는 새 리소스가 아니라 새 이름을 만들었다

2010년 4월에 발표된 실험적RFC 5842는 WebDAV에 BIND, UNBIND, REBIND를 추가했습니다. BIND는 컬렉션 안의 새 경로 세그먼트를 기존 리소스와 연결합니다. 그 결과 만들어진 URI는 다른 매핑된 URI와 마찬가지로 해당 리소스에 메서드를 보내는 데 쓸 수 있습니다.

아무것도 복사되지 않습니다. 새로 생긴 것은 바인딩이지 리소스가 아닙니다. 서로 다른 두 컬렉션이 각각 같은 리소스를 가리키는 바인딩을 포함할 수 있고, 그 둘은 서로 구별되는 컬렉션 상태입니다.

이 구분에는 운영상의 결과가 있습니다. 바인딩 하나를 제거하는 일이 다른 바인딩을 끊긴 경로로 만들어서는 안 됩니다. 다른 바인딩이 남아 있는 동안 서버는 리소스를 회수해서는 안 됩니다. 바인딩 무결성이란, 어떤 작업이 명시적으로 그 바인딩을 제거하거나 바꾸기 전까지는 경로가 계속 존재하며 계속 같은 리소스를 식별한다는 뜻입니다.

따라서 별칭은 버릴 수 있는 장식이 아닙니다. 공유된 대상으로 이어지는, 독립적으로 관리되는 간선입니다.

바인딩된 컬렉션은 그 아래의 경로를 배수로 늘렸다

새 바인딩이 평범한 리프 리소스를 가리킬 때, 그것은 그 리소스로 가는 또 하나의 URI 매핑을 만듭니다. 컬렉션을 가리킬 때는, 새로운 하위 바인딩이 하나도 추가되지 않았음에도 모든 하위 항목이 대응하는 새 URI 경로를 통해 도달 가능해집니다.

이 구분은 미묘합니다. 자식 관계는 여전히 그 하나의 컬렉션의 상태입니다. 그러나 컬렉션 자체가 이제 두 경로를 가지므로, 그 관계들을 두 접두어 아래에서 순회할 수 있습니다.

컬렉션이 자기 자신이나 자신의 조상 중 하나에 바인딩되면 그 효과는 무한해집니다. 네임스페이스는 무한 개의 리소스를 만들지 않고도/myself,/myself/myself,/myself/myself/myself등을 생성할 수 있습니다. 무한해지는 것은 반복 순회가 만드는 URI 매핑의 집합입니다.

서버는Depth: infinity를 처리하는 동안 컬렉션 바인딩 루프를 감지해야 합니다. 루프 지원은 선택 사항이므로 서버는 루프 생성 자체를 거부할 수 있습니다. 그러나 루프가 허용된다면, 순회는 계층구조가 여전히 단순한 트리인 것처럼 행세할 수 없습니다.

안정적인 리소스 식별성은 바뀌는 경로 아래에 놓여 있었다

경로 일치로는 문제를 해결할 수 없습니다. 요점 자체가 서로 다른 경로가 하나의 리소스에 도달할 수 있다는 것이기 때문입니다. 내용 일치로도 해결할 수 없습니다. 서로 독립적인 두 리소스가 우연히 동일한 바이트와 속성을 담고 있을 수 있습니다.

그래서 RFC 5842는DAV:resource-id를 요구합니다. 이 값은 리소스가 생성될 때 할당되고, 모든 시대에 걸쳐 모든 리소스에 대해 고유해야 하며, 기존 리소스가 갱신되거나 다시 바인딩되어도 바뀌어서는 안 되고, 리소스가 URI를 통해 더 이상 도달할 수 없게 된 뒤에도 재할당되어서는 안 됩니다.

서로 다른 바인딩을 통해 얻은 두 PROPFIND 결과가 문자 하나까지 동일한 리소스 ID를 반환한다면, 클라이언트는 그 바인딩들이 같은 리소스에 도달한다는 것을 알 수 있습니다. 이 식별자는 선호 주소가 아닙니다. 주소가 늘어나거나 옮겨지는 동안에도 안정적으로 유지됩니다.

이것이 208이 필요로 하는 증거입니다. 클라이언트는 “이미 확장한 것에 대한 또 다른 경로”와 “비슷하게 보이는 또 다른 대상”을 구별할 수 있습니다.

무한 깊이는 계층구조를 그래프 순회로 바꾸었다

전통적인 디렉터리 순회기는 흔히 작업을 경로명으로 구분합니다. 경로를 방문하고, 자식을 열거하고, 재귀합니다. 바인딩은 경로 식별성과 리소스 식별성이 갈라지므로 그 규칙을 위험하게 만듭니다.

경로만으로 구분하면 모든 경로는 보존되지만 하나의 컬렉션을 반복해서 확장하고 순환을 영원히 따라갈 수 있습니다. 리소스 ID만으로 구분하면 반복 작업은 피하지만, 바인딩이 기록되기 전에 적용하면 실제 네임스페이스 간선을 지워 버립니다. 그러면 클라이언트는 대상 자체는 알지만 그것에 도달할 수 있는 모든 위치는 알지 못합니다.

충실한 순회에는 두 개의 장부가 필요합니다. 하나는 바인딩 경로를 기록하고, 다른 하나는 이 응답에서 어떤 컬렉션 식별자의 하위 항목이 이미 열거되었는지를 기록합니다.

HTTP 208은 그 두 장부를 잇는 프로토콜 표식입니다. 즉, 이 경로를 첫 장부에 남기고, 그 아래 새로운 하위 트리가 따르지 않는 이유는 두 번째 장부가 설명한다는 것입니다.

208은 별칭을 남기고 반복만 제거했다

정확한 규칙은 협소합니다. 서버는Depth: infinity요청의DAV:propstatresponse 요소 안에서 208을 사용할 수 있습니다. 범위 안의 같은 컬렉션에 대한 바인딩들 가운데 하나는 200으로 보고됩니다. 나머지 바인딩들에 대한 이후의DAV:response항목은 208을 담으며, 그 하위 항목들은 다시 포함되지 않습니다.

이후의 response 항목이 사라지는 것은 아닙니다. 그href는 여전히 대체 경로를 식별하며, 클라이언트는DAV:resource-id를 요청하고 비교하여 바인딩 구조를 정확히 재구성할 수 있습니다. 사라지는 것은 200 발생을 통해 이미 보고된 하위 항목들의 두 번째 열거뿐입니다.

RFC의 루프 예제에서/Coll/과/Coll/Bar는 같은 컬렉션 식별자를 노출합니다. 첫 번째는 200을 받고 멤버가 나열됩니다. 두 번째는 208을 받습니다. 그 경로 뒤의 컬렉션은 이미 걸어졌으므로/Coll/Bar/Bar/Bar행렬은 나타나지 않습니다.

“이미 보고됨”은 이 Multi-Status 응답의 확장 이력을 수식할 뿐입니다. 별칭이 중요하지 않다고 선언하는 것은 아닙니다.

첫 번째 200은 정식 URI에 왕관을 씌우지 않았다

200으로 확장된 경로를 원본으로, 모든 208 경로를 열등한 복제본으로 취급하고 싶어집니다. 그러나 RFC 5842는 그런 권리의 위계를 만들지 않습니다.

바인딩들은 컬렉션 상태 안에서 서로 구별되는 관계입니다. 응답이 유한하도록 하기 위해 하위 항목 열거를 위한 하나의 발생을 선택해야 하지만, 그 선택이 그 URI를 영구적이거나 정식이거나 나머지를 파멸시킬 권리를 가진 것으로 만들지는 않습니다.

클라이언트가 네임스페이스 구조를 표시하거나, 감사 이력을 평가하거나, 나중에 바인딩을 제거할 때 이것이 중요합니다. 그래프를 하나의 선호 경로명으로 접으면 어느 컬렉션이 어느 간선을 소유하는지가 가려지고, 정당한 UNBIND가 리소스 자체의 삭제처럼 보이게 될 수 있습니다.

200과 208의 차이는 보고 작업에 국지적입니다. 소유권 규칙이 아닙니다.

207은 여전히 봉투였다

HTTP 클라이언트는 보통 요청 수준의 응답, 즉 207 Multi-Status를 먼저 봅니다. 208은 response 항목 중 하나의 속성 상태 안에 나타납니다.

이 중첩은 두 가지 실수를 막습니다. 최상위 2xx 결과만으로 클라이언트에게 모든 하위 항목이 독립적으로 확장되었다고 말할 수는 없습니다. 반대로 내부 208이 전체 요청이 반복된 요청이었거나 모든 리소스가 이전에 반환되었다는 뜻도 아닙니다.

외부 계층은 상세 계정이 본문에 있다고 말합니다. 내부의 200과 208 값은 각 바인딩 발생이 그 계정에 어떻게 참여했는지를 말합니다.href는 경로 식별성을 보존하고,DAV:resource-id는 같은 대상에 도달하는 경로들을 연결하며, 하위 항목의 존재나 부재는 어느 발생이 순회 비용을 지불했는지를 보여줍니다.

이 계층들을 “요청 성공” 하나로 납작하게 만들면, 유한한 그래프 보고를 가능하게 한 구조가 사라집니다.

압축에는 사전 이해가 필요했다

반복된 하위 트리를 생략하는 일은 수신자가 그 부재의 이유를 이해할 때만 안전합니다. 그래서 RFC 5842는 208을 기능 신호에 묶었습니다.

바인딩을 지원하는 서버는 OPTIONS에 대한 응답의DAV헤더에bind컴플라이언스 클래스를 알립니다. 클라이언트는 지원을 신호하기 위해DAV: bind를 보내야 하고, 특히 208을 이해해야 합니다.

하위 호환성을 위해 서버는 클라이언트가 그 신호를 보내지 않았다면 Multi-Status 본문에서 208을 사용해서는 안 됩니다. 낡은 클라이언트는 알 수 없는 속성 상태를 실패로 취급하거나, 경로는 남기되 자식이 존재하지 않는다고 잘못 결론지을 수 있습니다.

절약된 반복은 서버만의 비공개 최적화가 아닙니다. 두 끝점 사이의 공유된 해석 계약입니다.

508은 실패였지, 208의 더 강한 철자가 아니었다

바인딩을 인식하지 못하는 무한 깊이 클라이언트가 바인딩 루프에 부딪히면, 사양은 클라이언트가 해석할 수 없는 208에 의존하는 대신 508 Loop Detected로 서버를 유도합니다. 루프가 응답 스트리밍이 시작되기 전에 발견되면 508이 최상위 결과가 될 수 있습니다. 스트리밍되는 Multi-Status 도중에 발견되면 실패는 그 안에서 표현될 수 있습니다.

제어 결과가 다릅니다. 208이면 바인딩을 인식하는 순회는 계속될 수 있습니다. 별칭은 기록되고 반복된 하위 항목은 억제됩니다. 508이면 서버는 무한 순회에 부딪혔기 때문에 종료되고 작업은 실패합니다.

508을 반환하면 유용한 부분적 시야를 희생할 수 있지만, 인식하지 못하는 클라이언트가 자신이 설명할 수 없는 생략을 담은 구조를 받아들이게끔 유도하지는 않습니다. 합의 없이 208을 반환하는 것은 더 이용 가능해 보이면서 조용히 거짓 트리를 만들 수 있습니다.

호환성은 때때로 불완전하게 이해된 성공보다 명시적인 정지를 선호합니다.

같은 그래프는 보안 비용도 만들었다

바인딩은 표현력과, 서버가 구별해서 유지해야 하는 식별자의 수를 늘립니다. RFC 5842는 클라이언트가 실수로든 악의적으로든 루프를 만들 수 있음을 지적하고 무한 깊이 처리 중의 루프 감지를 요구합니다.

사양은 서비스 거부 및 개인정보 위험도 지목합니다. 서버 간 바인딩은 그 부하를 위해 설계되지 않은 대상으로 사용을 유도할 수 있습니다. 선택 사항인DAV:parent-set속성은 디렉터리 위치를 드러낼 수 있고, 다른 관리 도메인의 영향을 받는 목록을 서버가 유지한다면 그 자체가 자원 고갈 표면이 될 수 있습니다.

208은 하나의 응답 안에서 반복 열거를 제어합니다. 그러나 완전한 리소스 예산, 인가 정책, 적대적 바인딩 생성에 대한 방어를 제공하지는 않습니다. 유한한 그래프 순회조차 너무 클 수 있고, 정확히 기록된 대체 경로조차 민감한 구조를 드러낼 수 있습니다.

이 상태 코드는 하나의 증폭 메커니즘을 담고 있을 뿐입니다. 누가 간선을 만들 수 있고 순회가 얼마나 소비할 수 있는지를 다스려야 할 필요를 없애지 않습니다.

라이브 속성은 경로를 그림 안에 남겨 두었다

리소스 ID가 동일하다고 해서 두 바인딩을 통해 얻은 모든 답이 바이트 단위로 동일해야 하는 것은 아닙니다. 데드 속성 값은 바인딩 수와 제출된 경로와 무관하지만, 라이브 속성은 자기 자신의 정의를 따르며 경로 관련 동작을 가질 수 있습니다.

따라서 모든 속성을 오직 리소스 ID로만 병합하는 클라이언트는 문맥을 지울 수 있습니다. 모든 속성 발생을 서로 다른 리소스의 증거로 취급하는 클라이언트는 반대 방향의 오류를 저지릅니다.

유용한 데이터 모델은 리소스 사실, 바인딩 사실, 경로 의존적 관찰을 따로 보존합니다. 그것은 208 자체가 표현하는 얇은 규율과 같습니다. 올바른 조율에 필요한 최소한의 식별성만 공유하고, 한 계층의 증거를 다른 모든 계층에 대한 권위로 승격시키지 마십시오.

복수의 경로는 그 밑의 대상을 배수하지 않고도 복수로 남을 수 있습니다.

IANA는 “다시 재귀하지 마십시오”를 뜻하는 성공을 등록했다

현재IANA HTTP 상태 코드 레지스트리는 208 Already Reported를 참조 문서 RFC 5842와 함께 나열합니다. 같은 실험적 문서가 508을 정의했고, 207은 여전히 표준 트랙 WebDAV 사양을 가리킵니다.

이 등록이 바인딩 확장을 인터넷 표준으로 만들거나, 현재 배포를 증명하거나, 중복 데이터를 보는 모든 API로 208을 일반화하지는 않습니다. 그 정의된 자리는 여전히 WebDAV의 바인딩 인식, 무한 깊이, Multi-Status 순회입니다.

이것은 데이터베이스 중복 제거 결과도, 멱등성 영수증도, 캐시 검증자도, 클라이언트가 HTTP 요청을 반복했다는 신호도 아닙니다. 하나의 네임스페이스 계정 안의 관계를 보고하는 것입니다.

이 코드의 지속력은 사용 폭이 아니라 그 관계의 정밀성에서 나옵니다.

하나의 대상, 모든 경로, 한 번의 확장

HTTP 208은 그래프가 트리였다고 가장하지 않고 그래프 문제를 해결했습니다. 무한 반복과 파괴적 중복 제거 사이에서 선택하지도 않았습니다.

서버는 경로가 실제 네임스페이스 상태이기 때문에 각 바인딩 경로를 보고합니다. 리소스가 그 경로들 중 하나로 환원되지 않기 때문에 안정적인 식별자를 부여합니다. 반복되는 하위 항목이 새로운 리소스 구조를 더하지 않기 때문에 컬렉션을 한 번만 확장합니다. 설명 없는 생략은 누락된 데이터와 구별될 수 없기 때문에 208을 신호합니다.

이 배치는 의도적으로 겸손합니다. 어떤 중심 경로도 주권을 갖지 않습니다. 어떤 별칭도 복제본으로 승격되지 않습니다. 어떤 반복 순회도 무한한 목록을 만들어내도록 허용되지 않습니다.

두 번째 문은 도면에 남습니다. 그 뒤의 방을 두 번 세어야 할 필요는 없습니다.