# 비이미지 미디어 파일 다운로드 불가, S3 업로드 시 원본 파일명 유실

**URL:** https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797
**Category:** Bug
**Created:** [5월 26, 2020, 5:00오후 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797 "2020-05-26T17:00:48Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![md-misko](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/md-misko/32/126315_2.png) [@md-misko](https://meta.discourse.org/u/md-misko)
#### Post date: [5월 28, 2020, 8:43오전 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/7 "2020-05-28T08:43:11Z")

</div>

> [@martin](#):
>
> 다시 살펴보니, 해결책은 반대 방향이어야 한다고 생각합니다. `uploads:migrate_to_s3` 작업은 `if !FileHelper.is_supported_media?(name)` 조건을 사용해야 합니다. 비디오와 오디오에 `content-disposition: attachment; filename=X` 헤더를 설정하는 것은 의미가 없습니다.

믿어주세요, 저는 이 문제를 해결하기 위해 며칠을 보냈고, 처음에는 저도 이상하게 생각했습니다. 하지만 `content-disposition: attachment; filename=X`를 이미지 _외의_ 모든 미디어 파일에 설정하는 것이 현재 \_로컬 저장소\_에서 미디어 파일이 서빙되는 방식을 완벽하게 \_모방\_합니다.

> [@martin](#):
>
> 그 파일들을 Discourse 게시물 내에서 스트리밍하는 것이지, 다운로드하는 것이 아니죠?

간단히 말하면, 아닙니다! 필요하면 원복싱(oneboxing)을 사용하여 스트리밍할 수 있지만, 로컬 또는 S3 경로인 `[media_file](path_to_media_file)`의 직접 다운로드 링크는 로컬 저장소에서와 마찬가지로(그리고 S3로 _이관된_ 파일의 경우에도) \_원본 파일명\_을 사용하여 파일을 \_다운로드\_해야 합니다.

하지만 갑자기 S3로 직접 업로드한 파일의 경우 이것이 불가능해졌습니다: `[media_file](S3_path_to_media_file)` 링크는 새 탭에서 미디어 파일을 스트리밍합니다(원복싱이 수행하는 것이므로 불필요합니다). 또한 미디어 플레이어 컨트롤에서 다운로드를 시도해도 원본 파일명을 잃어버립니다.

로컬 호스팅 파일과 S3 호스팅 파일은 동일한 방식으로 동작해야 한다고 기대하는 것이 맞지 않나요? 동의하시죠? 당신의 제안대로라면 S3 호스팅 업로드의 경우, 새 파일뿐만 아니라 이관된 파일에 대해서도 기능이 완전히 반대로 작동하게 됩니다.

> [@martin](#):
>
> 제가 무언가를 놓치고 있다면, 추가 정보나 예시를 자유롭게 추가해 주세요.

자세한 사례 파일과 왜 제 제안이 올바른지(즉, 로컬과 S3 모두에 호스팅된 업로드에 대해 동일한 기능을 유지하는지)에 대한 설명을 드립니다:

### 로컬에 호스팅된 파일

저는 1~10MB 크기의 음성 파일 5,000개 이상의 저장소를 가지고 있으며, 총 용량은 약 40GB입니다. 현재 이 파일들은 로컬 저장소에 호스팅되어 있으며, 이제 S3로 이전되고 있습니다(이것은 의도된 것이며, 제 3자 서비스에 호스팅하는 것을 원하지 않습니다). 성능 측면에서는 이미 상당히 잘 작동하고 있지만, 저장 비용 상승과 S3와 CDN 사용 옵션 때문에 S3로 이관하는 것이 합리적입니다.

이 파일들은 \_크기\_에 최적화되어 있으며 스트리밍을 위한 것이 아니라, 로컬에서 다운로드하여 듣기 위한 것입니다(대역폭/연결성이 제한된 클라이언트를 위해). 파일들은 일괄 업로드된 후, 각 SHA1 값으로 생성된 링크를 사용하여 원시 게시물에서 참조됩니다: `[dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3)`이며, 파일의 직접 링크를 클릭하여 _원본_ 파일명으로 다운로드할 수 있습니다(예시 [여기](https://discourse.suttacentral.net/t/bhante-sujato-metta-meditation-retreat-2019/15951) 참조).

반면, 이 링크들이 \_원복싱\_된다면 여전히 Discourse 서버에서 직접 스트리밍할 수 있으며(플레이어 컨트롤에서 다시 원본 파일명으로 다운로드도 가능합니다).

### S3로 이관된 파일

`uploads:migrate_to_s3`를 사용하여 업로드를 로컬 저장소에서 S3로 이관하면 두 가지 일이 발생합니다:

- 이미지 _외의_ 모든 업로드에 `content-disposition: attachment; filename=X`가 설정됩니다.
- 원시 게시물 내의 직접 로컬 링크 `[dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3)`가 S3 링크 `[dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)`로 대체됩니다.

이는 원복싱을 포함하여 원본 파일명을 가진 다운로드 링크까지 로컬 호스팅 업로드의 모든 측면을 모방합니다.

### S3로 새로 업로드된 파일

- 모든 미디어 파일에 `content-disposition: attachment; filename=X`가 **설정되지 않습니다**
- 새로 업로드된 파일은 원시(raw)에서 short-url을 사용하여 참조되지만, cooked 링크는 여전히 `https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3`로 직접 가리킵니다.
- short-url 링크나 수동으로 삽입된 S3 링크 `[dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)`를 클릭하면 파일이 다운로드되지 않고 새 탭에서 열립니다.

`content-disposition`이 설정되지 않기 때문에, 이제 미디어 파일이 로컬 저장소에서 서빙되는 방식과 다릅니다(원복싱은 여전히 작동하지만, 원본 파일명을 가진 다운로드 링크는 더 이상 사용할 수 없습니다).

추가 정보가 필요하시다면 알려주세요.

---

_[View the full topic](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797)._