요약

  • RFC 3229는 조건부 GET에 델타 인코딩을 도입했습니다. 클라이언트는If-None-Match로 캐시된 인스턴스를 지명하고,A-IM으로 수용 가능한 변환을 알리며, 또 다른 완전한 사본 대신 226과IM설명을 받을 수 있습니다.
  • 재구성에는 세 가지 식별성이 관여합니다.Delta-Base는 기존 인스턴스를 지명하고, 본문은 변환 데이터를 담으며, 응답 ETag는 재구성된 현재 인스턴스—델타 바이트가 아니라—를 지명합니다.
  • 새 상태 코드는 호환성 장벽이었습니다. 낯선 헤더를 무시하는 중개자가 차이를 캐시한 뒤 나중에 그것을 자원 전체로 서비스할 수 있었기 때문입니다. 바이트를 절약하려면 의미론적 불완전성을 드러내야 했습니다.

조건부 조회에는 여전히 전 아니면 무의 청구서가 있었다

캐싱은 웹 초창기에 한 종류의 반복을 해결했습니다. 저장된 응답이 여전히 최신이면 조건부 요청은 304 Not Modified를 받아 또 다른 사본을 피할 수 있었습니다. 그러나 아주 조금이라도 자원이 바뀌었다면 일반적인 답은 완전한 새 값이었습니다.

이는 일관성을 이분법적으로 만들었습니다. 기존 인스턴스는 변경 없이 재사용 가능하거나 전송에 무용하거나 둘 중 하나였습니다. 한 단락만 바뀌어도 서버는 바뀌지 않은 모든 단락을 다시 보내야 했습니다.

RFC 3229는 2002년 1월에 발표되며, 캐시가 예 아니오의 증인 이상이 될 수 있는지 물었습니다. 클라이언트가 이미 이전 인스턴스를 보유하고 있다면, 서버는 변경 사항에 대한 설명을 보낼 수 있습니다. 그 델타를 기존 베이스에 적용하면 현재 인스턴스를 복원할 수 있습니다.

이 제안은 의도적으로 선택 사양이었습니다. 추가 네트워크 왕복 없이 평균 응답 크기를 줄이려 했고, 하나 이상의 델타 형식을 지원했으며, 그 존재를 모르는 HTTP/1.0·HTTP/1.1 구현과 공존해야 했습니다. 모든 자원이나 모든 변경이 유용한 델타를 만들어내리라는 보장은 하지 않았습니다.

델타는 압축된 사본이 아니었다

이 메커니즘은 서로 다른 변환을 분리할 만큼 정밀한 어휘에 의존했습니다. RFC 3229는 “인스턴스”를 콘텐츠 코딩 이후, 인스턴스 조작과 전송 코딩 이전 단계에서 선택된 변형에 대해 200 GET이 반환할 것으로 정의했습니다.

델타는 인스턴스 사이에서 계산됩니다. 현재 인스턴스의 더 작은 직렬화가 아닙니다. 압축은 기존 사본 없이도 디코딩할 수 있지만, 델타는 일반적으로 그 차이가 계산된 특정 베이스를 필요로 합니다.

델타는 바이트 범위도 아닙니다. 범위는 하나의 현재 인스턴스에서 좌표를 선택합니다. 델타는 한 인스턴스가 다른 인스턴스와 어떻게 다른지 기술합니다. 여섯 바이트의 명령이 문서 곳곳에 흩어진 변경을 재현할 수 있는 반면, 여섯 바이트의 범위는 그저 선택된 여섯 바이트일 뿐입니다.

이 구분은 226을 PATCH와도 분리합니다. 226의 본문은 GET에 대한 응답이며, 수신자에게 현재 표현 상태를 복원하는 방법을 알려줍니다. 자원을 변경하라는 요청이 아닙니다. RFC 3229는 정의된 메커니즘을 GET에 대한 응답으로 명시적으로 제한했습니다.

클라이언트는 자신의 기존 지식을 보여야 했다

델타 서비스는 클라이언트 측의 증거에서 시작됩니다.If-None-Match는 클라이언트가 보유한 이전 인스턴스들의 엔터티 태그를 하나 이상 나열합니다.A-IM은 클라이언트가 수용할 수 있는 인스턴스 조작—예를 들어 델타 코딩—을 나열합니다.

지명된 인스턴스가 여전히 최신이라면 아무것도 바뀌지 않았으므로 기존의 304 경로가 그대로 옳습니다. 바뀌었다면, 능력 있는 서버는 제안된 베이스를 골라 호환되는 델타를 계산할 수 있습니다. 서버에 베이스가 없거나, 조작을 지원하지 않거나, 계산이 유익하지 않다고 판단하면 일반적인 200도 언제든 가능합니다.

따라서 이 요청은 지시가 아니라 제안입니다. 클라이언트는 실제로 재구성할 수 있는 베이스와 디코딩할 수 있는 형식을 통제합니다. 오리진은 보유한 과거 인스턴스, 작업 수행 여부, 전체 전송이 더 저렴한지를 통제합니다.

