WebDAV 프로토콜 안내서

1. 부: WebDAV의 탄생과 핵심 철학

1.1 서론: 월드 와이드 웹의 읽기/쓰기 매체로의 확장

월드 와이드 웹(World Wide Web)의 창시자 팀 버너스리(Tim Berners-Lee)가 구상했던 초기 웹의 비전은 단방향적인 정보 소비(읽기) 매체를 넘어, 사용자가 원격지의 콘텐츠를 직접 생성하고 수정(쓰기)할 수 있는 양방향 협업 플랫폼이었다.1 그러나 초기의 하이퍼텍스트 전송 프로토콜(HTTP/1.0)은 GET, HEAD, POST와 같은 제한된 메서드만을 제공하였고, 이는 복잡한 원격 저작(Remote Authoring) 및 관리 작업을 수행하기에는 근본적인 한계를 지니고 있었다.

웹이 폭발적으로 성장하면서, 개발자, 디자이너, 콘텐츠 제작자들은 원격 웹 서버에 있는 파일을 관리하기 위해 파일 전송 프로토콜(FTP)과 같은 별도의 프로토콜에 의존해야만 했다. 이 방식은 웹의 핵심 프로토콜인 HTTP와 이질적인 워크플로우를 강요했으며, 특히 방화벽 및 프록시 환경에서 복잡한 문제를 야기했다. 이러한 배경 속에서 웹의 기본 프로토콜인 HTTP의 틀 안에서 원격 콘텐츠를 직접, 그리고 여러 사용자가 협력하여 저작할 수 있는 표준화된 메커니즘의 필요성이 절실하게 대두되었다. WebDAV(Web Distributed Authoring and Versioning)는 바로 이러한 요구에 부응하기 위해 탄생한 HTTP의 핵심 확장 프로토콜이다.3

1.2 WebDAV의 역사적 발전 과정

WebDAV 프로토콜의 개발은 웹을 진정한 읽기/쓰기 매체로 만들고자 하는 열망에서 시작되었다. 그 과정은 기술적 이상과 현실적 제약 사이의 전략적 타협으로 점철되어 있다.

1.2.1 초기 논의와 IETF 워킹 그룹 결성

WebDAV의 개념적 시초는 1996년으로 거슬러 올라간다. 당시 짐 화이트헤드(Jim Whitehead)는 월드 와이드 웹 컨소시엄(W3C)과 협력하여 분산 저작 문제에 대한 기술적 논의를 위한 두 차례의 회의를 주최했다.1 이 논의는 웹 기술의 표준화를 주도하는 IETF(Internet Engineering Task Force)의 주목을 받았고, 곧이어 ’webdav’라는 공식 워킹 그룹이 결성되는 계기가 되었다.2 이 워킹 그룹의 목표는 HTTP를 확장하여 원격 파일 관리 및 협업 저작을 위한 견고하고 상호운용 가능한 프레임워크를 정의하는 것이었다.

1.2.2 버전 관리(Versioning) 기능의 전략적 분리

프로토콜의 이름 ’Web Distributed Authoring and Versioning’에서 알 수 있듯이, 초기 워킹 그룹은 분산 저작 기능과 버전 관리 기능을 하나의 프로토콜에 통합하여 다루고자 했다. 그러나 개발이 진행됨에 따라, 이 두 가지 기능을 동시에 완벽하게 구현하는 것이 프로토콜을 지나치게 복잡하게 만들고 표준화 일정을 지연시킬 것이라는 현실적인 문제에 직면했다.1

이 지점에서 워킹 그룹은 중요한 전략적 결정을 내린다. 즉, 우선순위를 조정하여 보다 시급하고 핵심적인 ‘분산 저작’ 기능에 개발 역량을 집중하고, 복잡한 ‘버전 관리’ 기능은 향후 별도의 확장 사양으로 분리하여 추진하기로 한 것이다.1 이 결정은 WebDAV 프로토콜의 생존과 광범위한 채택에 결정적인 역할을 했다. 만약 워킹 그룹이 두 기능을 모두 완벽하게 구현하려 했다면, 프로토콜은 너무 비대하고 복잡해져 시장에서 외면받았을 가능성이 높다. 핵심 기능에 집중한 실용주의적 접근 덕분에 WebDAV는 Apache, Microsoft IIS 등 주요 웹 서버에 빠르게 채택될 수 있는 기반을 마련했다. 이후 버전 관리 기능은 ’DeltaV’라는 이름의 RFC 3253으로 별도 표준화되었으나, 기본 WebDAV만큼 널리 성공하지는 못했다.7 이는 기술 표준화 과정에서 이상적인 목표와 현실적인 구현 가능성 사이의 균형이 얼마나 중요한지를 보여주는 사례다.

1.2.3 주요 RFC(Request for Comments) 연혁

WebDAV의 발전 과정은 여러 핵심 RFC 문서를 통해 공식화되었다.

• RFC 2291 (1998년 2월): “Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web“이라는 제목으로 발표된 이 문서는 WebDAV 프로토콜이 충족해야 할 기능적 요구사항들을 상세히 기술했다. 이는 이후 프로토콜 설계의 근간이 되는 청사진 역할을 했다.1

• RFC 2518 (1999년 2월): “HTTP Extensions for Distributed Authoring – WEBDAV“라는 제목으로 발표된 WebDAV의 첫 공식 표준이다. 이 문서는 HTTP/1.1을 확장하는 새로운 메서드(예: PROPFIND, LOCK), 헤더, 그리고 속성(Properties), 컬렉션(Collections), 잠금(Locking)과 같은 핵심 개념을 정의하며 프로토콜의 기틀을 마련했다.1

• RFC 4918 (2007년 6월): RFC 2518을 대체하는 현재의 표준 명세다. 약 8년간의 실제 구현 및 운영 경험을 바탕으로, 기존 명세의 모호한 부분을 명확히 하고 여러 구현체 간의 상호운용성 문제를 해결하기 위한 개정이 이루어졌다. 현재 대부분의 WebDAV 구현은 이 RFC 4918을 따르고 있다.1

2. 부: WebDAV 프로토콜 아키텍처 해부

WebDAV는 완전히 새로운 프로토콜을 창조하는 대신, 기존 웹 인프라와의 호환성을 극대화하기 위해 HTTP/1.1을 확장하는 방식을 채택했다. 이 아키텍처적 선택은 WebDAV가 프록시, 캐시, 방화벽, 그리고 SSL/TLS와 같은 기존 웹 기술들을 자연스럽게 활용할 수 있게 만들었다.9

2.1 HTTP의 확장: 새로운 메서드(Methods)와 헤더(Headers)

WebDAV는 파일 시스템과 유사한 작업을 수행하기 위해 HTTP/1.1에 정의되지 않은 새로운 메서드와 헤더를 도입했다.

2.1.1 주요 확장 메서드

WebDAV의 핵심 기능은 다음과 같은 새로운 HTTP 메서드를 통해 구현된다.

표 1: 주요 WebDAV 메서드 요약. 1

2.1.2 주요 확장 헤더

이러한 새로운 메서드들의 동작을 제어하기 위해 다음과 같은 HTTP 헤더들이 추가되었다.

