요약

  • PubSubHubbub은 구독자가 각 사이트에 되풀이해 ‘새 글 있나요?’라고 묻는 방식을 발행자·허브·콜백의 연결로 바꿨다. 2010년 초안에서 허브가 갱신된 피드를 가져와 구독자에게 배포했다. 속도는 중간 배달대의 일에서 나왔다.
  • 2018년 W3C WebSub 권고안에서 202 Accepted는 신청을 받았다는 회신일 뿐, 구독 완료 증거는 아니었다. 콜백 확인과 기한 있는 구독이 뒤따랐고, 구독자는 기한 전에 다시 신청해야 했다.

새 글을 찾아다니던 발걸음

피드 읽기 서비스는 새 글이 없어도 여러 사이트에 같은 피드를 주기적으로 요청한다. 대부분 이전 내용과 같다. 2010년 2월의 PubSubHubbub Core 0.3 초안은 발행자가 Atom이나 RSS 피드에 허브를 알리고, 내용이 바뀌면 허브에 통지하는 길을 제시했다. 허브가 피드를 가져와 바뀐 항목을 찾고 구독자의 콜백 주소로 보낸다.

발행 사이트의 문 앞에서 모든 독자가 같은 질문을 하지 않아도 된다. 발행자가 배달대에 한 번 알리면 배달대가 목록을 맡는다. 초안의 참조 구현은 Google App Engine을 겨냥했지만, 문서는 누구나 허브를 운영할 수 있다고 밝혔다. 프로토콜은 개방돼 있었다. 특정 구독의 전달 경로에는 발행자가 공지한 실제 허브가 있었다.

구독자는 인터넷에서 접근 가능한 콜백 URL을 내야 했다. 허브는 그곳에 hub.challenge를 보내고 동일한 값을 돌려받아 실제 신청 의사를 확인했다. 남의 콜백 주소를 기입해 멋대로 가입하거나 탈퇴시키는 일을 막는 절차다. 허브는 구독 목록과 갱신 배포도 관리했다. 독자가 하던 반복 확인을 줄인 만큼 중개자의 운영 일이 늘었다.

202는 접수증이었다

W3C는 2018년 1월 WebSub를 권고안으로 발표했다. PubSubHubbub의 새 이름이었다. 당시의 권고안은 발행자·허브·구독자 구조를 유지하면서 구독 대상을 웹 자원으로 넓혔다. 발행자가 대상과 허브를 공지하고, 구독자는 허브에 POST를 보내며, 허브는 콜백으로 내용을 POST한다.

HTTP 202 Accepted는 완료 통지처럼 보인다. 그러나 권고안에서 이는 허브가 처리 가능한 신청을 받았고, 이후 검증과 의사 확인을 진행한다는 뜻이다. 허브는 자체 규칙에 따라 대상이나 콜백을 거절할 수 있다. 콜백에는 검증용 값을 보내 답을 확인해야 한다. 신청 접수, 구독 확인, 실제 배달은 서로 다른 세 단계다. 202만 집계한 운영판은 배달을 시작하기도 전에 성공을 선언한다.

구독에는 시한도 붙었다. 2010년 초안은 기한을 허용하고 허브가 먼저 구독자에게 재확인해 자동 갱신하는 흐름을 설명했다. 2018년 권고안은 허브에 기한 집행을 요구했고 영구 구독을 금지했다. 허브가 확인 단계에서 hub.lease_seconds를 알려 주면 구독자는 기한 전에 다시 요청해야 했다. 피드가 계속 공개되고 새 글이 올라와도 갱신을 놓친 콜백에는 푸시 배달이 끊길 수 있다.

권고안은 여러 허브와 독립 구현을 허용했다. 발행자가 어느 허브를 공지할지 정하고, 선택된 허브는 신청을 받아들일지, 콜백이 유효한지, 기한이 남았는지, 실패한 배달을 언제 재시도할지 관리한다. 발행자는 지정한 허브에 갱신을 알려야 하지만 그 방식은 양측이 정한다. 허브가 내용을 가져와 콜백으로 보낸다. 발행, 허브 통지, 신청 접수, 확인, 유효한 기한, 배달 완료는 ‘실시간’이라는 한마디로 합칠 수 없는 기록이다.