之前被云存储的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？
用户遇到一个问题，小心翼翼地递过去。。。收到回复时满心欢喜，可是打开一看，原来的问题却变成了另外一个需要由用户自己解决的问题。用户心里就纠结啊，本来是好好的，搬到这来才出现这个问题的，而且只要是同样情况的用户，都会面临这个问题，为什么要让我为此付出代价呢？而且用户还要为用户的用户尽快解决这个问题，所以只能选择最快最简单的解决方法——撤回自己的服务器。
做云计算器就是做服务，任何由于使用了该服务给用户带来的额外问题都应该由服务提供者来承担、来解决。哪怕暂时没有好的解决方法，需要手工完成，也要由服务提供者来承担。只有切身体会到用户的痛处，才能设计出更好的服务。