• Depth: PROPFIND와 같은 요청이 적용될 깊이를 지정한다. 0은 대상 리소스 자체, 1은 대상과 그 직계 자식들, infinity는 대상과 모든 하위 리소스들을 의미한다.13

• Destination: COPY 또는 MOVE 작업의 대상이 될 URI를 절대 경로로 지정한다.13

• If: 특정 조건이 만족될 때만 요청을 실행하도록 하는 강력한 조건부 요청 헤더다. ETag 값이나 Lock-Token을 사용하여 리소스의 상태를 검증하는 데 사용된다.14

• Lock-Token: LOCK 요청에 성공했을 때 서버가 발급하는 고유한 잠금 식별자다. 잠긴 리소스를 수정하거나 UNLOCK할 때 이 토큰을 제시해야 한다.13

• Overwrite: COPY 또는 MOVE 작업 시, Destination에 이미 리소스가 존재할 경우 덮어쓸지 여부를 제어한다. T(True) 또는 F(False) 값을 가진다.13

• Timeout: LOCK 요청 시 클라이언트가 원하는 잠금의 유효 시간을 서버에 제안한다. 형식은 Second- 또는 Infinite이다.15

2.2 XML 기반의 통신 구조

WebDAV는 HTTP 헤더만으로는 표현하기 어려운 복잡하고 구조적인 데이터를 교환하기 위해 요청 및 응답 본문에 XML(Extensible Markup Language)을 적극적으로 사용한다. 이는 프로토콜 설계의 핵심적인 특징으로, 다음과 같은 중요한 이점을 제공한다.9

• 확장성(Extensibility): XML의 태그 기반 구조는 새로운 기능을 추가하기 용이하게 만든다. 표준에 정의되지 않은 새로운 XML 요소를 추가하여 프로토콜을 확장할 수 있으며, 이는 CalDAV, CardDAV와 같은 수많은 확장 프로토콜이 탄생하는 기반이 되었다.9

• 국제화(Internationalization): XML은 기본적으로 ISO 10646(유니코드) 문자 집합을 지원하므로, 다양한 언어로 된 속성 값(예: 파일 작성자 이름, 설명)을 문자 깨짐 문제 없이 안정적으로 처리할 수 있다.9

2.2.1 Multi-Status 응답

WebDAV의 아키텍처가 단순한 파일 전송을 넘어 원격 ’자원 관리’를 지향한다는 점을 가장 명확하게 보여주는 것이 바로 207 Multi-Status 응답 코드의 도입이다. FTP와 같은 전통적인 프로토콜이 단일 명령에 대해 단일 성공/실패 응답을 반환하는 것과 달리, WebDAV의 PROPFIND와 같은 메서드는 단일 요청으로 여러 리소스(예: 한 디렉터리 내의 모든 파일)에 대한 작업을 수행할 수 있다.

이 과정에서 일부 파일은 성공적으로 조회되지만 다른 파일은 권한 문제로 실패하는 ‘부분적 성공’ 상태가 발생할 수 있다. 이러한 복합적인 결과를 단일 응답으로 표현하기 위해 새로운 HTTP 상태 코드인 207 Multi-Status가 정의되었다.9 이 응답 코드는 전체 작업이 시작되었음을 알리고, 각 개별 리소스에 대한 상세한 상태는 XML 형식의 응답 본문을 통해 전달된다.

207 Multi-Status 응답 본문의 XML 구조는 다음과 같다.17

• <D:multistatus>: 응답 본문의 루트 요소로, 하나 이상의 <D:response> 요소를 포함한다. D는 DAV: XML 네임스페이스를 의미한다.

• <D:response>: 개별 리소스에 대한 응답 정보를 담는 컨테이너다.

• <D:href>: 이 응답이 적용되는 리소스의 URI를 명시한다.

• <D:propstat>: 특정 속성 그룹에 대한 상태 정보를 담는다. 하나의 <D:response> 안에 여러 개의 <D:propstat>이 존재할 수 있다 (예: 일부 속성은 성공적으로 조회되고, 일부는 실패한 경우).

• <D:prop>: 실제 속성(이름과 값)을 담는 컨테이너다.

• <D:status>: 해당 <D:propstat>에 포함된 속성들에 대한 HTTP 상태 라인(예: HTTP/1.1 200 OK 또는 HTTP/1.1 404 Not Found)을 포함한다.

이러한 구조는 클라이언트가 단일 요청에 대한 복합적인 결과를 효율적으로 파싱하고 처리할 수 있게 해준다. 만약 이 메커니즘이 없었다면, 클라이언트는 각 리소스의 상태를 확인하기 위해 수많은 개별 요청을 보내야 했을 것이다.

2.3 WebDAV의 3대 핵심 개념 심층 분석

WebDAV의 기능성은 속성(Properties), 컬렉션(Collections), 그리고 잠금(Locking)이라는 세 가지 핵심 추상화 개념 위에 구축된다.

2.3.1 속성(Properties): 리소스의 메타데이터 관리

WebDAV는 모든 리소스가 이름-값 쌍 형태의 메타데이터, 즉 ’속성’을 가질 수 있도록 정의한다. 속성의 이름은 고유한 URI로 식별되며, 값은 वेल-formed XML 조각으로 표현된다. 이는 단순한 파일 콘텐츠를 넘어 리소스에 대한 풍부한 부가 정보를 체계적으로 관리할 수 있게 해준다.1 WebDAV 속성은 크게 두 가지 유형으로 나뉜다.

• ‘Live’ 속성 (Live Properties): getcontentlength(파일 크기), getlastmodified(최종 수정일), resourcetype(리소스 유형) 등과 같이 서버가 직접 관리하고 파일 시스템의 상태와 동기화되는 핵심 속성이다. 이 속성들은 서버에 의해 자동으로 계산되고 유지되며, 클라이언트는 일반적으로 이 값을 직접 수정할 수 없다.19

• ‘Dead’ 속성 (Dead Properties): author(작성자), copyright(저작권 정보) 등과 같이 클라이언트가 임의로 생성, 수정, 삭제하는 사용자 정의 속성이다. 서버는 이 속성들의 의미를 해석하지 않고 단순히 저장하고 반환하는 역할만 수행한다. 이러한 유연성 덕분에 애플리케이션은 필요한 모든 종류의 메타데이터를 리소스에 연결할 수 있다.19

속성을 조작하기 위해 PROPFIND와 PROPPATCH 메서드가 사용된다.

• PROPFIND 요청 (특정 속성 조회):

<?xml version="1.0" encoding="utf-8"?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:getcontentlength/>
<D:getlastmodified/>
<Z:author xmlns:Z="http://www.example.com/ns"/>
</D:prop>
</D:propfind>

• PROPPATCH 요청 (속성 설정 및 제거):

PROPPATCH는 원자적(atomic) 연산을 보장한다. 즉, 요청 본문 내의 모든 속성 변경(set 또는 remove)이 성공하거나, 하나라도 실패하면 모든 변경이 롤백된다.20