이 협상은 낙관적 추측을 막습니다. 양쪽이 무엇으로부터의 차이인지, 그리고 그것을 어떻게 적용할지 합의하기 전에는 서버가 “그 차이”를 안전하게 보낼 수 없습니다.

하나의 응답이 세 가지 식별성을 담았다

재구성 사슬에는 서로 분리된 세 개체가 있습니다. 베이스 인스턴스는 이미 캐시에 있습니다. 응답 본문은 델타 명령을 담습니다. 그 명령을 적용한 결과가 현재 인스턴스입니다.

여러 베이스 ETag가 제안되었을 때,Delta-Base는 서버가 어느 것을 골랐는지 클라이언트에 알립니다. 226 응답의 ETag는 재구성이 만들어내는 현재 인스턴스를 지명합니다. RFC 3229는 그 ETag를 델타 값과 결부하는 것이 의미가 없다고 명시적으로 경고합니다. 델타 자체는 인스턴스가 아니기 때문입니다.

여기가 226의 핵심입니다. 메시지 본문은 그 자체로 사용 가능한 표현이 아니면서도 옳을 수 있습니다. 그 의미는 특정 베이스, 특정 조작, 의도된 결과 식별성의 함수입니다.

Content-Length는 눈앞의 메시지를 따릅니다. 델타 본문을 측정하는 것이지 재구성된 현재 인스턴스가 아닙니다. 그 길이를 현재 자원의 길이로 다루면 프로토콜 효율이 잘림처럼 보이게 됩니다.

변환 순서가 증거의 일부가 되었다

RFC 3229는 인스턴스 조작을 더 큰 메시지 생성 순서 안에 놓았습니다. 오리진은 자원과 변형을 선택하고, 콘텐츠 코딩을 적용하고, 인스턴스 ETag를 부여하고, 델타나 범위 같은 인스턴스 조작을 적용하고, 그다음에야 전송 코딩을 적용합니다.

이 계층들은 서로 교환할 수 없습니다. 여러 인스턴스 조작이 일어나면 그 순서는A-IM과IM으로 알려지고 보고된 순서입니다. 델타 후 범위는 반드시 범위 후 델타와 같지 않습니다. 콘텐츠 코딩으로서의 압축은 ETag와 델타가 이해되는 대상 인스턴스를 바꾸고, 이후 조작으로서의 압축은 다른 계층을 바꿉니다.

따라서 프로토콜은 순서를 관측 가능하게 만들었습니다. 캐시는 조작 이름들만 보관한 채 재생 중에 몰래 순서를 바꿀 수 없습니다. 재구성 조리법에는 순서, 매개변수, 베이스 식별성이 포함됩니다.

효율성은 구현자를 아낀 바이트만 생각하게 유혹합니다. 그러나 여기서 바이트가 표현으로 바뀌는 방법을 설명하는 메타데이터가 그 표현의 계보의 일부입니다.

왜 또 하나의 2xx 코드가 필요했는가

설계자들은 처음에 새 상태 코드 추가에 저항했습니다. 226의 최종 도입 이유는 장식적 분류가 아니라 배포된 캐시 행동이었습니다.

HTTP 수신자는 일반적으로 이해하지 못하는 헤더 필드를 무시하는 것으로 기대됩니다. 따라서 레거시 중개자는IM을 무시하고 델타 본문을 저장한 뒤, 나중에 완전한 표현을 받았다고 믿는 무지의 클라이언트에게 그 바이트를 보낼 수 있었습니다. 호환 확장은 구형 소프트웨어가 설계대로 동작하는 그 자체 때문에 조용한 손상을 만들어냈을 것입니다.

RFC 3229는 낯선 새 성공 코드를 안전 경계로 썼습니다. 저자들은 기존 프록시가 알지 못하는 상태를 캐시하지 않고 전달하는 경향이 있음을 관찰했습니다. 이를 모르는 구성요소도 응답을 운반할 수 있지만, 델타를 일반 200 콘텐츠로 재표시할 가능성은 낮아집니다.

사양은 적어도 하나의 잘못된 검증 경로에 대해서는Vary: If-None-Match, A-IM만으로는 불충분하다고까지 명시합니다. 의미론적 단절은 레거시 로직이 무심코 지워버리지 않는 어딘가에서 드러나야 했습니다.

IM은 무슨 일이 일어났는지 말하고, 226은 전체로 가정하지 말라고 했다

델타 인코딩된 응답은 226을 쓰고IM을 포함해야 하며, 적어도 사용된 델타 코딩을 지명해야 합니다. 요청은A-IM으로 수용 가능한 인스턴스 조작을 제안하고If-None-Match로 베이스를 공급했어야 합니다.

상태는 GET이 이행되었으며 본문은 현재 인스턴스에 하나 이상의 조작을 적용한 결과를 표현한다고 말합니다. 그 조작에 따라서는 이 응답을 이전 또는 미래의 응답과 결합해야만 현재 인스턴스를 얻을 수도 있습니다.

이 코드는 그 자체로 “델타”를 뜻하지 않습니다. 이 프레임워크는 범위 선택과의 조합을 포함해 하나 이상의 인스턴스 조작을 기술할 수 있습니다.IM이 순서화된 조리법을 담고, 226이 응답이 조작되었음을 표시합니다.

