하이퍼텍스트 전송 프로토콜 (HTTP)에서의 Content-Disposition 헤더 필드 사용

다음은 [RFC2616]에서 정의된 항목입니다:

  token         = <token, defined in [RFC2616], Section 2.2>
  quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
  value         = <value, defined in [RFC2616], Section 3.6>
                ; token | quoted-string
              

[RFC5987]에서 정의된 항목:

  ext-value   = <ext-value, defined in [RFC5987], Section 3.2>

동일한 매개변수 이름이 여러 번 나타나는 Content-Disposition 헤더 필드 값은 무효입니다.

또한 암시된 선형 공백 규칙(Section 2.1 of [RFC2616]) 때문에 단어(token 또는 quoted-string)와 구분자 사이에 선택적 공백이 올 수 있습니다.

또한 ext-value에 사용되는 형식은 자연어(e.g., "en")를 지정할 수 있게 하지만, 파일 이름에는 제한적으로만 유용하며 수신자에게 무시될 가능성이 높습니다.

처리 유형이 "attachment"(대소문자 구분 없이)와 일치하면, 이는 수신자가 응답을 정상적으로 처리하는 대신(미디어 타입에 따른 처리) 로컬에 저장하도록 사용자에게 저장 프롬프트를 표시해야 함을 나타냅니다.

반면에 "inline"(대소문자 구분 없이)과 일치하면 이는 기본 처리를 의미합니다. 따라서 "inline" 처리 유형은 파일 이름과 같은 추가 매개변수가 첨가될 때에만 유용합니다(아래 참조).

알려지지 않았거나 처리되지 않는 처리 유형은 수신자가 "attachment"와 같은 방식으로 처리해야 합니다([RFC2183], Section 2.8 참조).

"filename" 및 "filename*" 매개변수(대소문자 구분 없이 일치)는 메시지 페이로드를 저장하기 위한 파일 이름을 구성하는 방법에 대한 정보를 제공합니다.

처리 유형에 따라 이 정보는 즉시 사용될 수 있습니다(예: "attachment"로 인해 발생하는 "다른 이름으로 저장..." 상호작용) 또는 나중에 사용될 수 있습니다(예: 사용자가 현재 표시 중인 페이지 내용을 저장하기로 결정할 때).

"filename"과 "filename*"의 차이는 "filename*"이 [RFC5987]에 정의된 인코딩을 사용하여 ISO-8859-1 문자 집합에 없는 문자를 사용할 수 있게 해준다는 점입니다.

이 명세서 이전의 많은 사용자 에이전트 구현은 "filename*"을 이해하지 못합니다. 따라서 하나의 헤더 필드 값에 "filename"과 "filename*"이 모두 포함된 경우, 수신자는 가능하면 "filename*"을 선택하고 "filename"은 무시해야 합니다. 이렇게 하면 송신자는 더 표현력이 높은 "filename*" 매개변수와 레거시 수신자를 위한 대체용 "filename" 매개변수를 동시에 전송하여 특정 사용자 에이전트를 특수 처리하는 일을 피할 수 있습니다(예시는 섹션 5 참조).

수신자는 지정된 파일 이름을 권고적(advisory)으로만 취급해야 하며, 원하는 정보를 추출할 때 매우 주의해야 합니다. 특히 다음을 준수해야 합니다:

• 수신자는 시스템의 허가된 위치 이외의 어떤 위치에도 쓰기할 수 없어야 합니다. 예를 들어 "/etc/passwd"와 같은 잘 알려진 시스템 위치를 덮어쓸 수 있는 문제를 고려하십시오. 이를 위해 파일 이름의 폴더 정보는 신뢰하지 말고 마지막 경로 세그먼트만 남겨 실제 파일명만 사용하는 전략(경로 구분자 "\"와 "/"로 구분되는 '경로 세그먼트' 기준)이 권장됩니다.

• 많은 플랫폼은 파일 시스템에서 타입 정보를 위해 Internet Media Types([RFC2046])을 사용하지 않고 파일 확장자에 의존합니다. 서버가 제공한 파일 확장자를 그대로 신뢰하면 저장된 파일을 나중에 열 때 권한 상승(privilege escalation)을 초래할 수 있으므로(예: ".exe"), 파일 확장자를 통해 미디어 타입을 결정하는 수신자는 수신된 페이로드의 미디어 타입과 안전하게 일치하는 확장자를 사용해야 합니다.

• 수신자는 제어 문자나 선행/후행 공백과 같이 UI나 파일 이름에서 혼란을 일으키는 문자 시퀀스를 제거하거나 대체해야 합니다.

• "." 및 "..", "~", "|", 그리고 장치 이름 등 파일 시스템이나 셸 명령에서 특별한 의미를 갖는 이름은 무시하거나 대체하는 것이 권장됩니다.

미래의 확장을 가능하게 하기 위해, 수신자는 인식하지 못하는 매개변수를 무시해야 합니다([RFC2183], Section 2.8 참조).

RFC 2183 섹션 9은 disposition 유형과 disposition 매개변수에 대한 IANA 레지스트리를 정의합니다. 이 레지스트리는 MIME과 HTTP와 같이 Content-Disposition을 사용하는 여러 프로토콜에서 공유됩니다. 따라서 등록된 모든 값이 HTTP 문맥에서 의미가 있는 것은 아닐 수 있습니다.

이 명세서는 RFC 2183 섹션 9에 정의된 disposition 값 및 매개변수 등록 절차에 대한 변경을 도입하지 않습니다.

이 문서는 Content-Disposition HTTP 헤더 필드의 정의를 영구 HTTP 헤더 필드 레지스트리(참조 [RFC3864])에 업데이트합니다.

Header field name:

Content-Disposition

Applicable protocol:

http

Status:

standard

Author/Change controller:

IETF

Specification document:

this specification (섹션 4)

Related information:

none

10.1. 규범적 참고문헌

[ISO-8859-1]

International Organization for Standardization, “Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1”, ISO/IEC 8859-1:1998, 1998.

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2616]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.

[RFC5987]

Reschke, J., “Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters”, RFC 5987, August 2010.

10.2. 비규범적 참고문헌

[RFC2046]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, November 1996.

[RFC2047]

Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text”, RFC 2047, November 1996.

[RFC2183]

Troost, R., Dorner, S., and K. Moore, Ed., “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field”, RFC 2183, August 1997.

[RFC2231]

Freed, N. and K. Moore, “MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations”, RFC 2231, November 1997.

[RFC2388]

Masinter, L., “Returning Values from Forms: multipart/form-data”, RFC 2388, August 1998.

[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.

[US-ASCII]

American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange”, ANSI X3.4, 1986.

'encoded-word'는 'quoted-string' 내에 나타나서는 안 됩니다.

...

'encoded-word'는 MIME Content-Type 또는 Content-Disposition 필드의 매개변수에 사용되어서는 안 되며, 'comment' 또는 'phrase' 내를 제외한 어떤 구조체화된 필드 본문에서도 사용되어서는 안 됩니다.

실제로 일부 사용자 에이전트는 이 인코딩을 구현하고, 일부는 구현하지 않으며(인코딩된 문자열을 사용자에게 노출), 일부는 혼란을 겪습니다.

일부 사용자 에이전트는 percent-encoded([RFC3986], Section 2.1) 시퀀스를 받아들입니다. 디코딩에 사용되는 문자 인코딩은 참조 페이지의 인코딩, 사용자 에이전트의 로케일 및 구성, 그리고 매개변수 값 자체에 따라 달라집니다.

실제로 이는 사용하기 어렵습니다. 이를 지원하지 않는 사용자 에이전트는 이스케이프된 문자 시퀀스를 사용자에게 그대로 표시할 것이고, 지원하는 사용자 에이전트들 사이에서도 어떤 문자 인코딩을 기대하는지 예측하기 어렵습니다.

일부 사용자 에이전트는 기본적으로 quoted-string 형식의 값이 ISO-8859-1로 간주되는 것을 검사하고, UTF-8이 더 올바른 해석일 가능성이 높으면 UTF-8로 전환합니다.

위 접근법들처럼 이는 상호운용성이 없고, 실제 값을 잘못 해석할 위험이 있습니다.