<?xml version="1.0" encoding="utf-8"?>
<D:propertyupdate xmlns:D="DAV:" xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:Authors>
<Z:Author>Jim Whitehead</Z:Author>
</Z:Authors>
</D:prop>
</D:set>
<D:remove>
<D:prop>
<Z:Copyright-Owner/>
</D:prop>
</D:remove>
</D:propertyupdate>

2.3.2 컬렉션(Collections): 계층적 네임스페이스 관리

’컬렉션’은 전통적인 파일 시스템의 디렉터리와 유사한 개념으로, 다른 리소스(일반 파일 또는 다른 컬렉션)들을 멤버로 포함하는 컨테이너 역할을 한다.9 이를 통해 웹 서버 상에 계층적인 네임스페이스를 구성하고 관리할 수 있다.

• MKCOL 메서드를 사용하여 새로운 빈 컬렉션을 생성할 수 있다.1

• 컬렉션의 멤버 목록을 조회하기 위해서는 해당 컬렉션의 URI에 PROPFIND 요청을 보내면서 Depth: 1 헤더를 사용한다. 서버는 응답으로 컬렉션 자체의 속성과 함께, 그 직계 자식 멤버들의 속성 정보를 207 Multi-Status 응답에 담아 반환한다.13

2.3.3 잠금(Locking): ‘소실된 업데이트 문제(Lost Update Problem)’ 해결

WebDAV의 가장 중요한 협업 지원 기능은 ‘잠금’ 메커니즘이다. 이는 여러 사용자가 동시에 같은 파일을 수정하고 저장할 때, 나중에 저장한 변경 사항이 먼저 저장한 내용을 덮어써서 데이터가 유실되는 ’소실된 업데이트 문제(lost update problem)’를 방지하기 위해 설계되었다.9

LOCK 메서드를 통해 리소스에 잠금을 설정하면, 잠금을 획득한 사용자만이 해당 리소스를 수정할 수 있는 권한을 독점하게 된다.

WebDAV는 두 가지 종류의 잠금을 지원한다.

• 배타적 잠금 (Exclusive Lock): 가장 일반적이고 강력한 잠금 방식이다. 오직 한 명의 사용자(주체)만이 리소스에 대한 배타적 잠금을 획득할 수 있다. 이 잠금이 활성화된 동안 다른 어떤 사용자도 해당 리소스에 대해 배타적 잠금이나 공유 잠금을 획득할 수 없다.22

• 공유 잠금 (Shared Lock): 여러 사용자가 동시에 리소스에 대한 공유 잠금을 획득할 수 있다. 이는 엄격한 수정 제어보다는, 여러 명의 저자가 해당 파일을 작업 중임을 서로에게 알리고, 외부 통신(예: 이메일, 메신저)을 통해 작업을 조율할 것을 전제로 한다. 공유 잠금이 하나라도 걸려 있는 리소스에 대해서는 배타적 잠금을 획득할 수 없다.22

LOCK 요청 시, 클라이언트는 요청 본문에 <lockinfo> XML 요소를 포함하여 원하는 잠금의 유형(scope), 종류(type), 소유자(owner) 정보를 명시한다.

• LOCK 요청 본문 (<lockinfo>) 예시:

<?xml version="1.0" encoding="utf-8"?>
<D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>mailto:jane.doe@example.com</D:href>
</D:owner>
</D:lockinfo>

이러한 잠금 요청의 성공 여부는 리소스의 현재 잠금 상태에 따라 결정된다. 그 규칙은 다음의 호환성 표로 요약할 수 있다.

표 2: WebDAV 잠금 호환성 매트릭스. 22

• 동일한 주체(principal)가 동일한 잠금을 두 번 요청하는 것은 허용되지 않는다.

이처럼 1990년대 후반의 설계 철학은 확장성과 구조화된 데이터 표현을 위해 XML을 채택하는 결정을 내렸다. 이 선택은 CalDAV, CardDAV와 같은 풍부한 확장 생태계를 가능하게 한 원동력이었지만, 동시에 현대적인 바이너리 기반 프로토콜과 비교했을 때 발생하는 성능 저하의 근본적인 원인이 되기도 했다. 이는 기술 설계에 있어 유연성과 성능 사이의 영원한 트레이드오프(trade-off)를 보여주는 대표적인 사례다.

3. 부: 주요 구현체 및 실제 적용

WebDAV 프로토콜은 표준 명세로서, 실제 그 기능을 활용하기 위해서는 서버와 클라이언트 양측에 구현체가 필요하다. 지난 수십 년간 다양한 소프트웨어에서 WebDAV를 지원하며 견고한 생태계를 구축해왔다.

3.1 서버 측 구현: Apache와 Nginx

WebDAV 서버 기능은 주로 기존 웹 서버에 모듈 형태로 추가되어 구현된다.

3.1.1 Apache HTTP Server (mod_dav)

Apache HTTP Server는 mod_dav 모듈을 통해 WebDAV 기능을 제공하며, 이는 사실상의 표준(de facto standard) 구현체로 널리 인정받고 있다.7

mod_dav는 오랜 기간 안정적으로 개발 및 유지보수되어 왔으며, WebDAV Class 1과 Class 2의 모든 기능을 충실하게 지원한다.

• 기본 설정: Apache 설정 파일(httpd.conf)에서 LoadModule 지시어를 사용하여 dav_module과 파일 시스템 연동을 위한 dav_fs_module을 로드한다. 그 후, WebDAV를 활성화하고자 하는 <Location> 또는 <Directory> 설정 블록 내에 Dav On 지시어를 추가하는 것만으로 간단히 활성화할 수 있다.23

• 잠금 데이터베이스 설정: WebDAV의 잠금 기능을 정상적으로 사용하기 위해서는 DavLockDB 지시어를 사용하여 잠금 정보를 기록할 파일의 경로를 반드시 지정해야 한다. 이 파일이 위치한 디렉터리는 Apache 프로세스를 실행하는 사용자(예: www-data)가 쓰기 권한을 가져야 한다.23

• 인증 구성: 원격에서 파일 시스템을 조작할 수 있는 강력한 권한을 부여하므로, WebDAV가 활성화된 경로는 반드시 인증 절차로 보호해야 한다. 보안상 평문 비밀번호를 전송하는 Basic 인증보다는, mod_auth_digest 모듈을 이용한 Digest 인증이 강력히 권장된다. 만약 Basic 인증을 사용해야 한다면, 반드시 SSL/TLS(HTTPS) 연결을 통해 통신 채널을 암호화해야 한다.23

다음은 Apache의 기본 WebDAV 설정 예시다.

# httpd.conf 전역 설정
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
DavLockDB /var/www/DavLock

# 가상 호스트 또는 Directory 설정
<Directory /var/www/webdav>
Dav On
AuthType Digest
AuthName "WebDAV-Realm"
AuthUserFile /etc/apache2/webdav.passwd
Require valid-user
</Directory>

3.1.2 Nginx (ngx_http_dav_module)

