[TIL] HTTP: The Definitive Guide "p424 ~ p432"

시윤·2026년 2월 20일

TIL http

[TIL] Two Pages Per Day

목록 보기

154/159

Chapter 19. Publishing Systems

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

✏️ 요약

FrontPage Server Extensions for Publishing Support

FrontPage(FP) : 마이크로소프트에서 제공하는 다목적 웹 저작 및 게시 도구
- 웹 사이트 생성과 관리를 하나로 결합하려는 시도
FrontPage Server Extensions(FPSE) : 서버 사이드의 FP 확장 프로그램
- FP를 구동하는 클라이언트와 웹 사이트 사이에서 필요한 번역 처리 담당
- HTTP의 POST 요청 상위의 RPC 레이어에서 구현된 프로토콜 사용
FrontPage Publishing Architecture
- 1. FP 클라이언트가 본문에 FP 명령이 포함된 요청 메시지 전송
  - FP 명령에는 서버에서 파일을 저장/조회하는 내용이 포함됨
- 1. 서버가 일반적인 HTML이 아님을 판단 -> CGI나 ISAPI로 구현된 FPSE에 명령 전달
- 1. FPSE 실행 -> 파일 저장/조회
- 1. 처리 결과를 응답 메시지로 전송

FrontPage Vocabulary

Virtual server : 동일 서버에서 동작하며 각각 고유한 도메인과 IP를 가진 중복된 웹 사이트 중 하나를 칭하는 용어 -> 한 서버에 여러 웹 사이트를 호스팅 할 수 있으므로 multi-hosting 웹 서버라고도 부른다
Root web : 웹 서버의 top-level 콘텐츠 디렉토리, multi-hosting 환경에서는 virtual server의 top-level 콘텐츠 디렉토리를 칭하는 용어 -> 즉 서버 하나당 root web은 한 개
Subweb : root web 혹은 다른 subweb으로부터 파생된 서브 디렉토리 -> FPSE 확장 웹

The FrontPage RPC Protocol

1. FP 클라이언트가 본문에 FP 명령이 포함된 요청 메시지 전송
```
POST /_vti_bin/_vti_aut/author.dll HTTP/1.1
Date: Sat, 12 Aug 2000 20:32:54 GMT
User-Agent: MSFrontPage/4.0
..........................................
<BODY>
method=list+documents%3a4%2e0%2e2%2e3717&service%5fname=&listHiddenDocs=false&listExp
lorerDocs=false&listRecurse=false&listFiles=true&listFolders=true&listLinkInfo=true&l
istIncludeParent=true&listDerived=false
&listBorders=false&listChildWebs=true&initialUrl=&folderList=%5b%3bTW%7c12+Aug+2000+2
0%3a33%3a04+%2d0000%5d
```
- URL : _vti_inf.html 와 같이 생김
- 본문 : <BODY> 내부에 method=<command> 형식으로 작성 (<command>에는 서버에서 파일을 저장/조회하는 명령이 포함됨)
- 명령 : 서버에서 파일을 저장/조회하기 위한 내용
  - service_name : 메서드가 실행해야 하는 웹 사이트의 URL
  - listHiddenDocs : 숨겨진 문서를 보이게 할 것인지 true/false로 설정 가능
  - listExploreDocs : 태스크 목록을 나열할지 true/false로 설정 가능
1. 서버가 일반적인 HTML이 아님을 판단 -> CGI나 ISAPI로 구현된 FPSE에 명령 전달
1. FPSE 실행 -> 파일 저장/조회

처리 결과를 응답 메시지로 전송

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Sat, 12 Aug 2000 22:49:50 GMT
Content-type: application/x-vermeer-rpc
X-FrontPage-User-Name: IUSER_MINSTAR
<html><head><title>RPC packet</title></head>
<body>
<p>method=list documents: 4.0.2.3717
<p>document_list=
<ul>
<li>document_name=help.gif
<\ul>

FrontPage Security Model

사용자를 administrators, authors, browsers 3가지 유형으로 정의
admin : 모든 권한 / authors : author + browser / browsers : browser
웹 서버마다 디폴트 실행 권한은 다르게 설정될 수 있다
모든 Subweb은 Root Web의 권한을 상속받거나 더 작은 범위에서 권한을 선택할 수 있다

WebDAV and Collaborative Authoring

Web Distributed Authoring and Versioning(WebDAV) : 웹 저작과 협업을 위한 추가 기능 제공
RFC 2518에 정의 -> 적절한 협업 플랫폼을 구축하기 위해 HTTP를 확장하는 데 초점을 맞춤
HTTP 헤더만으로 특정 앱의 정보나 상태를 전달하는 데 어려움이 있어 XML을 주로 사용함
- XML(Extensible Markup Language) : 구조화된 데이터의 표현 방식을 포맷팅하는 언어
- 구조화된 데이터 : 요청과 응답의 데이터를 트리 구조로 정합성 있게 전달
- 확장성 : 새로운 기능을 추가할 때 HTTP 규격을 해치지 않고 XML 요소만 추가할 수 있음

WebDAV Methods

PROPFIND : 리소스의 속성을 받는다
PROPPATCH : 한 개 이상의 리소스의 속성을 한 개 이상 지정한다
MKCOL : 컬렉션을 생성한다
COPY : 리소스 혹은 컬렉션을 주어진 source로부터 destination으로 복사한다 (source와 destination이 같은 기기가 아니어도 된다)
MOVE : 리소스 혹은 컬렉션을 주어진 source로부터 destination으로 이동한다 (source와 destination이 같은 기기가 아니어도 된다)
LOCK : 한 개 이상의 리소스를 lock 한다
UNLOCK : 이전에 lock 되어있던 리소스를 unlock 한다

