인터넷 엔지니어링 태스크 포스 (IETF) M. Nottingham
Request for Comments: 8288 2017년 9월
Obsoletes: 5988
Category: Standards Track
ISSN: 2070-1721

웹 링크

초록

이 명세서는 웹 상의 리소스들 간의 관계("링크")와 그 관계의 유형("링크 관계 타입")에 대한 모델을 정의합니다.

또한 이러한 링크를 Link 헤더 필드를 사용해 HTTP 헤더에 직렬화하는 방법을 정의합니다.

이 메모의 상태

이 문서는 인터넷 표준 트랙 문서입니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물입니다. 이는 IETF 커뮤니티의 합의를 반영합니다. 공개 검토를 거쳤으며 인터넷 엔지니어링 스티어링 그룹(IESG)에 의해 발행 승인을 받았습니다. 인터넷 표준에 관한 추가 정보는 RFC 7841의 섹션 2를 참조하십시오.

이 문서의 현재 상태, 정오표, 피드백 제공 방법에 관한 정보는 https://www.rfc-editor.org/info/rfc8288에서 확인할 수 있습니다.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

1. 소개

이 명세서는 웹 상의 리소스들 간의 관계("링크")와 그 관계의 유형("링크 관계 타입")에 대한 모델을 정의합니다.

HTML [W3C.REC-html5-20141028] 및 Atom [RFC4287]은 모두 잘 정의된 링크 개념을 가지고 있습니다. 섹션 2는 이러한 형식과 (잠재적으로) 다른 곳에서의 링크를 포괄하는 프레임워크로 이를 일반화합니다.

또한, 섹션 3은 이러한 링크를 전달하기 위한 HTTP 헤더 필드를 정의합니다.

1.1. 표기 규약

이 문서에서 대문자로만 나타나는 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 BCP 14 [RFC2119] 및 [RFC8174]에서 설명된 대로 해석됩니다.

이 문서는 Augmented Backus-Naur Form(ABNF) [RFC5234] 표기와 [RFC7230]에서 사용하는 #rule을 포함하여, quoted-string, token, SP, BWS, OWS, RWS, LOALPHA, DIGIT 규칙을 명시적으로 포함합니다.

추가로 다음 규칙들이 포함됩니다:

  • URI 및 URI-Reference (RFC3986에서)
  • type-name 및 subtype-name (RFC6838에서)
  • media-query-list (W3C Media Queries에서)
  • Language-Tag (RFC5646에서)

1.2. 적합성 및 오류 처리

적합성과 오류 처리에 관한 요구사항은 [RFC7230]의 섹션 2.5에 강조된 사항이 본 문서에도 적용됩니다.

4. IANA 고려사항

5. 보안 고려사항

Link 헤더 필드의 내용은 보안, 프라이버시 또는 무결성이 보장되지 않습니다. 이러한 속성을 제공하는 현재 유일한 종단 간 방법은 HTTP에 대한 전송 계층 보안(TLS)을 사용하는 것입니다 (RFC2818 참조).

링크 애플리케이션은 HTTP 헤더 필드에서 수집된 링크를 자동으로 따라가거나 신뢰하거나 사용하는 경우 열릴 수 있는 공격 벡터를 고려해야 합니다.

예를 들어, anchor 파라미터를 사용하여 링크 컨텍스트를 다른 리소스와 연결하는 Link 헤더 필드는 제3자의 주장으로 인해 부정확하거나 악의적일 수 있으므로 신뢰할 수 없습니다. 애플리케이션은 이러한 링크를 폐기하도록 지정하거나(예: 리소스 간에 동일한 권한(authority)이 있음이 확립된 경우에만 허용) 위험을 완화할 수 있습니다.

링크를 역참조하는 것은 사용 중인 애플리케이션에 따라 여러 위험을 수반합니다. 예를 들어 Referer 헤더(RFC7231 참조)는 애플리케이션 상태(민감한 정보 포함)에 대한 정보를 노출할 수 있습니다. 마찬가지로 쿠키(RFC6265 참조)도 공격 벡터가 될 수 있습니다. 애플리케이션은 이러한 메커니즘이 어떻게 동작해야 하는지 신중히 규정하여 위험을 완화할 수 있습니다.