Nginx 또한 ngx_http_dav_module이라는 공식 모듈을 통해 WebDAV를 지원한다. 하지만 이 기본 모듈은 PUT, DELETE, MKCOL, COPY, MOVE와 같은 기본적인 파일 관리 메서드만 지원하며, 클라이언트가 디렉터리 목록을 보거나 파일 속성을 조회하는 데 필수적인 PROPFIND 메서드를 지원하지 않는다는 치명적인 한계가 있다.27

따라서 Nginx로 완전한 기능의 WebDAV 서버를 구축하기 위해서는 nginx-dav-ext-module과 같은 서드파티 확장 모듈을 함께 설치하고 설정해야 한다. 이 확장 모듈은 PROPFIND, OPTIONS 및 LOCK/UNLOCK과 같은 핵심 메서드를 추가로 지원하여 WebDAV 프로토콜의 완전한 기능을 제공한다.28

다음은 확장 모듈을 포함한 Nginx의 설정 예시다.

# nginx.conf의 http 블록
dav_ext_lock_zone zone=dav_locks:10m;

# server 블록
location /webdav {
root /var/www;
client_body_temp_path /var/www/temp;

dav_methods PUT DELETE MKCOL COPY MOVE;
dav_ext_methods PROPFIND OPTIONS LOCK UNLOCK;
dav_ext_lock zone=dav_locks;

create_full_put_path on;
dav_access user:rw group:r all:r;

auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/webdav.htpasswd;
}

3.2 클라이언트 측 구현

WebDAV의 진정한 가치는 클라이언트 측에서 원격 저장소를 마치 로컬 파일 시스템의 일부처럼 다룰 수 있게 해주는 강력한 ’추상화’에 있다. 사용자는 복잡한 HTTP 메서드나 XML 구조를 전혀 인지할 필요 없이, 익숙한 파일 탐색기 인터페이스를 통해 원격 파일과 상호작용할 수 있다.

• 운영체제 내장 클라이언트: 대부분의 현대 운영체제는 WebDAV를 파일 시스템 수준에서 통합 지원한다.4

• Windows: 파일 탐색기의 ‘네트워크 드라이브 연결’ 기능을 사용하여 WebDAV 공유 폴더를 Z:와 같은 특정 드라이브 문자로 매핑할 수 있다. 매핑된 후에는 로컬 드라이브와 거의 동일하게 파일을 열고, 저장하고, 복사하고, 이동할 수 있다.3

• macOS: Finder의 ‘서버에 연결’(단축키: Cmd+K) 기능을 통해 WebDAV 서버 주소를 입력하면, 서버의 공유 폴더가 데스크톱에 하나의 볼륨처럼 마운트된다.3

• Linux: GNOME 환경의 Nautilus나 KDE 환경의 Dolphin과 같은 파일 관리자들은 주소창에 davs://user@example.com/path와 같은 형식으로 주소를 입력하여 서버에 직접 연결할 수 있다. 또한, davfs2 파일 시스템 드라이버를 설치하면 mount 명령어를 통해 WebDAV 공유를 시스템의 특정 디렉터리에 마운트하여 모든 애플리케이션에서 로컬 디렉터리처럼 접근할 수 있다.30

• 주요 서드파티 애플리케이션:

• 파일 전송 클라이언트: Cyberduck, WinSCP, Transmit과 같은 전문 파일 전송 클라이언트들은 FTP, SFTP와 더불어 WebDAV를 기본 프로토콜로 지원하여 그래픽 인터페이스를 통한 편리한 파일 관리를 제공한다.31

• 저작 도구: Microsoft Office(Word, Excel, PowerPoint), Adobe Creative Suite(Photoshop, Dreamweaver) 등 다수의 콘텐츠 저작 도구들은 WebDAV를 직접 지원한다. 이를 통해 사용자는 파일을 로컬에 다운로드했다가 다시 업로드하는 번거로운 과정 없이, 서버에 있는 파일을 직접 열어 수정하고 바로 저장할 수 있다.7

이처럼 WebDAV는 성능상의 일부 단점에도 불구하고, ‘원격 파일을 로컬 파일처럼’ 다룰 수 있게 해주는 강력하고 직관적인 사용자 경험을 제공함으로써 기술에 익숙하지 않은 일반 사용자들에게까지 그 가치를 확장했다. 이 점이 S3 API와 같은 개발자 중심의 프로토콜과 WebDAV를 근본적으로 구분 짓는 요소이며, 수십 년간 기술 생태계에서 살아남을 수 있었던 핵심 비결 중 하나다.

3.3 주요 활용 사례: 클라우드 스토리지와 협업 시스템

WebDAV의 이러한 특성은 특히 파일 동기화 및 온라인 협업 분야에서 널리 활용되었다.

• Nextcloud 및 ownCloud: Nextcloud와 그 전신인 ownCloud는 개인 및 기업용 파일 동기화 및 공유(EFSS)를 위한 대표적인 오픈소스 플랫폼이다. 이들 시스템의 핵심 아키텍처에서 WebDAV는 매우 중요한 역할을 한다. 데스크톱 및 모바일 동기화 클라이언트는 물론, 다양한 서드파티 애플리케이션과의 호환성을 보장하는 표준 접근 프로토콜로서 WebDAV를 제공한다.2 이를 통해 사용자들은 공식 클라이언트가 없는 환경에서도 운영체제의 내장 기능이나 범용 WebDAV 클라이언트를 사용하여 자신의 파일에 접근할 수 있다.

• 기업 내 문서 중앙화 및 협업: 많은 기업이 내부 파일 서버에 WebDAV 인터페이스를 추가하여, 직원들이 외부에서도 안전하게(HTTPS를 통해) 문서에 접근하고 편집할 수 있는 환경을 구축한다. 특히 WebDAV의 파일 잠금 기능은 여러 명의 팀원이 동시에 같은 문서를 편집할 때 발생할 수 있는 데이터 충돌을 원천적으로 방지하여 문서의 무결성을 보장한다.3 Microsoft SharePoint와 같은 문서 관리 시스템(DMS) 역시 WebDAV를 지원하여, 사용자가 웹 브라우저뿐만 아니라 파일 탐색기나 Microsoft Office 애플리케이션에서 직접 문서를 다룰 수 있도록 한다.34

4. 부: 성능, 보안, 그리고 프로토콜 생태계

WebDAV는 강력한 기능과 유연성을 제공하지만, 그 아키텍처적 특성으로 인해 성능과 보안 측면에서 고려해야 할 중요한 사항들이 존재한다.

4.1 성능 특성 및 한계점 분석

WebDAV의 성능은 기반 프로토콜인 HTTP의 특성과 XML 사용에 직접적인 영향을 받는다.

• HTTP 오버헤드와 XML 파싱 비용: WebDAV는 바이너리 기반의 프로토콜(예: FTP의 데이터 채널, SMB)과 달리 텍스트 기반의 HTTP 위에서 동작한다. 모든 요청과 응답에는 상당한 크기의 HTTP 헤더가 포함되며, PROPFIND나 PROPPATCH와 같은 작업의 본문은 장황한(verbose) XML로 구성된다. 이로 인해 순수한 데이터 전송 외의 프로토콜 오버헤드가 크다. 특히 수많은 작은 파일을 나열하거나 전송할 때, 각 파일에 대한 요청/응답 및 XML 파싱에 소요되는 비용이 누적되어 심각한 성능 저하를 유발할 수 있다.14

