[RFC 6266] Content-Disposition in HTTP

전에 '파일 다운로드 구현시 파일명 지정'라는 글을 쓴적이 있다.

HTTP GET으로 받는 파일이 해당 URL과 다른 경우 HTTP 응답 헤더에 Content-Disposition 이름의 헤더를 지정하여 원하는 파일명으로 저장을 할 수 있게 하는 내용이었다.

문제는 그 방법이 IE와 Chrome에서는 동작을 했으나, 파이어폭스에서는 URL 인코딩 된 파일로 되어 버리는 현상이 있었다.

예) HTTP Response는 아래와 공통.

하지만 저장된 파일명은 달랐다.

크롬 41.0.2272.76 m

파이어 폭스 36.0.1

우선 관련문서를 보자.

RFC 6266 (Content-Disposition in HTTP)에 1절에 나와있듯이,

HTTP/1.1 Standard (Section 15.5)에는

Content-Disposition는 HTTP 표준의 일부가 아니다. 하지만 널리 구현되어 있는 점을 통해 볼 때, 우리는 구현자에게 사용법 미 위험성을 문서화 한다.

라고 나와 있다고 한다.

 4.2절 (Disposition Type)에서 다음과 같이 되어 있다.

If the disposition[각주:1] type matches "attachment" (case-insensitively), this indicates that the recipient should prompt the user to save the response locally, rather than process it normally (as per its media type).
만약 디스포지션 타입이 "attachement" (대소문자 무시)와 일치할 경우에, 이것은 수신자(보통 웹브라우저)는 로컬 응답을 (미디어 타입이 지정하는 것에 따라) 저장하기 보다 국부적으로(locally) 사용자가 이를 처리하도록 띄워줘야 함을 나타낸다.

On the other hand, if it matches "inline" (case-insensitively), this implies default processing.  Therefore, the disposition type "inline" is only useful when it is augmented with additional parameters, such as the filename (see below).
반면에, "inline" (대소문자 무시)와 일치할 경우, 기본적인 처리로 할 것을 내포한다. 그 결과, 디스포지션 타입이 "inline"의 경우 filename 같은 추가적인 파라메터들이 나오는 경우에만 유용할 것이다.

Unknown or unhandled disposition types SHOULD be handled by recipients the same way as "attachment" (see also [RFC2183], Section 2.8).
알 수 없는 혹은 처리되지 않은 디스포지션 타입들은 "attachment"와 같은 방식으로 수신자에의해 처리되어야 한다. (RFC2183의 2.8절 참고)

여기까지는 일반적인 내용이고, 인코딩에 대해서는 5절 Examples에 나와 있다.

Direct the UA to show "save as" dialog, with a filename containing
   the Unicode character U+20AC (EURO SIGN):

     Content-Disposition: attachment;
                          filename*= UTF-8''%e2%82%ac%20rates

즉, URL인코딩을 사용하려면 앞에 filename*= UTF-8'' 같은 문장을 필요로 한다.

문제는 IE8에서 테스트 해보니 filename*을 인식하지 못하는 문제가 있었다.

결국은 병기를 해야한다는 것이 결론이다. User-Agent 같은 헤더로 브라우저 탐침할 이유가 전혀 없었다.

1. displosition: 기질, 성향, 배치 등의 사전적인 의미를 가진다. [본문으로]