첨부파일 강제 다운로드
web | 2010-03-11
웹브라우저는 등록된 형식의 파일을 직접 다룰 수 있는 기능이 있습니다. 예를 들어서 텍스트 파일이나 png 이미지 파일을 브라우저에서 열면 브라우저로 바로 내용을 확인할 수 있습니다. 플래시나 pdf 파일도 적절한 플러그인이 브라우저와 연결이 되어 있다면 플러그인을 브라우저에서 직접 구동하여 내용을 볼 수 있습니다. 브라우저가 파일을 요청할 때 서버는 파일의 형식에 따라 마임타입(mime-type) 정보를 함께 보내주고 이 마임타입에 따라서 브라우저가 파일을 어떻게 처리할지를 결정해서 처리하게 됩니다.
웹사이트의 첨부파일 게시판을 만들 때 파일을 무조건 다운로드 받게 만드는 경우가 많습니다. 파일의 형식을 웹서버에서 지정해주는대로 사용하지 않고 download.asp와 같이 중간에 처리를 한번 더 거쳐서 마임타입을 application/octet-stream으로 바꿔 줍니다. 그러면 브라우저는 이 파일을 어떻게 처리해야 할지 모르기 때문에 파일을 다운로드 받게 합니다. 다운로드 받은 파일은 사용자의 운영체제에서 처리를 결정하게 됩니다.
여기서 생각해볼 점이 있습니다. 무조건 파일을 다운로드 받게 하는 것이 과연 사용자를 위한 기능인가 하는 점입니다. 이렇게 다운로드 처리를 하지 않은 경우에도 파일을 다운로드 받고 싶다면 브라우저의 기능(Save link content as...)을 사용하면 되지만 파일을 브라우저에서 보고싶은 사용자는 방법이 없습니다. 사실 어느쪽이 더 사용자에게 좋다고 단정하기는 힘들고 보통은 사용자가 가지고 있는 기존 경험에 따라서 다를 것입니다. 하지만 사용자에게 선택권을 주지 않았다는 측면에서는 좋은 방법이라고 보기 힘듭니다.
또한 이 방법은 웹서버의 파일을 중간에 한번 거쳐서 다운로드 하기 때문에 웹서버의 보안이 미치지 못하는 부분에서 보안상 결함이 있을 수 있습니다. 완벽하게 추상화하지 않고 파일의 경로를 사용하게 되면 서버에 있는 임의의 파일을 다운로드 할 수 있게 됩니다. 그래서 부적절한 접근을 막는 처리를 해야 하는데 실수로라도 이에대한 처리를 빠트리면 보안구멍이 생기는 것입니다.
과연 이 기능이 정말 사용자를 위한 것인지 아니면 단지 웹사이트 담당자의 주관적인 사용자 경험을 위한 것인지 한번 고민해볼 필요가 있습니다.
Comments
제 기억에 수년전 제로보드 4에서 download.php 란게 생긴 이유가 다운로드 카운팅을 위해서였던 것 같고, htaccess 를 쓰지 않은채로 외부링크를 차단하기 위해서였던 것 같은데, 카운팅이 필요없다면 직접링크도 나쁘지 않을 듯 합니다. 다만 저 두가지 기능을 함께 얻고싶을때의 대안도 마련해주어야 할 것 같아요. 다운로드 클릭과 함께 ajax로 뭘 쏘는건 완결성이 부족하고;
문제는 download.php같은 프로그램이 mime type을 application/octet-stream로 강제로 바꾼다는데 있는 것 같에요. 확장자 기반으로 mine type 스니핑을 한 후 그에 걸맞는 mime type만 header에 적어주면 문제가 없지요. 제가 보기엔 귀차니즘 같다는...
거기에 더불어 파일이름도 좀 제대로 넣어줬으면 좋겠어요. 숫자나 임의로 생성한 alphanumeric 문자열로 파일명을 주는 경우 참 맘에 안 듭니다. 한글 파일명도 올바로 처리하는 건 제가 자료 조사 후 직접 구현해봤고 주요 브라우저에서 모두 동작합니다. http://code.google.com/p/cciu-open-course-labs/source/browse/opencourselabs/utils/__init__.py#71
포탈 블로그 쪽은 관리 옵션에서 '마우스 오른쪽 버튼 금지 설정' 이란 항목이 존재해서, 이를 사용해 오른쪽 클릭을 제한하고 있는 경우가 상당수입니다. 설치형 블로그 역시 '마우스 오른쪽 클릭 방지' 플러그 인등을 사용하는 사람이 많고요. 즉, 'Save link content as...' 자체를 이용하지 못하는 경우가 다반사죠. 이런 경우 사용자는 다운로드를 하고 싶은데 클릭 외에 다른 방법은 없고, 클릭시 mime type 때문에 원치 않았던 프로그램이 실행되고 하는 경우가 있습니다. 제 생각에는 결국 선택권이 없는 상황이 될 것이라면, 무조건 다운로드가 되는 편이 나은 것 같습니다. 물론, 'Save link content as...' 에 대한 선택권이 있다면 말씀하신 것 처럼 처리하는 것이 좋을 것 같습니다.
오른쪽 클릭 선택권을 안줬기 때문에 파일 여는 선택권도 박탈해야 한다는 논리는 너무 제공자 측면인 것 같은데요.
모든 사항을 고려해볼 필요는있지만 무엇이 더 좋다고 판단할수 없는 주제같네요. 제가 초보 사용자라면 파일을 간직하고 싶은데 브라우저에서 열려버리면 사용법이 익숙하지 못하면 파일로 간직할수 없다고 불평할거 같아요.
'첨부파일 다운로드' 라는 제목 하에 제공되는 첨부파일은... 사용자가 다운로드하려는 의도가 강할텐데.. 이런 경우에는 바로 다운로드되게 하는 편이 나을거같네요. 사용자의 선택이 언제나 best라고는 생각지 않습니다. 상황과 배경, 방법 등이 고려가 되어야 사용성, 편의성이 향상될 거라고 보이는데요.... 오히려 다운로드한 이후에 브라우저를 이용하든 하게 만드는 편이 낫지 않나요.. 브라우저에서 해당 파일을 열려고 하더라도 그 파일을 로컬에 다운받아야 열 수 있는건 마찬가진데~
저의 경우는 ColdFusion으로 주로 개발하다보니 CF쪽 이야기를 하자면 브라우저마다 mime타입을 달리 먹는것에 혼란을 겪었습니다. CF만의 문제인지는 모르겠으나, 구글의 지메을의 경우도 hwp와 같은 파일(예를 들어 한글명.hwp와 같은)은 오페라에서 정상적으로 다운로드가 안되는 현상이 있습니다. 헤더를 동일하게 주어도 브라우저마다 다르게 다운로드되거나 특히 한글파일명의 경우 정말 화딱지 난 경우도 많았습니다. 단순 링크의 경우 문제가 없지만 download.cfm과 같은 중간처리파일에서 헤더를 추가해서 다운로드하는 경우는 브라우저마다 처리를 다르게 주거나하는 테스트가 필요해 보입니다. 하지만 장점도 있지요. 저의 실제 개발 경험상 가령 어떤 파일들은 유료로 판매중인 파일인데, 웹루투가 아닌 서버의 특정 공간에 파일을 저장하고 다운로드시에만 임시로 다운로드할 수 있도록 할 수 있었는데 이런경우 파일경로가 절대 유출되지 않는다는 장점이 있습니다.(해킹하지 않는한..ㅋ) 실제파일명과 다르게 다운로드시의 파일명을 동적으로 지정해버려 유추가 사실상 불가능하게 말이죠..ㅋ 일장일단이 있는듯합니다. ^^
옛날 글이지만 글을 남깁니다. 베가에서는 download as라는게 되어서 당연히 갤럭시s3에서 되는줄 알았습니다. 하지만 갤럭시 s3의 내장 인터넷브라우저는 그게 없더군요. 무조건 스트리밍 재생만 되고 강제 다운로드가 불가능하더군요. 저에게는 좋은 공부가 되었습니다.