• 대용량 파일 전송 문제: 프로토콜 자체에는 파일 크기 제한이 없지만, 실제 환경에서는 대용량 파일 전송이 실패하는 경우가 빈번하다. 이는 WebDAV 서버, 클라이언트, 그리고 그 사이에 위치한 프록시나 방화벽의 설정(예: client_max_body_size, proxy_read_timeout, 메모리 제한)에 기인하는 경우가 대부분이다.36

• Windows 클라이언트의 파일 크기 제한 (오류 0x800700DF): Windows 운영체제에 내장된 WebDAV 클라이언트(WebClient 서비스)는 시스템 보호 및 성능 저하 방지를 위해 기본적으로 업로드 가능한 파일 크기를 50,000,000바이트(약 47.6MB)로 제한한다. 이보다 큰 파일을 업로드하려고 시도하면 “파일 크기가 허용된 한도를 초과하여 파일을 저장할 수 없습니다“라는 메시지와 함께 오류 코드 0x800700DF가 발생한다.38

• 레지스트리를 통한 해결: 이 제한은 Windows 레지스트리 편집을 통해 완화할 수 있다. 레지스트리 편집기(regedit)를 실행하여 다음 경로로 이동한다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

해당 경로에서 FileSizeLimitInBytes라는 이름의 DWORD 값을 찾거나 새로 생성한다. 이 값의 데이터(10진수 기준)를 기본값 50000000에서 원하는 크기(바이트 단위)로 수정한다. 설정 가능한 최댓값은 32비트 정수의 최댓값인 4294967295(약 4GB)이다. 레지스트리 수정 후에는 변경 사항을 적용하기 위해 반드시 WebClient 서비스를 재시작하거나 시스템을 재부팅해야 한다.38

4.2 보안 메커니즘

WebDAV의 보안 모델은 프로토콜 자체가 모든 것을 책임지기보다, 검증된 다른 계층의 기술에 역할을 ’위임’하는 방식에 기반한다. 이는 모듈성과 유연성을 높이는 장점이 있지만, 동시에 관리자가 각 계층의 보안을 올바르게 구성해야 하는 책임을 부여한다.

• 인증(Authentication): WebDAV는 HTTP/1.1에 정의된 인증 메커니즘을 그대로 사용한다.41

• Basic Authentication: 사용자 이름과 비밀번호를 콜론으로 연결한 후 Base64로 인코딩하여 Authorization 헤더에 담아 전송한다. Base64는 암호화가 아니므로 누구나 쉽게 디코딩할 수 있다. 따라서 데이터 탈취를 방지하기 위해서는 반드시 HTTPS를 통해 전송 채널 자체를 암호화해야 한다.42

• Digest Authentication: 서버가 nonce(임의의 문자열) 값을 클라이언트에 보내면, 클라이언트는 사용자 이름, 비밀번호, nonce, HTTP 메서드, 요청 URI 등을 조합하여 MD5 해시 값을 생성해 응답하는 Challenge-Response 방식이다. 비밀번호가 평문으로 네트워크를 통해 전송되지 않으므로 Basic 인증보다 안전하다. 하지만 여전히 중간자 공격(Man-in-the-Middle attack)에는 취약할 수 있으므로, 가능한 한 HTTPS와 함께 사용하는 것이 권장된다.41

• 암호화(Encryption): WebDAV 프로토콜 자체에는 데이터 암호화 기능이 내장되어 있지 않다. 통신 중 데이터의 기밀성과 무결성을 보장하기 위해서는 전송 계층 보안(TLS) 위에서 HTTP를 실행하는 HTTPS를 사용하는 것이 필수적이다. HTTPS를 사용하면 모든 HTTP 요청과 응답(헤더와 본문 포함)이 암호화되어 전송된다.3

• 접근 제어(Access Control) - WebDAV ACL (RFC 3744): WebDAV의 기본 권한 모델은 단순한 읽기/쓰기 수준에 머무른다. 이를 보완하기 위해 RFC 3744는 리소스별로 매우 세분화된 접근 제어 목록(Access Control List, ACL)을 설정할 수 있는 확장 표준을 정의한다.1

• ACL은 하나 이상의 접근 제어 항목(Access Control Entry, ACE)으로 구성된다.

• 각 ACE는 특정 ‘주체(Principal)’(예: 특정 사용자, 그룹)에게 특정 ‘권한(Privilege)’(예: 읽기, 쓰기, ACL 읽기/쓰기)을 허용(grant)하거나 거부(deny)하는 규칙을 명시한다.45

• 주요 표준 권한으로는 DAV:read, DAV:write, DAV:read-acl, DAV:write-acl 등이 있으며, 이 권한들은 DAV:all이라는 최상위 권한 아래 계층적으로 집계(aggregate)된다. 예를 들어, DAV:write 권한을 부여받으면 하위 권한인 DAV:write-content(파일 내용 쓰기)와 DAV:bind(파일 생성) 권한도 함께 부여된다.45

4.3 WebDAV 확장 프로토콜 생태계

WebDAV의 설계상 가장 큰 성공 중 하나는 그 자체가 하나의 플랫폼이 되어 다양한 응용 프로토콜을 파생시켰다는 점이다. XML 기반의 확장 가능한 구조는 특정 도메인의 문제를 해결하기 위한 새로운 표준의 기반이 되었다.

• CalDAV (RFC 4791): 달력 데이터 동기화를 위한 프로토콜이다. CalDAV는 달력 정보를 표준 iCalendar 형식으로 표현하고, 각 ’달력’을 WebDAV 컬렉션으로, ’일정(event)’이나 ’할 일(to-do)’을 WebDAV 리소스로 모델링한다. 사용자는 CalDAV를 지원하는 클라이언트(예: macOS 캘린더, Thunderbird)를 통해 여러 기기에서 자신의 일정을 동기화하고 관리할 수 있다.1

• CardDAV (RFC 6352): 주소록 데이터 동기화를 위한 프로토콜이다. CalDAV와 유사한 방식으로, 주소록 정보를 표준 vCard 형식으로 표현하고, ’주소록’을 WebDAV 컬렉션으로, 개별 ’연락처’를 리소스로 취급한다. 이를 통해 사용자는 자신의 연락처 정보를 중앙 서버에 저장하고 여러 기기에서 일관되게 유지할 수 있다.14

• 기타 확장 사양: 이 외에도 서버 측 검색을 위한 SEARCH 메서드(RFC 5323), 컬렉션의 저장 공간 할당량을 관리하기 위한 quota 속성(RFC 4331), 리소스 리디렉션을 위한 참조 리소스(RFC 4437), 컬렉션 내 멤버의 순서를 지정하기 위한 정렬된 컬렉션(RFC 3648) 등 다양한 기능이 별도의 RFC를 통해 표준화되어 WebDAV의 기능을 풍부하게 만들었다.1

5. 부: WebDAV와 타 프로토콜 비교 분석

WebDAV의 기술적 특성과 가치를 명확히 이해하기 위해서는, 유사한 목적을 가진 다른 프로토콜들과의 비교 분석이 필수적이다.

