요약

  • 1997년 1월 RFC 2068은 자원 사이의 관계, 대개 요청한 자원과 다른 자원의 관계를 나타내는 HTTP Link 필드를 정의했다. 한 응답에 여러 값을 실을 수 있었고 HTML의 LINK 요소와 뜻을 비교했다.
  • 2010년 10월 RFC 5988은 1999년 6월 RFC 2616이 구현 경험 부족으로 그 필드를 없앴다고 기록했다. 빠진 뒤 지위가 흐려졌지만 일부 사용자 에이전트가 나중에 사용했고 새 용도도 나타났다.
  • RFC 5988은 한 문서 형식에 묶이지 않는 유형 있는 링크로 필드를 다시 정의했다. 2017년 10월 RFC 8288은 그 문서를 대체하면서 HTTP Link를 자원 관계를 전달하는 방식 중 하나로 유지했다.

링크가 응답 봉투에 올라타다

HTML 페이지 안의 링크는 찾기 쉽다. 브라우저가 본문이나 LINK 요소를 읽고 관계에 따라 행동을 정한다. 하지만 웹 자원의 본문은 언제나 HTML인 것은 아니다. 같은 자원을 다른 형식으로 받는 프로그램이라면 HTML 본문 속에만 있는 관계를 놓칠 수 있다. HTTP 응답 헤더에 적힌 관계는 클라이언트가 본문 형식을 해석하기 전에도 도착한다.

1997년 1월의 HTTP/1.1 표준 RFC 2068은 19.6.2.4절에서 그 자리를 마련했다. Link는 두 자원의 관계, 보통 요청한 자원과 다른 자원의 관계를 기술한다. 하나의 엔터티에 여러 값을 담을 수 있다. rel은 관계의 종류, title은 사람이 읽을 이름, anchor는 다른 시작점을 나타낸다. 문서는 이 필드가 HTML LINK 요소와 의미상 대응한다고 했다. 문서 안에 붙이던 안내판을 HTTP 응답의 봉투에도 붙인 셈이다.

위치가 달라지면 읽을 수 있는 대상도 달라진다. HTML 표시는 HTML을 이해하는 클라이언트에게 보인다. HTTP 필드는 본문이 다른 매체 형식이어도 응답과 함께 간다. 이를 아는 프로그램은 본문을 펼치기 전에 유형 있는 관계를 알 수 있다. 하지만 필드가 대상 자원을 가져오거나 사용자에게 무엇을 보여 줄지는 결정하지 않는다. 다음 행동은 응용 프로그램의 규칙에 달렸다.

RFC 2068에서 Link는 추가 기능에 놓였다. 근처에는 관계를 만들고 지우려는 요청 메서드 LINK와 UNLINK도 있었다. 요청 메서드와 응답 필드는 서로 다른 장치다. 2010년에 응답 필드가 다시 규정됐다고 그 메서드까지 함께 돌아온 것은 아니다. 이름이 비슷하다는 이유로 두 역사를 합치면 원문보다 훨씬 큰 복귀를 꾸며내게 된다.

1999년 판에 생긴 빈자리

1999년 6월 RFC 2616은 RFC 2068을 대체했지만 Link 필드의 정의는 싣지 않았다. 후대의 RFC 5988이 이유를 밝힌다. 구현 경험이 부족해 빠졌다는 것이다. HTTP/1.1의 새 기본 문서 작성자에게는 설명 가능한 구상이 있었지만, 계속 본문에 남길 만큼 작동 사례가 모이지 않았다.

이는 표준 편집 결정의 근거이지 1999년 모든 서버와 브라우저의 조사표가 아니다. 특정 제품이 필드를 보냈는지 읽었는지를 알려면 날짜가 붙은 출시 기록과 보존된 HTTP 응답이 필요하다. 현재 기록만으로도 한 번 규격에 실린 제안이 현장의 뒷받침이 약하면 다음 판에서 빠질 수 있다는 점은 분명하다.

삭제는 다른 비용도 낳았다. RFC 5988은 Link의 지위가 불분명해졌고, 이를 재사용하기보다 응용 프로그램마다 별도 헤더를 만들자는 생각이 나왔다고 적었다. 자원 관계를 알리는 하나의 공통 문제를 여러 작은 이름으로 쪼갤 수 있었다. 본문 형식이 HTML이 아닐 때도 관계를 알려야 한다는 요구는 그대로 남아 있었다.

