이 문서는 W3C 회원, 소프트웨어 개발자, 그리고 다른 W3C 그룹과 이해관계자들의 검토를 거쳤으며, 디렉터에 의해 W3C 권고안으로 승인되었습니다. 이 문서는 안정적인 문서로, 참고자료 또는 타 문서에서 인용 자료로 사용할 수
있습니다. W3C의 권고안 제공 역할은 명세에 주목하고 그 광범위한 배포를 촉진하는 것입니다. 이는 웹의
기능성과 상호운용성을 향상시킵니다.
웹멘션(Webmention)은 한 URL이 다른 URL에 링크했음을 알리는 알림입니다. 예를 들어, Alice가 자신의 블로그에 흥미로운 글을 씁니다.
Bob은 자신의 사이트에 Alice의 글에 대한 응답을 쓰고 원본 글로 되돌아가는 링크를 겁니다. Bob의 게시 소프트웨어는 Alice에게 해당 글에 답글이 달렸음을 알리는 Webmention을
전송하고, Alice의 소프트웨어는 그 답글을 원본 게시물의 댓글로 표시할 수 있습니다.
Webmention 전송은 블로그 게시물에만 국한되지 않으며, 다양한 종류의 콘텐츠와 응답에도 사용할 수 있습니다. 예를 들어, 응답은 이벤트에 대한
RSVP, 누군가 다른 게시물을 "좋아요"했다는 표시, 다른 게시물의 "북마크" 등일 수 있습니다. Webmention은 이러한 상호작용이 서로 다른 웹사이트 간에 일어날 수 있게 하여 분산된
소셜 웹을 가능하게 합니다.
1.1 Social Web 워킹 그룹
이 절은 비규범적입니다.
Webmention은 Social Web
워킹 그룹에서 작성 중인 여러 관련 명세들 중 하나입니다. 대체 접근 방식이나 보완 프로토콜에 관심 있는 구현자는 개요 문서[social-web-protocols]를 먼저 읽어보는 것이 좋습니다.
1.2 배경
이 절은 비규범적입니다.
Webmention 명세는 [Pingback] 명세의
단순화된 버전으로 시작되었습니다. Pingback은 소스와 대상 URL을 XML-RPC 페이로드로 전송할 것을 요구했지만, Webmention은 이를 form-encoded 페이로드로
단순화하여 HTML 폼에서 쉽게 사용 가능하게 했고, form-encoded 페이로드를 다루는 도구가 더 많아 작업이 쉬워졌으며 XML-RPC를 통해 시스템 코드의 다른 부분이 실수로
노출되는 취약성도 피할 수 있게 되었습니다.
그 후 Webmention은 요청 전송 및 검증 세부사항을 보다 자세히 규정하고, 소스 문서가 업데이트되거나 삭제될 때 알림을 보내는 기능까지
확장되었습니다. 자세한 내용은 IndieWeb 위키의 Webmention FAQ에서 확인할 수
있습니다.
1.3 개요
이 절은 비규범적입니다.
일반적인 Webmention 흐름은 다음과 같습니다:
Alice가 자신의 사이트에 흥미로운 콘텐츠를 게시합니다(해당 사이트는 Webmention을 받을 수 있도록 설정되어 있음).
Bob이 이 콘텐츠를 보고 자신의 사이트에 대해 그것에 대해 댓글을 달고, Alice의 원본 게시물로 링크합니다.
Webmention을 사용하여 Bob의 게시 소프트웨어는 자동으로 Bob 게시물의 URL이 Alice의 게시물을 링크했다는 사실을 Alice의
서버에 알립니다.
Alice의 게시 소프트웨어는 Bob의 게시물이 실제로 그녀의 게시물을 언급하고 있는지 검증한 후 이 정보를 자신의 사이트에 포함합니다.
1.4 프로토콜 요약
이 절은 비규범적입니다.
Webmention은 소스 URL에서 대상 URL로 "보내어" 대상에게 소스에서 언급되었음을 알리는 방식입니다.
사용자 Aaron이 자신의 블로그에 게시물을 작성합니다.
사용자 Barnaby는 Aaron의 게시물로 링크하는 자신의 블로그 게시물을 작성합니다.
게시물을 발행한 후(즉, 게시물이 URL을 가지게 된 후), Barnaby의 서버는 게시 과정의 일부로 Aaron의 게시물 언급을
감지합니다.
Barnaby의 서버는 Aaron의 게시물에서 Webmention 엔드포인트를 찾기 위한 Webmention 탐색을 수행합니다(찾지
못하면 처리를 중단합니다).
Barnaby의 서버는 다음을 포함하여 Aaron의 게시물 Webmention 엔드포인트에 Webmention 알림을 보냅니다:
source는 Barnaby 게시물의 영구 링크(permalink)로 설정됩니다.
target는 Aaron 게시물의 영구 링크로 설정됩니다.
Aaron의 서버가 Webmention을 수신합니다.
Aaron의 서버는 Webmention의 target이 Aaron 블로그의 유효한 영구 링크인지
검증합니다(유효하지 않으면 처리 중단).
Aaron의 서버는 Webmention의 source를 가져와(리디렉션을 따름 [FETCH]) 해당 문서가 target에 대한 하이퍼링크를
포함하고 있는지 확인합니다(포함하지 않으면 처리 중단).
2. 적합성
이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "
SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", 그리고
"OPTIONAL"은 [RFC2119]에 설명된 대로 해석되어야 합니다.
2.1 적합성 클래스
Webmention 구현은 발신자(sender) 또는 수신자(receiver) 중 하나입니다. 이 절에서는 양쪽의 적합성 기준을
설명합니다.
아래에는 알려진 종류의 Webmention 구현이 나열되어 있습니다.
발신자(Senders)
Webmention Sender는 Webmention을 전송하는 구현체입니다. Sender가 Webmention을 보내려면 먼저
Receiver가 접근 가능한 URL에 문서가 있어야 합니다.
보고 있는 페이지를 대신해 컨텍스트 메뉴에서 Webmention을 전송하는 브라우저 플러그인
Webmention 엔드포인트 탐색 및 전달을 오프로드하는 웹 API
기존 소셜 미디어 게시물을 HTML 게시물로 변환하고 Webmention을 전송하는 프록시 서비스
수신자(Receivers)
Webmention Receiver는 자신의 Webmention 엔드포인트가 광고된 하나 이상의 대상 URL로 Webmention을
수신하는 구현체입니다. Webmention을 수신하려면 Receiver의 Webmention 엔드포인트를 광고하는 URL이 있어야 합니다. 해당 URL은 전적으로 다른 시스템이나 도메인에
존재할 수 있으므로 Receiver 구현의 일부로 간주되지 않습니다.
webmention.rocks는 구현을 실시간으로
테스트할 수 있는 많은 테스트 케이스를 제공합니다. 또한 Webmention 구현을 개발할 때 오류 발생 시 상세한 응답을 제공하므로 유용한 도구입니다.
3. 웹멘션 프로토콜
이 명세는 HTML 및 HTTP 링크 관계 모두에 대해 [HTML5]가 정의한 link rel 등록소를 사용합니다.
3.1 웹멘션 보내기
3.1.1 대상을 언급하는 소스 문서 작성
Webmention은 소스 URL에서 대상 URL로 "보내어" 대상에게 소스
URL에서 언급되었음을 알립니다. Webmention을 보내기 전에, Webmention을 "보낼" 소스 URL이 있어야 합니다. 소스는 종종 블로그 게시물이지만 어떠한 유형의
콘텐츠도 될 수 있습니다.
예를 들어,
https://waterpigs.example/post-by-barnaby 에 있는 URL은 Aaron의 게시물로의 링크를 포함한 다음과 같은 HTML을 가질 수 있습니다.
Example 1
<!doctype html><html><body><ahref="https://aaronpk.example/post-by-aaron">This is a great post</a></body></html>
3.1.2 발신자가 수신자의 Webmention 엔드포인트 탐색
발신자는 MUST 대상 URL을 가져오고(리디렉션을 따름[FETCH]) rel 값이 webmention인 HTTP Link 헤더[RFC5988]가 있는지 확인해야 합니다. 문서의 콘텐츠 타입이 HTML인 경우,
발신자는 rel 값이 webmention인 HTML <link> 및 <a> 요소를 찾아야
합니다. 이러한 항목이 여러 개 있는 경우, 우선 순위는 첫 번째 HTTP Link 헤더, 그 다음 문서 순서상의 첫 번째 <link> 또는
<a> 요소입니다. 발신자는 이 세 가지 옵션을 모두 지원해야 하며 이 순서대로 대체해야 합니다.
엔드포인트는 상대 URL일 수 있으며, 이 경우 발신자는 MUST 해당 엔드포인트를 target URL에 대해 [URL]에 따라 상대적으로 해석해야 합니다.
엔드포인트는 쿼리 문자열 매개변수를 포함할 수 있으며, 이 경우 쿼리 문자열
매개변수는 보존되어야 하고 Webmention 요청을 전송할 때 POST 본문 매개변수로 전송되어서는 안 됩니다(MUST).
발신자는 먼저 Link 헤더를 확인하기 위해 HTTP HEAD 요청[RFC7231]을 시도할 수 있습니다(MAY).
발신자는 대상 URL을 가져올 때 사용되는 HTTP User
Agent[RFC7231]를 Webmention 탐색의 일부로 이루어진 요청임을
수신자에게 알리기 위해 사용자 지정할 수 있습니다(MAY). 이 경우 User Agent 문자열에
"Webmention"을 포함하는 것이 권장됩니다. 이는 사람들이 탐색 요청이 왜 이루어졌는지 알아볼 수 있는 단서를 제공합니다.
3.1.3 발신자가 수신자에게 알림 전송
발신자는 MUST Webmention 엔드포인트로
HTML5의 x-www-form-urlencoded 형식으로 source와 target 파라미터를 POST해야 합니다. 여기서
source는 링크를 포함한 발신자 페이지의 URL이고, target은 링크된 페이지의 URL입니다.
Webmention 엔드포인트 URL에 쿼리 문자열 매개변수가 포함된 경우, 그 쿼리 문자열 매개변수는 MUST 보존되어야 하며 POST 본문에 포함되어서는 안 됩니다(MUST NOT).
Webmention 엔드포인트는 요청을 검증하고 처리한 후 HTTP 상태 코드를 반환합니다[RFC7231]. 대부분의 경우 요청이 큐에 들어가 비동기로 처리됨을 나타내는
202 Accepted 또는 201 Created가 반환됩니다. 응답 코드가 201이면 Location 헤더에
요청 상태를 모니터링할 수 있는 URL이 포함됩니다.
소스 URL이 업데이트된 경우, 발신자는 이전에 보낸 모든 Webmention을 재전송하는 것이
권장됩니다(SHOULD). 여기에는 문서에서 제거된 URL에 대해 Webmention을 다시 보내는 것도
포함될 수 있으며, 또한 해당 URL에 새로 나타나는 링크에 대해 Webmention을 전송해야 합니다(SHOULD).
이는 Webmention 수신자가 소스 문서의 표시를 업데이트하거나, 자신들의 URL을 언급한
게시물이 업데이트되었음을 수신자에게 알릴 수 있게 합니다.
게시물이 업데이트되었을 때 Webmention을 보낼 경우, 발신자는 대상 URL마다
Webmention 엔드포인트를 다시 탐색해야 합니다(MUST), 대상이 Webmention 엔드포인트를
변경했을 가능성에 대비하기 위함입니다.
만약 소스 URL 페이지에 소스에 대한 응답(예: 댓글)이 표시된다면, 발신자는 이를 소스
URL의 업데이트로 간주하고 이전에 보낸 Webmention을 재전송하는 것이 권장됩니다(SHOULD).
3.1.5 삭제된 게시물에 대한 웹멘션
전송
소스 URL이 삭제된 경우, 발신자는 해당 URL에 대해 HTTP
410 Gone 상태 코드를 반환하는 것이 권장됩니다(SHOULD). 또한 발신자는
보통 삭제된 게시물의 "묘비(tombstone)" 표현을 표시하는 것이 권장되며(예: 게시물의 속성 값을 공백으로 만들거나 게시물의 주요 콘텐츠(예: [h-entry]의 이름 또는 내용)를 "Deleted"로 대체), 그런 다음 해당
문서에 대해 이전에 보낸 모든 Webmention을 다시 전송해야 합니다(SHOULD).
이는 이전에 수신된 Webmention을 댓글이나 다른 상호작용으로 표시했던 수신자가 삭제를
지원하는 경우 해당 표시를 제거할 수 있게 하며, 업데이트만 지원하는 수신자에게는 합리적인 대체 동작을 제공합니다.
3.2 웹멘션 수신
source와 target 파라미터를 포함한 POST 요청을 수신하면, 수신자는
파라미터를 검증(아래 요청 검증 참조)하고 요청을 큐에 넣어 비동기로 처리하는 것이 권장됩니다(SHOULD). 이는 DoS 공격을 방지하기 위한 것입니다. 수신 처리 방식에 따라 요청에 대해 세 가지 가능한
응답이 있습니다.
수신자가 발신자가 상태를 확인할 수 있는 상태 페이지를 생성하는 경우, 수신자는 상태 URL을 가리키는
Location 헤더와 함께 HTTP 201 Created 응답을 반환해야 합니다(MUST). 응답 본문은 내용을 포함할 수 있습니다(MAY).
Example 4
HTTP/1.1 201 Created
Location: http://aaronpk.example/webmention/DEhB9Jme
수신자가 요청을 비동기로 처리하되 상태 URL을 반환하지 않는 경우, 수신자는 HTTP 202 Accepted
응답을 반환해야 합니다(MUST). 응답 본문은 내용을 포함할 수 있으며(MAY), 사람이 읽을 수 있는 응답을 제공하는 것이 권장됩니다.
Example 5
HTTP/1.1 202 Accepted
수신자가 요청을 동기적으로 처리하고 검증 단계를 수행하기로 선택한 경우(권장되지 않음), 성공 시 200 OK
상태로 응답해야 합니다(MUST).
3.2.1 요청 검증
수신자는 source와 target이 유효한 URL([URL])인지, 그리고 수신자가 지원하는 스킴인지 확인해야 합니다(MUST). 일반적으로 이는 source와 target의 스킴이
http 또는 https인지 확인하는 것을 의미합니다.
수신자는 source URL과 target URL이 동일한 경우 요청을 거부해야
합니다(MUST).
수신자는 target이 Webmention을 수락할 수 있는 유효한 리소스인지 확인하는 것이
권장됩니다(SHOULD). 이 검사는 심층 검증이 시작되기 전에 동기적으로 수행되어야 합니다. 무엇이
"유효한 리소스"인지는 수신자에 따라 다릅니다. 예를 들어, 어떤 수신자는 여러 도메인에 대해 Webmention을 허용할 수 있고, 다른 수신자는 엔드포인트가 위치한 동일
도메인에 대해서만 허용할 수 있습니다.
대상 URL에 프래그먼트 식별자(fragment identifier)가 포함될 수 있으며, 수신자가 어떤 URL이
Webmention을 받을 수 있는지를 제한하는 경우 프래그먼트는 검사 시 무시하는 것이 권장됩니다(SHOULD).
3.2.2 웹멘션 검증
Webmention 검증은 DoS(서비스 거부) 공격을 방지하기 위해 비동기로 처리하는 것이 권장됩니다(SHOULD).
수신자가 Webmention을 어떤 방식으로든 사용하려는 경우(예: 게시물에 댓글로 표시하거나 "좋아요" 카운터를
증가시키거나 게시물 작성자에게 알림을 보내는 경우), 수신자는 source에 대해 HTTP GET 요청을 수행하고(HTTP 리디렉션을 따르며, 따라야 하는
리디렉션 수를 제한하는 것이 권장됨) 실제로 대상 target을 언급하고 있는지 확인해야 합니다(MUST). 또한 수신자는 허용 가능한 콘텐츠 타입의 선호도를 나타내는 HTTP Accept 헤더를 포함하는 것이 권장됩니다(SHOULD).
수신자는 콘텐츠 유형별 규칙을 사용하여 소스 문서가 대상 URL을 언급하는지 판단하는 것이 권장됩니다(SHOULD). 예를 들어 [HTML5] 문서에서는 수신자가 <a href="*">,
<img src="*">, <video src="*"> 등과 같은 유사한 링크를 찾아야 합니다.
JSON([RFC7159]) 문서에서는 수신자가 값이 URL과 정확히 일치하는
속성을 찾아야 합니다. 일반 텍스트 문서의 경우 수신자는 문자열 검색으로 URL을 찾아야 합니다. 다른 콘텐츠 타입은 구현자의 재량에 따라 처리할 수 있습니다. 소스 문서는
Webmention으로 유효하다고 간주되려면 제공된 target URL과 정확히 일치해야 합니다(MUST).
이 시점에서 수신자는 소스 페이지의 콘텐츠를 대상 페이지나 다른 페이지에 게시할 수 있으며(MAY), 소스에서 수집한 다른 데이터와 함께 게시할 수 있습니다. 예를 들어 수신자는 소스의 내용을 댓글로
표시하거나, 게시물에 유사한 Webmention을 보낸 사람들의 목록에 작성자 프로필 사진을 표시할 수 있습니다.
Note
소스 페이지의 콘텐츠를 재게시할 때, 우연히 콘텐츠의 가시성을 변경하지 않도록 주의해야 합니다.
예를 들어 소스 문서가 제한된 관중만 볼 수 있다면, 재게시된 콘텐츠가 일반 대중에게 보이지 않도록 해야 합니다. 소스 문서는 인증으로 제한되거나 수신자도 동일한 방화벽
뒤에 있는 소스 URL일 수 있습니다.
3.2.3 오류 응답
만약 Webmention이 발신자(sender)의 잘못으로 성공하지 못한 경우, 수신자는 MUST400 Bad Request 상태 코드를 반환해야 하며 응답 본문에 오류 설명을 포함할 수 있습니다(MAY).
GET 요청을 수행하기 전에 동기적으로 반환될 수 있는 발신자 관련 가능한 오류는 다음과 같습니다:
지정된 target URL을 찾을 수 없음.
지정된 target URL이 Webmention을 허용하지 않음.
source URL이 잘못되었거나 지원되지 않는 URL 스킴(e.g. mailto:)임.
소스 URL의 콘텐츠를 가져온 후 발생할 수 있는 발신자 관련 가능한 오류는 다음과 같습니다:
source URL을 찾을 수 없음.
source URL에 target URL로의 링크가 포함되어 있지 않음.
만약 Webmention이 수신자 서버의 오류로 인해 성공하지 못한 경우, 수신자는 SHOULD500 Internal Server Error 상태 코드를 반환해야 하며 응답 본문에 오류 설명을
포함할 수 있습니다(MAY).
3.2.4 기존 웹멘션 업데이트
수신자가 과거에 동일한 source와 target으로
Webmention을 받은 적이 있는 경우,
두 검증 단계가 모두 성공하면, 수신자는 기존 Webmention에 대해 소스에서 수집한 데이터 업데이트하는 것이 권장됩니다(SHOULD).
Webmention 구현이 업데이트를 지원하는 경우(즉, "Webmention 업데이트 구현")에는, 기본 객체(primary object)의 속성에서
데이터를 업데이트하는 것을 지원해야 합니다(MUST)(예: 페이지의 [h-entry] 속성).
Webmention 업데이트 구현은 기본 객체의 자식 또는 다른 하위 객체(예: 페이지의 h-entry 내부에 있는 댓글 h-entry)로부터의
데이터 업데이트를 지원할 수 있습니다(MAY). 참고: 이를 지원하는 구현체는
[Salmention] 확장에 따라
지원하는 것을 고려할 수 있습니다.
소스에 대해 GET 요청을 수행했을 때 410 Gone 상태 코드를 받았거나
200 OK를 받고도 source에서 target에 대한 언급을 찾지 못한 경우, 수신자는 기존
Webmention을 삭제하거나 삭제로 표시하는 것이 권장됩니다(SHOULD).
Webmention 처리 작업은 멱등성(idempotent)을 유지하는 것이 권장됩니다(SHOULD). 즉, 동일한 source와
target에 대해 콘텐츠 변경 없이 여러 번 Webmention을 받더라도 여러 개의 답글로 표시되어서는 안 됩니다.
4. 보안 고려사항
4.1 악용 방지
검증 과정은 SHOULD DoS 공격 방지를 위해 3.2절에 따라 큐에 넣고 비동기적으로 처리해야 합니다.
수신자가 소스에서 가져온 데이터를 표시하기로 선택한 경우, MUST [XSS] 및 [CSRF] 공격을 방지하기 위해 해당 데이터를 인코딩 및/또는 필터링해야 합니다.
수신자는 MAY Webmention을 공개 전에
선별(모더레이션)할 수 있습니다.
수신자는 MAY 주기적으로 Webmention을 재검증하고
업데이트할 수 있습니다.
4.2 GET 요청 제한
Webmention 프로토콜은 발신자가 수신자의 엔드포인트를 발견하기 위해 GET(또는 HEAD) 요청을 하고, 그 다음 수신자가
실제로 링크가 있는지 확인하기 위해 발신자의 웹 페이지에 GET 요청을 보내는 것에 의존합니다. 이로 인해 발신자가 수신자로 하여금 임의의 URL에 GET 요청을 하게 만들어 DoS
공격의 벡터가 될 수 있습니다.
수신자는 MAY 링크를 검증할 때 우선적으로 HTTP HEAD
요청을 보내고, 반환된 콘텐츠 타입, 길이, 기타 HTTP 헤더를 점검한 후 전체 GET 요청을 할 것인지 결정할 수 있습니다.
수신자는 SHOULD 리디렉션 루프에 빠지지 않도록 따라가는
HTTP 리디렉션 수를 제한해야 하며, 예시로 20번 이하로 제한할 수 있습니다.
수신자는 SHOULD 검증되지 않은 소스 URL을 가져오는
데 소모하는 데이터량과 시간을 제한해야 합니다. 예를 들어, 소스 URL이 5초 이내에 응답하지 않으면 실패로 간주하거나, 한 페이지에서 1MB까지만 가져오도록 할 수 있습니다(대부분의
HTML이나 JSON 페이지는 이보다 작음).
4.3 localhost로 Webmention 전송
방지
발신자가 수신자의 Webmention 엔드포인트를 발견할 때 localhost나 기타
루프백(loopback) 주소가 엔드포인트인 경우는 거의 없습니다. 발신자에 인증이 필요 없는 localhost 서비스가 있을 경우, 악의적인 Webmention 수신자가 자체적으로
Webmention 엔드포인트를 조작하여 발신자가 본인에게 임의의 POST 요청을 하도록 만들 수 있습니다.
탐색 단계 중에 발신자가 엔드포인트가 localhost 또는 루프백 IP(127.0.0.0/8)임을
발견하면 해당 엔드포인트로 Webmention을 보내지 않는 것이 SHOULD NOT 합니다.
4.4 크로스사이트 요청 위조(CSRF)
이 명세는 인증 헤더나 세션 쿠키 등 추가 헤더 또는 파라미터가 포함될 수 있는 Webmention 요청에 대해 특별한
처리를 정의하지 않습니다. 다만, Webmention 엔드포인트가 추가 헤더를 받은 요청을 허용한다면, SHOULD
CSRF(Cross-Site Request Forgery) 공격으로부터 스스로를 보호해야 합니다. CSRF 공격을 막는 한 가지 방법은 Webmention 엔드포인트의 쿼리 스트링
파라미터에 CSRF 토큰을 포함하여, Webmention 발신자가 엔드포인트 발견 단계에서 이 토큰을 얻도록 하는 것입니다.
예를 들어, 대상 URL이 CSRF 토큰이 포함된 Webmention 엔드포인트를 광고할 수 있습니다:
Example 6
GET/post-by-aaron HTTP/1.1
Host: aaronpk.example
HTTP/1.1 200 OK
Link: <http://aaronpk.example/webmention?csrf=Q0NTVhYjI0NTVkNDA3M>; rel="webmention"
이제 Webmention 엔드포인트가 요청을 처리할 때, 가장 먼저 CSRF 토큰의 유효성을 검사한 후 나머지 처리를 진행할
수 있습니다.
4.5 보호된 리소스 접근 제한
공격자가 임의의 URL을 가리키는 Webmention 엔드포인트를 광고하는 것이 가능합니다. 따라서, 방화벽
뒤에 있거나 일반적으로 보호된 리소스에 접근이 가능한 서버에서 Webmention을 보내는 소프트웨어를 설치하는 경우, 공격자가 서버로 하여금 내부 서버에 POST 요청을 보내게 할 수
있다는 점을 인지해야 합니다. 이러한 서버가 보호된 리소스에 접근하지 못하도록 하기 위해서는 SHOULD 다음 중
하나 이상의 조치를 취해야 합니다:
발신자를 해당 내부 리소스에 접근할 수 없는 환경에서 실행
이 발신자에서 나가는 모든 HTTP 요청을 내부 리소스 접근을 막는 프록시를 거쳐 전송
4.6 보안 및 프라이버시 리뷰
이 질문들은 Self-Review Questionnaire: Security and Privacy([security-privacy-questionnaire])의 안내에 따라 본
명세의 보안 및 프라이버시 관련 고려사항을 개괄적으로 다룹니다.
이 명세가 개인 식별 정보를 다루나요?
Webmention에서 다루는 유일한 잠재적 개인 식별 정보는 source와 target URL입니다.
이 명세는 고가치 데이터를 다루나요?
아니요, 인증이나 기타 자격증명이 관여되지 않습니다.
이 명세는 브라우징 세션 간 지속되는 새로운 상태를 원본에 도입하나요?
아니요
이 명세는 웹에 지속적이고 크로스오리진 상태를 노출하나요?
Webmention 수신자는 Webmention 요청에 관한 정보를 가진 임시 리소스를 생성할 수 있습니다.
이 명세는 현재 접근할 수 없는 다른 데이터를 원본에 노출하나요?
아니요
이 명세는 새로운 스크립트 실행/로딩 메커니즘을 가능하게 하나요?
아니요
이 명세는 원본이 사용자의 위치 정보에 접근하도록 허용하나요?
아니요
이 명세는 원본이 사용자의 기기 센서에 접근하도록 허용하나요?
아니요
이 명세는 원본이 사용자의 로컬 컴퓨팅 환경의 측면에 접근하도록 허용하나요?
아니요
이 명세는 원본이 다른 기기에 접근하도록 허용하나요?
아니요
이 명세는 원본이 User Agent의 네이티브 UI 일부를 제어할 수 있도록 허용하나요?
아니요
이 명세는 웹에 임시 식별자를 노출하나요?
아니요
이 명세는 1st-party와 3rd-party 맥락의 동작을 구분하나요?
아니요
이 명세는 User Agent의 "시크릿 모드" 맥락에서 어떻게 동작해야 하나요?
Webmention은 상태를 저장하지 않으므로 "시크릿 모드"에서 별도의 고려사항이 없습니다.
이 명세는 사용자의 로컬 디바이스에 데이터를 저장하나요?
아니요
이 명세는 기본 보안 특성을 다운그레이드하는 것을 허용하나요?
아니요
5. 기타 고려사항
5.1 HTML이 아닌 콘텐츠에서 Webmention 보내기
만약 소스 문서가 HTML이 아닌 경우(PDF 등) 이거나, 일반적인 HTTP GET 요청으로
원본 소스를 가져올 수 없도록 제한되어 있다면(예: 유료벽 뒤에 있음, 클릭 동의가 필요함), HTML "랜딩 페이지"를 따로 만들어 Webmention을 보낼 모든 대상을 나열해야
합니다. 이런 HTML 랜딩 페이지를 생성한 뒤 Webmention을 보낼 때 소스 URL로 사용할 수 있습니다. 이를 통해 수신자는 검증을 위해 자신의 대상 URL에 대한 링크 유무를
확인할 수 있게 되며, 원본 전체 문서를 공개하지 않아도 됩니다.
HTML 랜딩 페이지를 만들면 제한된 콘텐츠(예: 학술 논문 같은 자료)에 대해 사람들이
참고하거나 링크할 수 있는 장소를 제공해줄 수 있으므로 인바운드 링크 증가에 도움이 될 수 있습니다. 학술 논문의 경우 HTML 랜딩 페이지에 참고문헌 목록을 HTML로 포함시키면, 이를
Webmention 대상(URL)로 사용할 수 있습니다.
5.2 대용량 데이터셋에 대한 Webmention
보내기
Webmention 소스 문서 자체가 매우 큰 경우(예: 테이블에 수천 개 레코드가 있는 거대한
HTML 페이지, 매우 큰 JSON 파일 등)에는 해당 소스 URL로 Webmention을 보내는 것을 피하는 것이 좋습니다. 그렇게 하면 수신자가 전체 데이터를 다운로드하여 본인의
대역폭을 많이 사용하게 되거나, 수신자가 파일 일부만 다운받아 자체 대역폭을 제한하려고 할 때 검증이 실패할 수도 있습니다. 수신자가 소스 문서로의 링크를 재게시하는 경우, 다른 방문자도
전체 데이터셋을 무심코 다운로드하게 될 수 있습니다.
브라우저에서 대용량 데이터셋을 페이지 단위로 나누는 것이 권장되는 것처럼, Webmention을 보낼
때도 소스 문서가 대용량이라면 보다 작은 데이터 페이지별로 Webmention을 보내야 합니다. 데이터셋이 HTML이라면 기존의 HTML 페이지를 소스 URL로 활용하면 되며,
JSON이라면 작은 JSON 문서를 별도의 URL로 만들어 각각 소스 URL로 사용할 수 있습니다.
5.3 탐색 중 캐시 헤더 준수
Webmention 탐색을 수행할 때, 발신자는 대상 URL이 반환하는
HTTP 캐시 헤더[RFC7234]를 SHOULD 존중하고, 캐시 헤더에서 지정된 것보다 더 자주 대상 URL을 가져오지 않아야 합니다.
6. IANA 고려사항
아래의 링크 관계 유형은 [RFC5988]
6.2.1절에 따라 IANA에 등재되어 있습니다:
관계 이름(Relation Name):
webmention
설명(Description):
Webmention 프로토콜을 지원하는 대상 URI임을 식별합니다. 이로써 게시 프로세스 중 어떤 리소스를 언급하는 클라이언트가 해당 엔드포인트에 연락하여 언급되었음을 알릴 수 있습니다.
에디터는 Webmention 명세의 오리지널 초안을 기여해준 Sandeep Shetty께
감사를 표합니다.
추가로, 에디터는 IndieWeb 커뮤니티와 다른 구현자들의 지원, 격려 및 열정에도
감사하며, Amy Guy, Benjamin Roberts, Ben Werdmüller, Dave
Wilkinson, Rob Sanderson, Tantek Çelik 등을 포함하나 이에 국한되지 않습니다.
참고: URL은 매우 다양한 방식과 맥락으로 사용될 수 있습니다. 엄격한 URL을 생성하고자 한다면
[RFC3986] 및 [RFC3987]을 참고하십시오. URL 규격은 URL의 정의, 여러 URL 처리
알고리즘, URL 구문 분석 및 해석을 위한 API를 포함합니다. 개발자는 https://url.spec.whatwg.org/를 확인하여 최신 URL 규격의
진전을 파악하는 것이 좋습니다.
참고로, 웹 브라우저와 HTML 외부 소프트웨어 스택에서 URL 처리 방식에는 중요한 차이가 있을 수 있습니다.
기존 웹 콘텐츠를 깨뜨리는 URL 처리 변경은 허용되지 않지만, URL 처리의 일부는 구현 정의로 간주되어야 합니다(예: file: URL
파싱이나 [RFC3986] 및 [RFC3987] 규칙상 구문 오류가 될 URL 처리 등).
1.1 Social Web 워킹 그룹
이 절은 비규범적입니다.
Webmention은 Social Web 워킹 그룹에서 작성 중인 여러 관련 명세들 중 하나입니다. 대체 접근 방식이나 보완 프로토콜에 관심 있는 구현자는 개요 문서[social-web-protocols]를 먼저 읽어보는 것이 좋습니다.