5.1 전통적 파일 전송 프로토콜과의 비교: FTP, SMB

5.1.1 WebDAV vs. FTP (File Transfer Protocol)

WebDAV는 종종 ’HTTP를 이용한 FTP’로 비유되지만, 두 프로토콜은 설계 철학과 기능 면에서 근본적인 차이를 보인다.

• 네트워크 및 방화벽: WebDAV의 가장 큰 장점 중 하나는 방화벽 친화성이다. WebDAV는 표준 웹 포트인 80(HTTP) 또는 443(HTTPS) 하나만을 사용하여 모든 통신을 처리한다. 반면, FTP는 명령을 위한 제어 채널(포트 21)과 실제 데이터 전송을 위한 데이터 채널(가변적인 포트)을 분리하여 사용한다. 이 구조는 NAT 환경이나 방화벽을 통과할 때 복잡한 설정을 요구하며, 종종 연결 문제를 일으키는 주된 원인이 된다.2

• 보안: 암호화되지 않은 순수 FTP는 사용자 인증 정보와 전송 데이터를 모두 평문으로 노출시켜 보안에 매우 취약하다. 이를 보완하기 위해 FTPS(FTP over SSL/TLS)나 SFTP(SSH File Transfer Protocol)가 사용된다. 반면, WebDAV는 웹 표준인 HTTPS를 통해 손쉽게 강력한 종단 간 암호화를 적용할 수 있다.34

• 협업 기능: FTP는 이름 그대로 파일 ’전송’에만 초점을 맞춘 프로토콜이다. 여러 사용자가 동시에 작업할 때 발생하는 충돌을 방지하기 위한 파일 잠금(locking)이나, 파일의 작성자, 버전 정보 등을 관리하기 위한 속성(properties) 관리 기능이 전무하다. WebDAV는 이러한 협업 기능을 프로토콜 수준에서 내장하고 있어, 분산 저작 환경에 훨씬 더 적합하다.2

• 성능: 단순 대용량 파일의 단일 전송에서는 프로토콜 오버헤드가 상대적으로 적은 FTP가 더 나은 성능을 보일 수 있다. 그러나 수많은 작은 파일을 전송하는 시나리오에서는 매번 새로운 데이터 채널 연결을 설정해야 하는 FTP보다, 지속적인 단일 TCP 연결(Persistent Connection)을 활용하는 WebDAV가 더 효율적일 수 있다.35

5.1.2 WebDAV vs. SMB (Server Message Block)

SMB(최근 버전은 CIFS로도 불림)는 주로 Windows 환경의 로컬 네트워크(LAN)에서 파일 및 프린터 공유를 위해 사용되는 프로토콜이다.

• 주 사용 환경: SMB는 낮은 지연 시간(low latency)을 가진 LAN 환경에 최적화되어 설계되었다. 반면, WebDAV는 HTTP를 기반으로 하므로 높은 지연 시간을 가진 인터넷(WAN) 환경에서의 원격 접근에 더 적합하다. SMB는 프로토콜의 ‘수다스러운(chatty)’ 특성 때문에 WAN을 통해 사용할 경우 성능이 급격히 저하되는 경향이 있다.52

• 플랫폼 호환성: SMB는 Windows 환경에서는 기본적으로 지원되지만, macOS나 Linux에서 사용하려면 Samba와 같은 별도의 소프트웨어 설치가 필요하다. WebDAV는 HTTP 클라이언트를 가진 거의 모든 플랫폼에서 접근이 가능하여 플랫폼 간 상호운용성이 더 높다.

5.2 현대적 클라우드 스토리지와의 비교: Object Storage (S3 API)

현대 클라우드 컴퓨팅의 데이터 저장 표준으로 자리 잡은 S3(Simple Storage Service) API와 WebDAV를 비교하는 것은 ‘파일 시스템’ 패러다임과 ‘객체 저장소’ 패러다임의 근본적인 차이를 이해하는 것과 같다. 이 둘의 대립은 ’인간을 위한 인터페이스’와 ‘기계를 위한 인터페이스’ 간의 철학적 차이를 명확히 보여준다.

• 데이터 모델의 차이:

• WebDAV: 사용자에게 익숙한 계층적 디렉터리 구조(폴더와 파일)를 가진 파일 시스템 추상화를 제공한다. 리소스는 /documents/report.docx와 같은 경로(path)를 통해 식별되며, MOVE나 COPY와 같은 파일 시스템 연산이 중심이다.21 이는 인간의 인지 모델에 부합하여 직관적인 파일 관리를 가능하게 한다.

• S3 API: 모든 데이터를 ’객체(Object)’라는 독립적인 단위로 취급하며, 이들은 전역적으로 고유한 키(key)를 통해 식별되는 평면적인(flat) 객체 저장소 모델을 따른다. my-bucket/documents/report.docx와 같은 키 이름이 디렉터리 구조처럼 보일 수 있지만, 이는 단지 이름의 일부일 뿐 실제 계층 구조는 존재하지 않는다. documents/는 폴더가 아니라 키 이름의 접두사(prefix)일 뿐이다.54 이 모델은 기계적인 처리에 최적화되어 있다.

• 데이터 조작 방식:

• WebDAV: 파일을 직접 열어 특정 부분만 수정하고 저장하는 부분적 수정(partial modification)을 지원한다. 이는 인간의 문서 편집 워크플로우와 일치한다.35

• S3 API: 객체는 일반적으로 불변(immutable)한 단위로 취급된다. 객체의 일부를 수정하려면, 전체 객체를 다운로드하여 수정한 후 새로운 버전으로 다시 업로드해야 한다. 이는 데이터의 일관성과 버전 관리를 단순화하여 대규모 분산 시스템에 적합하게 만든다.55

• 메타데이터 처리:

• WebDAV: ‘Live’ 및 ‘Dead’ 속성을 통해 구조화된 메타데이터를 지원하지만, 그 종류와 유연성에 한계가 있다.19

• S3 API: 각 객체에 대해 자유로운 형식의 키-값 쌍으로 구성된 사용자 정의 메타데이터(태그)를 거의 무제한으로 첨부할 수 있다. 이는 수십억 개의 객체 속에서도 원하는 데이터를 효율적으로 검색, 분류, 관리하고 접근 제어 정책을 적용하는 데 결정적인 역할을 한다.54

• 확장성과 주 사용 사례:

• WebDAV: 아키텍처가 단일 서버의 파일 시스템과 유사하게 동작하므로, 수평적 확장성(horizontal scalability)에 본질적인 한계가 있다. 주된 사용 사례는 소수의 인간 사용자가 직접 파일을 편집하고 관리하는 협업 워크플로우다.26

• S3 API: 처음부터 대규모 분산 시스템을 염두에 두고 설계되어 페타바이트(PB)급 데이터와 수십억 개의 객체를 처리할 수 있는 거의 무한한 확장성을 제공한다. 주된 사용 사례는 웹 애플리케이션의 정적 자산 저장, 빅데이터 분석, 백업 및 아카이빙, AI/ML 학습 데이터셋 저장 등 기계 중심의 대규모 워크로드다.56