WebDAV and XML

<D:propfind xmlns:D="DAV:">

RFC 2518에 WebDAV의 XML 스키마가 정의되어 있다
XML 네임스페이스 DAV: 사용 -> 다양한 요소와 속성이 포함되어 있음

WebDAV Headers

RFC 2518에 WebDAV의 새로운 메서드 기능을 강화하기 위한 몇 가지 HTTP 헤더가 정의되어 있다
DAV : 서버의 WebDAV 기능을 포함한 헤더 (WebDAV가 지원되는 모든 리소스는 OPTIONS 요청에 대한 응답으로 이 헤더를 포함해야 한다)
```
DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
```
Depth : 트리 구조로 그룹핑된 리소스에 대해 WebDAV를 확장하기 위해 필요한 헤더
```
Depth = "Depth" ":" ("0" | "1" | "infinity")
```
Destination : COPY와 MOVE 메서드에서 destination을 지정하는 헤더
```
Destination = "Destination" ":" absoluteURI
```
If : 조건을 명시하고 모든 조건이 false면 요청을 실패 처리, COPY와 PUT과 같은 메서드에서 사전 조건을 확인하기 위해 사용하기도 하지만 주로 lock 점유 여부를 확인하기 위해 사용한다
```
If = "If" ":" (1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-URL
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
State-token = Coded-URL
Coded-URL = "<" absoluteURI ">"
```
Lock-Token : Lock에 대한 정보를 명시하는 헤더 (UNLOCK 요청 메서드에서 Lock을 해제할 때 사용하거나 LOCK 메서드에 대한 응답에 정보를 담기 위해 사용)
```
Lock-Token = "Lock-Token" ":" Coded-URL
```
Overwrite : COPY나 MOVE 메서드에서 destination에 이미 파일이 존재하는 경우 덮어쓰기 여부를 지정하는 헤더
```
Overwrite = "Overwrite" ":" ("T" | "F")
```

Timeout : 클라이언트 측에서 Lock의 타임아웃 값을 지정하기 위한 헤더

TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
DAVTimeOutVal = 1*digit
Other = "Extend" field-value

✏️ 코멘트

ㅋㅋㅋㅋ 여행 갔다 와서 다시 읽었더니 또 앞의 내용이 잘 기억이 안 난다. 다행히 챕터 18은 끝내고 다녀와서 이해하는 데 크게 무리는 없었지만.. 책을 읽었는데 머릿속에 남는 게 없다면 별무소용이지 않을까. 완독 후에 중요한 내용들은 한 번 싹 정리하는 시간을 가져보는 게 좋겠다.

오늘 읽은 내용은 REST API가 보편화되기 전, 1990년대에서 2000년대 사이에 유행하던 FPSE 아키텍처에 대한 내용이었다. FPSE는 웹 서버 안에 호스팅 작업을 처리하기 위한 인터페이스를 두고 RPC를 통해 웹 사이트를 저장하고 조회하는 방식을 채택한다. HTTP 자체는 무상태 프로토콜이지만 리소스에 대해 Lock과 Unlock을 걸어주는 방식으로 인해 어쩔 수 없이 세션 중심으로 이루어져야 했다고 한다. 조금 부자연스러운 감이 있는 것 같다. 더 난감한 점은 서버에서 세션을 관리할 때 생기는 각종 문제들이다. 세션 관리에 소모되는 메모리나 scale-out의 어려움, redis와 같은 추가적인 캐시 서버의 도입을 고려하지 않을 수 없다. 나아가 캐시 서버의 Lock은 또 어떻게 처리해야 하는가.

한편 REST API는 HTTP 고유의 메서드를 활용하여 무상태로 리소스를 관리한다. 메서드 자체가 동사의 역할을 하기 때문에 URL은 리소스 그 자체를 나타내는 명사형으로 표현한다. 이쯤에서 나는 Lock과 Unlock이 없으면 REST API에서는 어떻게 리소스 동기화가 이루어지는지가 궁금해졌다. 데이터베이스 서버와의 통신이라면 DBMS에서 자체적으로 락 처리를 해주겠지만 단순히 서버의 문서를 가져오는 요청이라면 어떨까. 사실 이 부분은 이전 챕터에서 몇 번 다루었던 내용이다. 리소스마다 버전과 수정일시에 관한 메타데이터가 관리되기 때문에 If-None-Match나 If-Modified-Since와 같은 조건부 헤더를 통해 리소스를 동기화할 수 있다.

두 아키텍처의 동기화 방식 차이는 DB에서 이야기하는 Pessimistic Lock과 Optimistic Lock의 차이와 비슷한 느낌이지 않을까 싶다. FPSE 아키텍처가 데이터에 접근하기 전부터 락을 걸어버리는 Pessimistic Lock이라면, REST API는 충돌이 발생했을 때에만 실패 처리해버리는 Optimistic Lock을 사용하는 셈이다. 네트워크 성능 측면에서 REST가 훨씬 낫기 때문에 오늘날 REST API를 더 많이 사용하게 된 게 아닐까. 물론 REST를 사용하면 정합성이 중요한 데이터의 경우 애플리케이션 단에서 락을 걸어주어야 하지만... 필요할 때 구현하고 나머지는 빠르게 처리하는 게 현명하다고 생각한다.

오늘날 많이 사용하지 않는 아키텍처긴 하지만 꽤나 유익하고 재미있는 내용이었다..!