이 분담은 이유 문구에 과부하를 주지 않습니다. “IM Used”는 의도적으로 짧습니다. 소프트웨어가 결과를 복원하려면 영어 문장이 아니라 구조화된 필드가 필요합니다.

캐시 안전성은 명시적 능력이 되었다

이를 모르는 캐시는 조작된 바이트를 일반 표현으로 저장해서는 안 됩니다. 반면 델타를 아는 캐시는 그것을 생산적으로 쓸 수 있습니다. RFC 3229는 저장을 금지하는 대신 특별 규칙을 정의했습니다.

능력 있는 캐시는 모든 조작을 디코딩해 현재 인스턴스를 복원하고 일반 200 응답으로 저장할 수 있습니다. 범위 선택만 제외하고 모두 디코딩해 올바른 206 응답으로 저장할 수도 있습니다. 아니면 전용 제약 아래 원시 226 항목을 보관할 수도 있습니다.

원시 재사용은 엄격합니다. 다음 요청은 저장된 조작들—관련 순서와 매개변수 포함—을 수용해야 합니다. 캐시에는 여전히 만료, 검증, 베이스 및 응답 식별성 규칙이 필요합니다. 저장된 델타는 미래의 어떤 GET이든 답할 수 있는 독립 변형이 아닙니다.

imCache-Control 확장은 이 능력 경계를 지원했습니다. 신중히 표시된 응답은 일반 캐시에는no-store를 적용하면서, 전체 IM 계약을 이해하는 구현이 수반된 캐시 지시를 따르도록 허용할 수 있습니다.

과거를 보존하는 데에는 대가가 있었다

델타 인코딩은 누군가 적절한 과거를 보존해야만 전송을 절약합니다. 여러 기존 인스턴스를 가진 클라이언트는 여러 ETag를 나열할 수 있습니다. 대응하는 이력을 가진 오리진은 유용한 델타를 만드는 베이스를 골라Delta-Base로 지명할 수 있습니다.

그러나 캐시 공간은 유한하고 오리진의 이력도 유한하며, 여러 후보 델타를 계산하는 데는 CPU, 메모리, I/O 비용이 듭니다. 인스턴스가 보존할 가치가 있을 수 있다는 서버의 힌트는 오리진이 영원히 그것을 지키겠다는 약속이 아닙니다.

따라서 이 최적화는 저장 인센티브를 바꿉니다. 클라이언트는 더 이상 직접 표시되지 않더라도 유용한 재구성 베이스가 될 수 있으므로 기존 인스턴스를 유지할 수 있습니다. 서버는 미래의 절약이 비용을 정당화하는 곳에서만 버전을 보존하거나 델타를 미리 계산할 수 있습니다.

이 때문에 선택 사양성은 구조적입니다. 실패의 신호가 아닙니다. 델타가 더 크거나, 느리거나, 불가용하거나, 운영상 부적절할 때 서버는 200을 반환할 자유를 유지해야 합니다.

현재 레지스트리는 그 어휘를 지키고 있다

IANA HTTP 상태 코드 레지스트리는 여전히 226 IM Used를 RFC 3229로 등록합니다.IANA HTTP 필드 이름 레지스트리는A-IM,Delta-Base,IM을 영구 필드로 나열합니다.

등록이 배포 보편성을 확립하지는 않습니다. 프로토콜 기호가 정의된 의미를 유지함을 확립할 뿐입니다. 그것들을 만난 수신자는 계약을 찾을 수 있고, 구현자는 무관한 “증분” 형식으로 안전하게 재활용할 수 없습니다.

따라서 역사적 교훈은 모든 현대 전송이 델타가 되었다는 것이 아닙니다. 양쪽과 캐시 경로가 그 표현을 신뢰할 만하게 만들 만큼 충분한 상태를 보존할 수 있을 때, HTTP가 하나를 표현할 방법을 찾았다는 것입니다.

사본은 재구성 이후에야 도착했다

HTTP 226은 메시지와 표현 사이의 경계를 옮겼습니다. 전송선은 현재 인스턴스보다 작은 무언가를 운반하면서도 그 작은 것이 곧 인스턴스라고 주장하지 않을 수 있었습니다.

그 절약은 귀속의 사슬에 의존했습니다. 클라이언트는 자신이 어떤 기존 인스턴스를 보유하는지 증명했고, 서버는 베이스를 선택·지명했고,IM은 순서화된 변환을 지정했고, 응답 ETag는 재구성된 현재 상태를 지명했고, 캐시는 그 사슬을 이해하거나 바이트를 전체로 다루는 것을 삼갔습니다.

이 사슬 없는 델타는 효율적인 진실이 아닙니다. 겉보기 작음이 자신이 가정하는 상태를 감추는, 모호한 바이트 패치입니다.

이 상태 코드의 조용한 성과는 그 의존성을 무시할 수 없게 만든 것입니다. 수신자는 새 사본을 받지 않았습니다. 이미 가지고 있음을 증명할 수 있는 무언가로부터 새 사본을 만드는 신뢰할 만한 방법을 받았습니다.