결론적으로 “WebDAV와 S3 중 어느 것이 더 나은가?“라는 질문은 적절하지 않다. 두 기술은 서로 다른 문제를 해결하기 위해 탄생했으며, 직접적인 경쟁 관계라기보다는 상호 보완적인 관계에 가깝다. WebDAV가 인간 사용자를 위한 직관적인 파일 협업 인터페이스를 제공한다면, S3는 애플리케이션을 위한 확장성 높은 데이터 저장 백엔드를 제공한다.

표 3: 프로토콜 비교 분석표

6. 부: 결론: WebDAV의 현재적 가치와 미래 전망

WebDAV는 탄생한 지 20년이 훌쩍 넘은 프로토콜로서, 현대 클라우드 컴퓨팅 환경에서 그 위상과 역할에 대한 재평가가 이루어지고 있다. 과거 원격 파일 관리의 최전선에 있던 기술은 이제 새로운 패러다임에 자리를 내주었지만, 그 가치가 완전히 소멸한 것은 아니다.

6.1 클라우드 시대의 WebDAV의 역할

Dropbox, Google Drive, OneDrive와 같은 현대적인 상용 클라우드 스토리지 서비스들은 대부분 독자적인 고성능 API를 기반으로 동작하며, WebDAV를 주력 인터페이스로 사용하는 경우는 드물다.53 특히, Microsoft가 차기 Windows 버전에서 내장 WebDAV 클라이언트(WebClient 서비스)를 더 이상 기본으로 활성화하지 않고 점진적으로 지원을 중단(deprecate)할 것이라고 발표한 것은, WebDAV가 주류 PC 환경에서의 입지가 약화되고 있음을 보여주는 상징적인 사건이다.53

그럼에도 불구하고 WebDAV는 특정 벤더에 종속되지 않는 IETF 개방형 표준이라는 강력하고 대체 불가능한 가치를 지닌다. 이러한 특성은 다음과 같은 영역에서 WebDAV가 여전히 중요한 역할을 수행하게 만든다.

• 데이터 주권과 자체 호스팅(Self-Hosting): Nextcloud나 ownCloud와 같은 오픈소스 플랫폼 사용자들에게 WebDAV는 데이터의 통제권을 사용자 자신에게 유지하면서도, 다양한 기기와 애플리케이션에서 파일에 접근할 수 있는 보편적인 다리 역할을 한다. 이는 특정 기업의 생태계에 종속되기를 원치 않는 사용자들에게 매우 중요한 가치다.60

• 상호운용성과 레거시 시스템 연동: 수많은 기존 엔터프라이즈 애플리케이션과 시스템이 WebDAV를 지원하도록 이미 구축되어 있다. WebDAV는 이러한 레거시 시스템과 최신 시스템을 연결하거나, 서로 다른 벤더의 솔루션 간에 데이터를 교환해야 할 때 신뢰할 수 있는 ‘공용어’ 역할을 수행한다.61

6.2 미래 전망: 틈새 시장과 기반 기술로서의 잠재력

WebDAV의 미래는 과거처럼 전면에 나서기보다는, 특정 틈새 시장을 공략하거나 다른 기술을 지탱하는 보이지 않는 기반 기술로서 그 생명력을 이어갈 것으로 전망된다. 이는 기술 생태계에서 ’상위 포식자’의 역할에서 안정적인 ’기반 생물’로 역할이 변화하는 자연스러운 과정으로 볼 수 있다.

과거 원격 파일 관리의 표준이었던 WebDAV는 S3 API와 같은 더 효율적이고 확장성 높은 기술에 주도권을 내주었다. 하지만 이것이 기술의 ’사멸’을 의미하는 것은 아니다. 오히려 다른 기술 스택의 ’하부 구조’로 흡수되어 그 역할을 재정의하고 있다.

• IoT 및 임베디드 시스템: 경량 웹 서버를 내장한 수많은 IoT 장치나 네트워크 장비에서 펌웨어를 업데이트하거나, 로그 파일을 수집하고, 설정을 원격으로 관리하는 데 WebDAV는 매우 효과적인 솔루션이 될 수 있다. HTTP 기반이므로 방화벽 통과가 용이하고, 구현이 비교적 간단하며, 기존 웹 기술을 재사용할 수 있다는 장점은 리소스가 제한된 임베디드 환경에 적합하다.62

• 기반 기술(Foundational Technology)로서의 지속성: WebDAV 자체의 직접적인 사용은 감소하더라도, CalDAV와 CardDAV는 여전히 개인 정보 관리(PIM) 데이터 동기화의 핵심 표준으로 전 세계 수많은 기기에서 사용되고 있다.1 이는 WebDAV가 최종 사용자에게 직접 노출되지 않더라도, 우리가 일상적으로 사용하는 서비스들을 지탱하는 보이지 않는 기반 인프라로서 계속해서 그 가치를 유지할 것임을 시사한다.

결론적으로, WebDAV는 클라우드 시대의 주역 자리에서는 물러났지만, 개방형 표준으로서의 가치, 파일 시스템 추상화의 편리함, 그리고 다른 프로토콜의 기반이 되는 확장성을 바탕으로 기술 생태계의 중요한 구성원으로서 앞으로도 오랫동안 그 역할을 수행할 것이다.

7. 참고 자료