Link 헤더 필드는 IRI와 URI를 광범위하게 사용합니다. IRI 관련 보안 고려사항은 RFC3987 섹션 8을, URI 관련 보안 고려사항은 RFC3986 섹션 7을, HTTP 헤더 필드 관련 보안 고려사항은 RFC7230 섹션 9를 참조하십시오.

6. 국제화 고려사항

링크 대상은 IRI를 지원하지 않는 직렬화에서 표현하기 위해 URI로 변환되어야 할 수 있습니다. 이는 Link HTTP 헤더 필드를 포함합니다.

유사하게, Link 헤더 필드의 anchor 파라미터는 IRI를 지원하지 않으므로 포함하기 전에 IRI를 URI로 변환해야 합니다.

관계 타입은 비교를 용이하게 하기 위해 URI로 정의됩니다. 이들은 최종 사용자에게 표시될 것으로 기대되지 않습니다.

등록된 관계 이름은 소문자 ASCII 문자여야 한다는 점에 유의하십시오.

7. 참고문헌

7.1. 규범적 참고문헌

[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC3864]
Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.
[RFC3987]
Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs)”, RFC 3987, January 2005.
[RFC5234]
Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, January 2008.
[RFC5646]
Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages”, BCP 47, RFC 5646, September 2009.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 6838, January 2013.
[RFC7230]
Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, June 2014.
[RFC7231]
Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, June 2014.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, June 2017.
[RFC8174]
Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017.
[RFC8187]
Reschke, J., “Indicating Character Encoding and Language for HTTP Header Field Parameters”, RFC 8187, September 2017.
[W3C.REC-css3-mediaqueries-20120619]
Rivoal, F., “Media Queries”, W3C Recommendation, June 2012.

7.2. 비규범적 참고문헌

