摘要：對于通過去下載文件時跨域的問題有一個解決思路是自己寫一個代理服務代理服務負責在服務端下載文件并配置好跨域相關的信息然后請求走代理服務進行下載。

文件下載是web應用中很常見的場景，在瀏覽器中下載文件, 最基本的方式就是——在頁面內隱藏iframe, 然后將文件下載地址加載到iframe中, 從而觸發瀏覽器的下載行為。 此外, html5引入a標簽的download屬性, 也是一種下載方式。

下載

下面針對下載地址的Response Header、瀏覽器兼容性, 以及一些特殊case, 做一些說明。

能觸發瀏覽器下載的url有兩類:

response header中指定了Content-Disposition為attachment，它表示讓瀏覽器把響應體作為附件下載到本地 (一般Content-Disposition還會指定filename, 下載的文件默認就是filename指定的名字)

response header中指定了Content-Type 為 application/octet-stream(無類型) 或者 application/zip(下載zip包時)以及其它幾個不常見類型 (其中還有瀏覽器差異)，其中 application/octet-stream表示http response為二進制流(沒指定明確的type), 需要下載到本地, 由系統決定或者用戶手動指定打開方式。

關于application/octet-stream的情況, 補充幾點

這種response, 由于沒有明確的type, 如果作為文件下載的話, 下載下來的文件將沒有文件名和拓展名(文件名直接取的url path的最后一坨)

如果不作為文件下載, 比如已知response body是一張圖片, 可以通過img標簽來顯示圖片

下載下來的內容, 只是缺少文件拓展名而已, 文件內容是完整的, 如果知道它實際的拓展名, 手動改了就能通過系統默認的程序打開, 不改拓展名的話也能通過指定應用程序的方式打開

關于response header的Content-Type, 補充幾點

首先要明確, Content-Type只是HTTP協議的部分, 不影響response body自身

Content-Type影響的是response的接收方(一般是瀏覽器), 對于瀏覽器而言, 它影響的是瀏覽器對響應體的處理方式. 比如指定為application/zip, 瀏覽器就會用pdf閱讀器打開.

Content-Type之于瀏覽器, 就好比文件擴展名之于操作系統, 影響的默認行為, 如果你指定了打開方式, 那么Content-Type就不起作用了. 比如, 你在服務端對圖片地址設置Content-Type為application/zip，但你在瀏覽器使用img標簽(相當于指定了打開方式)去加載, 照樣能正常加載圖片。

為什么上面說的「Content-Type」還有「文件拓展名」對于文件自身沒有影響?
這里涉及到「文件格式協議」/「文件頭」等內容, 待補充...