之前被雲存儲的URL大小寫問題糾結過一次，現在又被MIME type問題糾結。不想其他人再被糾結，所以在博客中一吐為快。
我們的文件上傳/下載（files.cnblogs.com）用的是又拍雲，最近有園友反饋他們之前上傳的Sliverlight文件（擴展名是.xap）在頁面中無法正常顯示。
我們測試發現，對於.xap文件的請求，又拍雲服務器端響應的Content-Type是application/octet-stream，正確的應該是application/x-silverlight-app，也就是說又拍雲服務器上沒有針對.xap擴展名定義對應的MIME type。之前我們用的是IIS，默認就定義了這個MIME type，所以沒遇到這個問題。見下圖：
即使沒有定義這個MIME type，在IIS中添加也很方便。我們想又拍雲在他們的服務器上增加這個設置應該也很方便，於是給他們發了郵件。收到的答復卻是無法全局設置MIME type，只能在調用又拍雲API上傳時由用戶一個一個文件指定MIME type，但是這些文件是我們之前通過FTP客戶端上傳的。也就是說在目前情況下，要解決這個問題我們只能寫代碼找出所有.xap文件，然后調用又拍雲API重新上傳這些文件，並且為這些文件指定MIME type。很是麻煩。
然后，我們去了解了一下阿里雲OSS（開放存儲服務），也沒解決這個問題，MIME type也需要在一個一個文件中指定。阿里雲OSS稍微好一點的地方就是可以直接調用API修改這些文件的MIME type，不用重新上傳。
又拍雲后來說以后考慮這樣解決這個問題，在用戶上傳時，如果發現上傳文件擴展名是.xap，就會自動加上MIME type。但是假如又出現一個不同的擴展名需要指定MIME type呢，難道還要重復一次我們的糾結？難道每次遇到這個問題，又拍雲都要去修改程序？這種解決方法感覺是在亡羊補牢，每丟一次羊，都要補一次牢，而且每次牢補好了，都要付出丟羊的代價。難道真的就沒有一勞永逸的方法——不僅只需補一次牢，而且可以把以前丟的羊找回來了。難道真的就實現不了讓用戶可以根據擴展名指定MIME type？
用戶遇到一個問題，小心翼翼地遞過去。。。收到回復時滿心歡喜，可是打開一看，原來的問題卻變成了另外一個需要由用戶自己解決的問題。用戶心里就糾結啊，本來是好好的，搬到這來才出現這個問題的，而且只要是同樣情況的用戶，都會面臨這個問題，為什么要讓我為此付出代價呢？而且用戶還要為用戶的用戶盡快解決這個問題，所以只能選擇最快最簡單的解決方法——撤回自己的服務器。
做雲計算器就是做服務，任何由於使用了該服務給用戶帶來的額外問題都應該由服務提供者來承擔、來解決。哪怕暫時沒有好的解決方法，需要手工完成，也要由服務提供者來承擔。只有切身體會到用戶的痛處，才能設計出更好的服務。