[RFC2046]
Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, November 1996.
[RFC2818]
Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.
[RFC4287]
Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format”, RFC 4287, December 2005.
[RFC6265]
Barth, A., “HTTP State Management Mechanism”, RFC 6265, April 2011.
[W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., et al., “HTML5”, W3C Recommendation, October 2014.

부록 B. Link 헤더 필드 파싱 알고리즘

이 부록은 헤더 집합에서 Link 헤더를 추출하는 알고리즘, Link 헤더 필드 값을 파싱하는 알고리즘, 및 필드 값의 일반 부분을 파싱하는 알고리즘을 제시하는 비규범적 알고리즘 집합을 개괄합니다.

이 알고리즘들은 ABNF가 제시하는 문법보다 더 관대합니다; 여기에 포함된 오류 처리는 합리적인 접근법이지만 필수적인 것은 아닙니다. 따라서 이들은 권고적이며, 불일치가 있는 경우에는 본 명세서 본문에 정의된 동작이 올바른 동작입니다.

B.1. 헤더 집합에서 링크 파싱

이 알고리즘은 HTTP 헤더 집합에 포함된 Link 헤더 필드를 파싱하는 데 사용됩니다. (field_name, field_value) 쌍의 header_set이 주어지면(ASCII 인코딩 가정), 링크 객체 목록을 반환합니다.

  1. field_values를 field_name이 대소문자 구분 없이 "link"와 일치하는 header_set의 멤버들로 구성된 리스트로 둡니다.
  2. links를 빈 리스트로 둡니다.
  3. 각 field_value에 대해:
    1. field_value에서 링크 필드 값 파싱(부록 B.2)의 결과를 value_links로 둡니다.
    2. value_links의 각 멤버를 links에 추가합니다.
  4. links를 반환합니다.

B.2. 링크 필드 값 파싱

이 알고리즘은 Link 헤더 필드에서 쉼표로 구분된 0개 이상의 link-value를 파싱합니다. ASCII 문자열 field_value가 주어지면 링크 객체 목록을 반환합니다.

  1. links를 빈 리스트로 둡니다.
  2. field_value에 내용이 있는 동안:
    1. 선행 OWS를 소비합니다.
    2. 첫 문자가 "<"가 아니면 links를 반환합니다.
    3. 첫 문자인 "<"를 버립니다.
    4. 첫 ">" 문자 또는 field_value의 끝까지를 소비하고 그 결과를 target_string으로 둡니다.
    5. 다음 문자가 ">"가 아니면 links를 반환합니다.
    6. 선행 ">" 문자를 버립니다.
    7. link_parameters를 파싱 파라미터(부록 B.3)의 결과로 둡니다(0개 이상의 문자 소비).
    8. target_uri를 target_string을 상대적으로 해석한 결과로 둡니다(RFC3986 섹션 5.2). 본문에 있는 기준 URI는 사용되지 않습니다.
    9. relations_string을 link_parameters에서 첫 번째 튜플 whose first item matches "rel"의 두 번째 항목으로 하거나, 없으면 빈 문자열로 둡니다.
    10. relations_string을 RWS로 분할하여 relation_types 리스트로 만듭니다.
    11. context_string을 link_parameters에서 첫 번째 튜플 whose first item matches "anchor"의 두 번째 항목으로 둡니다. 없으면 컨텍스트 문자열은 Link 헤더를 갖는 표현의 URL(RFC7231 섹션 3.1.4.1)이며, URI로 직렬화됩니다. URL이 익명인 경우 context_string은 null입니다.
    12. context_uri를 context_string을 상대적으로 해석한 결과로 둡니다(RFC3986 섹션 5.2), 만약 context_string이 null이면 context는 null입니다. 본문 기준 URI는 사용되지 않습니다.
    13. target_attributes를 빈 리스트로 둡니다.
    14. link_parameters의 각 튜플(param_name, param_value)에 대해:
      1. param_name이 "rel" 또는 "anchor"와 일치하면 이 튜플을 건너뜁니다.
      2. param_name이 "media", "title", "title*" 또는 "type"이며 target_attributes가 이미 같은 param_name을 가진 튜플을 포함하면 이 튜플을 건너뜁니다.
      3. (param_name, param_value)를 target_attributes에 추가합니다.
    15. star_param_names를 link_parameters 중 param_name의 마지막 문자가 "*"인 param_name들의 집합으로 둡니다.
    16. 각 star_param_name에 대해:
      1. base_param_name을 star_param_name에서 마지막 문자를 제거한 값으로 둡니다.
      2. 만약 구현체가 base_param_name의 국제화된 형태를 지원하지 않기로 선택하면(금지 포함), link_parameters에서 star_param_name인 튜플들을 모두 제거하고 다음 star_param_name으로 건너뜁니다.
      3. link_parameters에서 base_param_name인 튜플들을 모두 제거합니다.
      4. link_parameters에서 star_param_name인 모든 튜플의 첫 번째 멤버를 base_param_name으로 변경합니다.
    17. 각 relation_type에 대해:
      1. relation_type을 소문자로 정규화합니다.
      2. target이 target_uri, 관계 타입이 relation_type, 컨텍스트가 context_uri, 대상 속성이 target_attributes인 링크 객체를 links에 추가합니다.
  3. links를 반환합니다.

B.3. 파라미터 파싱

이 알고리즘은 헤더 필드 값에서 파라미터를 파싱합니다. ASCII 문자열 input이 주어지면 포함된 (parameter_name, parameter_value) 튜플 목록을 반환합니다. input은 파싱된 파라미터를 제거하도록 수정됩니다.

  1. parameters를 빈 리스트로 둡니다.
  2. input에 내용이 있는 동안:
    1. 선행 OWS를 소비합니다.
    2. 첫 문자가 ";"가 아니면 parameters를 반환합니다.
    3. 선행 ";" 문자를 버립니다.
    4. 선행 OWS를 소비합니다.
    5. 첫 BWS, "=", ";" 또는 "," 문자 또는 입력의 끝까지를 소비하여 parameter_name으로 둡니다.
    6. 선행 BWS를 소비합니다.
    7. 다음 문자가 "="이면:
      1. 선행 "=" 문자를 버립니다.
      2. 선행 BWS를 소비합니다.
      3. 다음 문자가 DQUOTE이면 인용 문자열 파싱(부록 B.4)의 결과를 parameter_value로 둡니다(0개 이상의 문자 소비).
      4. 그렇지 않으면 첫 ";" 또는 "," 문자 전까지 또는 입력의 끝까지를 소비하여 parameter_value로 둡니다.
      5. parameter_name의 마지막 문자가 "*"이면 parameter_value를 RFC8187에 따라 디코딩합니다. 복구 불가능한 오류가 발생해도 처리를 계속합니다.
    8. 그렇지 않으면:
      1. parameter_value를 빈 문자열로 둡니다.
    9. parameter_name을 소문자로 정규화합니다.
    10. (parameter_name, parameter_value)를 parameters에 추가합니다.
    11. 선행 OWS를 소비합니다.
    12. 다음 문자가 ","이거나 입력의 끝이면 처리 중단하고 parameters를 반환합니다.

B.4. 인용 문자열 파싱

이 알고리즘은 RFC7230 섹션 3.2.6에 따라 인용 문자열을 파싱합니다. ASCII 문자열 input이 주어지면 언인쿼팅된 문자열을 반환합니다. input은 파싱된 문자열을 제거하도록 수정됩니다.

  1. output을 빈 문자열로 둡니다.
  2. input의 첫 문자가 DQUOTE가 아니면 output을 반환합니다.
  3. 첫 문자를 버립니다.
  4. input에 내용이 있는 동안:
    1. 첫 문자가 백슬래시("\")이면:
      1. 첫 문자를 버립니다.
      2. 더 이상 입력이 없으면 output을 반환합니다.
      3. 그렇지 않으면 첫 문자를 소비하고 output에 추가합니다.
    2. 그렇지 않고 첫 문자가 DQUOTE이면 그것을 버리고 output을 반환합니다.
    3. 그렇지 않으면 첫 문자를 소비하고 output에 추가합니다.
  5. output을 반환합니다.

부록 C. RFC 5988로부터의 변경사항

이 명세서는 이전 버전인 RFC 5988과 다음과 같은 차이점이 있습니다:

  • 초기 관계 타입 등록 항목은 RFC 5988에서 이미 등록되었으므로 제거되었습니다.
  • 소개가 축약되었습니다.
  • "Link Relation Application Data" 레지스트리가 제거되었습니다.
  • 정오표(errata)가 통합되었습니다.
  • 참조가 업데이트되었습니다.
  • 링크 기수성에 대한 설명이 명확해졌습니다.
  • 용어가 "target IRI" 및 "context IRI"에서 각각 "link target" 및 "link context"로 변경되었습니다.
  • 등록된 관계 타입에 URI를 할당하는 것은 직렬화별로 하도록 변경되었습니다.
  • Link 헤더 필드가 HTML 및 Atom 링크와 의미적으로 동등하다는 오해의 소지가 있는 진술이 제거되었습니다.
  • "link serialisations" 및 "link applications"의 정의와 사용이 보다 신중해졌습니다.
  • 대상 속성의 기수성(일반적 및 "type"에 대해)이 명확히 규정되었습니다.
  • Link 헤더 필드의 기본 링크 컨텍스트를 RFC 7231에 따라 표현의 식별성(identity)에 의존하도록 수정했습니다.
  • Link 헤더의 권장 파싱 알고리즘을 정의했습니다.
  • 대상 속성의 값 공간 및 정의가 지정되었습니다.
  • ABNF가 RFC7230과 호환되도록 업데이트되었습니다(특히 공백이 명시적임).
  • HTTP 헤더 필드의 일부 파라미터가 이제 token으로 나타날 수 있습니다.
  • HTTP 헤더의 파라미터가 이제 값이 없을 수 있습니다.
  • 인용 문자열 처리 방식이 RFC7230에 의해 정의되었습니다.
  • type 헤더 필드 파라미터는 이제 "/"를 허용하지 않는 token이므로 인용되어야 합니다.

저자 주소

Mark Nottingham
Email: mnot@mnot.net
URI: https://www.mnot.net/