1. WebDAV - Wikipedia, https://en.wikipedia.org/wiki/WebDAV
2. WebDAV protocol - definition, explanation and applications - Easy Software, https://easy-software.com/en/glossary/webdav-protocol/
3. What is WebDAV? | JSCAPE, https://www.jscape.com/blog/what-is-webdav
4. WebDAV: This is how the HTTP extension works - IONOS, https://www.ionos.com/digitalguide/server/know-how/webdav/
5. WWW Distributed Authoring and Versioning (webdav) - IETF Datatracker, https://datatracker.ietf.org/wg/webdav/history/
6. WebDAV Requirements Document Version History - UC Irvine, https://ics.uci.edu/~ejw/authoring/requirements/index.html
7. What Is WebDAV? - Version Control with Subversion, https://svnbook.red-bean.com/en/1.6/svn.webdav.basic.html
8. WebDAV Specifications, http://www.webdav.org/specs/
9. RFC 2518 - HTTP Extensions for Distributed Authoring – WEBDAV, https://greenbytes.de/tech/webdav/rfc2518.html
10. Information on RFC 4918 - » RFC Editor, https://www.rfc-editor.org/info/rfc4918
11. HTTP Extensions for Distributed Authoring – WEBDAV, http://www.webdav.org/specs/rfc2518.html
12. WebDAV for HTTP Server - IBM, https://www.ibm.com/docs/en/i/7.5.0?topic=concepts-webdav
13. Web Publishing with WebDAV - Oracle Help Center, https://docs.oracle.com/cd/E19857-01/819-0130/agdav.html
14. WebDAV Explained: Filesystems Over HTTP | Tek’s Domain, https://teknikaldomain.me/post/webdav-explained-filesystems-over-http/
15. HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) - Web Concepts, https://webconcepts.info/specs/IETF/RFC/4918.html
16. RFC 4918: 4 of 5, p. 77 to 102 - Tech-invite, https://www.tech-invite.com/y45/tinv-ietf-rfc-4918-4.html
17. 207 Multi-Status - HTTP - MDN - Mozilla, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/207
18. 207 Multi-Status - MDN - Mozilla, https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/207
19. WebDAV Properties <, https://learn.microsoft.com/en-us/iis/configuration/system.webserver/webdav/authoring/properties/
20. RFC 4918: 3 of 5, p. 44 to 77 - Tech-invite, https://www.tech-invite.com/y45/tinv-ietf-rfc-4918-3.html
21. WebDAV 101 - SysTutorials, https://www.systutorials.com/webdav-101/
22. Web Distributed Authoring and Versioning (WebDAV) Locking Protocol - greenbytes GmbH, https://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html
23. mod_dav - Apache HTTP Server Version 2.4, https://httpd.apache.org/docs/current/mod/mod_dav.html
24. How To Configure WebDAV Access with Apache on Ubuntu 18.04 - DigitalOcean, https://www.digitalocean.com/community/tutorials/how-to-configure-webdav-access-with-apache-on-ubuntu-18-04
25. mod_dav_fs - Apache HTTP Server Version 2.4, https://httpd.apache.org/docs/current/mod/mod_dav_fs.html
26. Use Linux and WebDAV to Facilitate Online Collaboration - ServerWatch, https://www.serverwatch.com/servers/use-linux-and-webdav-to-facilitate-online-collaboration/
27. Module ngx_http_dav_module - nginx, http://nginx.org/en/docs/http/ngx_http_dav_module.html
28. nginx - DAVx5, https://www.davx5.com/tested-with/nginx
29. arut/nginx-dav-ext-module: nginx WebDAV PROPFIND,OPTIONS,LOCK,UNLOCK support, https://github.com/arut/nginx-dav-ext-module
30. Accessing Nextcloud files using WebDAV, https://docs.nextcloud.com/server/latest/user_manual/en/files/access_webdav.html
31. WebDAV Server - Distributed Authoring and Versioning - infoRouter, https://www.inforouter.com/webdav
32. Accessing ownCloud Files Using WebDAV, https://doc.owncloud.com/server/next/classic_ui/files/access_webdav.html
33. Co-authoring Office Documents on a Mapped WebDAV Drive - TurboFTP, https://turboftp.com/co-authoring-office-documents-on-a-mapped-webdav-drive
34. WebDAV vs FTP: Understanding the Differences | MyWorkDrive, https://www.myworkdrive.com/blog/webdav-vs-ftp
35. Which file access is the best : Webdav or FTP? - Stack Overflow, https://stackoverflow.com/questions/11216884/which-file-access-is-the-best-webdav-or-ftp
36. Unable to upload files larger than 2GB via WebDav - ℹ️ Support - Nextcloud community, https://help.nextcloud.com/t/unable-to-upload-files-larger-than-2gb-via-webdav/200157
37. Large file support over webdav - Nextcloud community, https://help.nextcloud.com/t/large-file-support-over-webdav/168413
38. WebDAV File Size Limit: Resolving the Issue in Windows | MyWorkDrive, https://www.myworkdrive.com/blog/webdav-file-size-limit
39. Problem with WebDAV files, moving ang large file issues - Synology Community, https://community.synology.com/enu/forum/17/post/114161
40. WebDAV File Size Limit: Resolving the Issue in Windows …, https://www.myworkdrive.com/blog/webdav-file-size-limit/
41. HTTP Authentication: Basic and Digest Access Authentication - WebDAV Resources, http://www.webdav.org/specs/rfc2617.html
42. 10. Basic and Digest Authentication - Spring, https://docs.spring.io/spring-security/site/docs/3.1.x/reference/basic.html
43. What is the difference between Digest and Basic Authentication? - Stack Overflow, https://stackoverflow.com/questions/9534602/what-is-the-difference-between-digest-and-basic-authentication
44. WebDAV — Cyberduck Help documentation, https://docs.cyberduck.io/protocols/webdav/
45. Security - IBM, https://www.ibm.com/docs/en/tamino/10.7.0?topic=functionality-security
46. http://www.webdav.org/specs/rfc3744.xml, http://www.webdav.org/specs/rfc3744.xml
47. CalDAV API Developer’s Guide | Google Calendar, https://developers.google.com/workspace/calendar/caldav/v2/guide
48. WebDAV/CardDAV/CalDAV - Purelymail, https://purelymail.com/docs/webDav
49. Mastering CardDAV Server: The ultimate guide to Contact Synchronization - Contactzilla, https://contactzilla.com/best-carddav-server-for-secure-contact-management/
50. WebDAV Vs. FTP: Which Is Better for Transferring Files? - jscape, https://www.jscape.com/blog/webdav-vs.-ftp-which-is-better-for-transferring-files
51. WebDav vs NFS vs FTP - Which is Best Choice for File Access? - Web Hosting Forum, https://forumweb.hosting/17481-webdav-vs-nfs-vs-ftp-which-is-best-choice-for-file-access.html
52. Which Protocols Are Used for File Sharing? A 2025 Guide to FTP, SFTP, SMB, and More, https://www.webasha.com/blog/which-protocols-are-used-for-file-sharing-guide-to-ftp-sftp-smb-and-more
53. Inquiry about the Deprecation of WebClient/WebDAV Services, Overall Impact, and Replacement Options - Microsoft Learn, https://learn.microsoft.com/en-us/answers/questions/1609470/inquiry-about-the-deprecation-of-webclient-webdav
54. Block vs File vs Object Storage - Difference Between Data Storage Services - AWS, https://aws.amazon.com/compare/the-difference-between-block-file-object-storage/
55. Difference between Object Storage And File Storage - Stack Overflow, https://stackoverflow.com/questions/14925791/difference-between-object-storage-and-file-storage
56. Object vs. File vs. Block Storage: What’s the Difference? | IBM, https://www.ibm.com/think/topics/object-vs-file-vs-block-storage
57. Full Guide to WebDAV File Sharing and Transfer for Seamless Workflows - MultCloud, https://www.multcloud.com/tutorials/webdav-file-sharing-0121-gc.html
58. AWS EFS vs EBS vs S3 (differences & when to use?) [closed] - Stack Overflow, https://stackoverflow.com/questions/29575877/aws-efs-vs-ebs-vs-s3-differences-when-to-use
59. What Is WebDAV? Understanding Web Distributed Authoring and Versioning in 2025, https://www.cloudwards.net/what-is-webdav/
60. How to create a WebDAV share on JuiceFS?, https://juicefs.com/en/blog/usage-tips/setting-up-webdav-on-juicefs
61. WebDAV: What it is, where it turns up, and its alternatives - Comparitech, https://www.comparitech.com/net-admin/webdav/
62. WebDAV - Application Control | FortiGuard Labs - Fortinet, https://fortiguard.fortinet.com/appcontrol/15862
63. WebDAV - | Documentation | Cloud Hub, https://documentation.pantaris.io/information/developer-documentation/project-files/webdav