2010년 문서는 삭제 이후 일부 사용자 에이전트가 이 필드를 구현했다고도 말한다. 예로 스타일시트가 언급되고 다른 사용처도 나왔다. “일부”는 전체 시장의 비율을 뜻하지 않는다. 대신 다시 표준화할 때 내밀 수 있는 경험과 과제가 늘었다는 사실을 보여 준다.

HTML에 주소를 묶지 않고 돌아오다

2010년 10월 RFC 5988은 이전 정의와 호환되는 갱신된 문법으로 Link를 다시 정했다. 더 큰 변화는 관계를 운반 방식에서 분리한 것이다. 유형 있는 링크에는 맥락 자원, 관계 유형, 대상 자원, 선택적인 대상 속성이 있다. 같은 관계를 HTML, Atom, HTTP 헤더에 적을 수 있다. 어느 형식에 적었는지가 관계 자체의 의미를 정하지 않는다.

현장에서는 한 자원이 여러 형식으로 표현될 수 있다. 관계가 HTML 판본 본문에만 숨어 있다면 다른 형식을 받은 클라이언트는 길잡이를 잃는다. 헤더는 어떤 본문 형식과도 함께 갈 수 있다. HTML 내부 링크도 HTML 독자에게는 계속 쓸모가 있다. 규격은 공통 모델을 제공하고, 실제로 어떤 관계를 사용할지는 각 응용 프로그램이 정하게 했다.

RFC 5988은 Atom에서 시작된 관계 유형 등록부를 넓혀 HTML에서 알려진 관계도 담았다. 등록된 관계명은 두 자원이 어떻게 이어지는지 설명한다. 대상이 지금 접속 가능한지, 모든 클라이언트가 그 링크를 따라야 하는지는 따로 확인할 일이다. 브라우저는 스타일시트를 찾고, 보관 도구는 라이선스나 다른 판본을 찾을 수 있다. 단어는 공유하지만 행동은 다르다.

2017년 10월 RFC 8288은 RFC 5988을 대체하고 맥락, 관계, 대상, 선택 속성이라는 틀을 이어받았다. HTTP의 Link는 관계를 표현하는 여러 형식 가운데 하나로 남았다. 문서는 웹 탐색 응용이 HTML에서 stylesheet를 찾고 선택적으로 HTTP 헤더에서도 찾는 경우와, Atom 응용이 다른 관계를 쓰는 경우를 구분한다. 관계 유형은 자원 간 의미이고, 매체 유형은 대상을 가져왔을 때 돌아오는 표현 형식이다. 서로 다른 질문이다.

그러므로 2010년은 1999년에 지운 문단을 복사해 되돌린 순간이 아니다. 1997년 필드는 HTML 링크와 닮은 관계를 HTTP에 실었다. 그 뒤 두 문서는 형식을 넘어서는 관계 모델과 등록 절차를 갖췄다. 같은 이름이 더 분명한 역할을 얻어 돌아왔다.

표준이 두 번째 발자국을 기다린 시간

문서 발행과 실제 배포를 같은 일로 보면 순서가 변덕스러워 보인다. 1997년에는 설명할 만한 구상이 있었다. 1999년에는 기본 표준에 남길 구현 경험이 부족했다. 2010년에는 제한적인 구현과 새 용도를 가리킬 수 있었고, 2017년에는 후속 문서로 발전했다. 문서 속 자리는 편집자가 정하지만 그 결정을 뒷받침하는 발자국은 작동하는 프로그램이 남긴다.

걸린 것은 헤더 이름 이상의 문제다. HTML 본문 속 관계는 그 표현 형식에 딸린다. HTTP 응답의 관계는 본문이 다른 형식이어도 보일 수 있다. 발행자와 클라이언트가 모든 자원을 웹페이지처럼 꾸미지 않고 유형 있는 연결을 공유할 자리가 생긴다.

특정 제품의 채택 시점을 자세히 알려면 날짜가 적힌 클라이언트와 서버의 기록 또는 보존된 응답이 필요하다. RFC들의 흐름은 제도적 전환을 이미 보여 준다. 한때 정의했다가 경험 부족으로 뺐던 필드가 HTML 밖에서 자원을 연결해야 하는 문제가 구체화되자 더 넓은 모델을 가지고 돌아왔다.