카테고리 없음

HTTP 헤더 - Content-Disposition

신선아 2024. 1. 31. 00:24

이미지 A를 다운로드하는 링크를 구현하기 위해 아래와 같은 코드를 작성했다.

<a href="https://image.fre5h93.com/~~~" download >
	다운로드
</a>

이 링크를 클릭하면 분명 다운 될 줄 알았는데 나의 기대와 달리 창으로 띄워졌다.

혹시나 싶어 다른 이미지 B의 리소스의 url 로 변경하니 이번엔 다운로드가 잘 됐다.

분명 같은 환경 같은 코드이고, url만 달랐는데 왜 이런 현상이 일어났을까? 

 

HTTP 응답 헤더 - Content-Disposition 헤더

답은 Content-Disposition 헤더에 있었다.

Content-Disposition 헤더는 주로 HTTP 응답에서 사용되어 브라우저가 해당 컨텐츠를 어떻게 처리해야 할지를 표시한다.

Content-Disposition 헤더의 값이 attachment 인 이미지는 바로 다운로드가 되었다.
Content-Disposition 헤더가 없던 이미지는 다운로드가 되지 않고 브라우저에 표시되었다.

Content-Disposition 헤더의 기본 작동 방식

  • inline (기본값): 브라우저에서 파일을 직접 표시하려고 시도하게 된다.  이미지나 PDF 파일을 브라우저 창에서 직접 열 수 있다.
  • attachment: 브라우저에서 파일을 다운로드한다. filename 파라미터를 사용하여 다운로드되는 파일의 이름을 지정할 수 있다. (ex: attachment;filename="example.jpg").

 

 

AWS 콘솔에서 파일별 설정 확인하기

앞에서 확인했던 두 이미지를 요청했을때 응답으로 오는 Content-Disposition 헤더가 달랐다. 어디서 다르게 설정된 것일까? 파일이 저장된 S3 버킷을 찾아 확인해보았다. 

Metadata 부분을 확인해보니 다르게 설정 되어있는 것을 확인할 수 있었다.

추측으로는 서버에서 S3로 파일을 올리면서 메타데이터를 설정해주는 것 같다. (이건 S3에 업로드하는 코드를 추가로 살펴봐야겠다.

Metadata를 수정해 Content-Disposition 설정을 추가했을 때 요청하는 브라우저에서의 동작이 달라지는지 확인해보려 했었다.

그런데 변경 후 CloudFront 캐시를 invalidate를 해도 여전히 Content-Disposition  헤더가 응답 헤더로 오지 않았다.

찾아보니 ClouodFront에 Viewer response로 Lambda가 붙어있었고 Content-Disposition 헤더를 지우는 로직이 있었다. 왜 그런 로직이 추가되었는지는 모르겠지만 이유가 있을거라고 생각하고 다른 방법을 사용해서 다운로드 링크 이슈를 해결할 예정이다... 이런 로직이 추가된 이유도 여쭤볼 예정...

 

아무튼 Content-Disposition 헤더에 대해 알게 되었던 유익한 이슈였다...^^!

서버의 응답헤더를 수정할 수 없을 때 다운로드 링크를 구현할 코드를 완성하게 되면 아래 추가할 예정이다.