sanbo_个人页

楼主的这个问题，开发团队在设计第一天就考虑过。  如果放宽这个限制，会增加“中间人”这种安全漏洞的风险。  在数据安全和易用性上，我们选择了前者。希望楼主能够了解OSS开发人员的良苦用心。谢谢！！！

-------------------------

补充一点：只有在请求中带签名认证头（Authentication）时，才会验证服务器时间和请求机器时间。匿名访问不会做验证。

谢谢楼主的反馈！我们开发同学非常重视这个问题，正在全力排查问题。

-------------------------

1. 在测试中，为了不对用户的bucket产生流量。我将这张图片放到了OSS的另一个bucket里面：。
2. 通过ping，获取当前域名sharedata.oss.aliyuncs.com对应的IP地址是：42.120.62.53。
3. 通过阿里测，对比两个域名的HTTP（sharedata.oss.aliyuncs.com/test.png和42.120.62.53/oss-box/test.png）访问情况（见附件）可知，虽然通过域名访问的平均时间是396ms，但最长访问时间有出现12秒的情况；而直接访问IP的链接，平均314ms，最长是5秒（估计是测试机器的网络不是很好），不会出现10秒的情况。所以我认为是DNS解析时间过长，造成了用户的这个问题。

回头给你整个FTP工具

在完成OSS website的设置后。还去申请一个自己的域名，然后把域名CNAME到http://<bucket>.oss.aliyuncs.com。 CNAME规则生效后，就可以通过你自己的域名访问website了。

我来说下我的理解。

首先来看下标准中对HTTP Header中Content-MD5的定义（摘自 RFC1864 ）：

The output of the MD5 algorithm is a 128 bit digest.  When viewed in    network byte order (big-endian order), this yields a sequence of 16 octets of binary data.  These 16 octets are then encoded according to  the base64 algorithm in order to obtain the value that is placed in  the Content-MD5 field.  Thus, if the application of the MD5 algorithm  over the raw data of a MIME entity results in a digest having the  (unlikely) value of "Check Integrity!", then that MIME entity's  header could contain the field.

标准中定义的算法简单点说就是：先计算md5加密的二进制数组（128 bits），再对这个二进制进行base64编码（而不是对32位字符串编码）。

所以，Delete Multiple Objects请求填的Content-MD5必须按照上面的算法来获得。

至于计算签名的那个地方，它不会验证你的Content-MD5是否合法，它只认为这是一个字符串。现在你不填，甚至填个错的都是可以通过的。

建议大家写代码的时候，严格按照标准来写。以后OSS如果开始验证上传数据的Content-MD5，那么你填个错误的Content-MD5，就会出错。

-------------------------

再多说一句。

通过普通PUT请求上传的Object，OSS返回的ETAG定义是内容的MD5值，也就是32个十六进制数的字符串。和Content-MD5相比是没有经过base64编码的。

-------------------------

回楼上，我说的“Content-MD5是否合法”，是指不会验证HTTP头里的content-md5字段和上传数据的md5值是否一样。  在验证签名头的时候，是要判断提交的Content-MD5和签名中的Content-MD5是否一致。  

举个例子：你可以将HTTP头中的Content-MD5和签名中的都设置成“xxxxx”，是可以通过签名验证的；但你上传内容的MD5值，肯定不是“xxxxx”。

OSS CNAME功能需要备案；但备案可以不买阿里云的服务器。

楼主，对于传统文件系统，写文件写到一半异常退出，操作系统也会留一个不完整的文件在磁盘上。
对于多个客户端同时写同一个Object的情况，最后的Object会写成什么样子是无法预知的。我们目前建议用户在自己的逻辑端避免这种并发写的问题（因为传统的文件系统也不支持对同一个文件的并发写）。

目前我们推荐的标准解决方案是：
1. 生成一个UUID作为Object的名称，然后客户端把数据写入这个Object；
2. 在数据库里写一行数据，记录文件名和其对应的UUID。由于数据库是可以保证事务性，所以就避免的这个问题。
3. 读取的时候要先查一下数据库，找到文件对应的UUID，然后用这个UUID再去OSS中下载数据。

上面是一个标准的事务性操作，可以看出为了实现对同一个文件的并发写的事务性，做起来还是很难的。

OSS争取明年公布并发写的一致性模型：让你的数据要么是A，要么是B，不会是AB的中间状态。

目前正在评估该功能在工信部规定允许范围内的可操作性。按照国家的规定，要开展这个服务有些困难

我来解释一下困惑吧！这也是具有中国特色的解释。

按照工信部的规定，如果你的根域名通过CNAME直接解析到OSS，那么你的域名不但要在域名注册地备案，还要在内容提供地（也就是阿里云）备案。

虽然CNAME功能已经开发完成，但基于上面的规定，用户使用起来非常非常繁琐，而且全部审核都要人工干预。


所以只能用楼主提到的方式：
若设置 img --> oss.aliyuncs.com
则直接访问img.xxx.com/abc/a.jpg正常。

因为你的根域名不是OSS，而是后面跟了一级路径。不知道这算不算擦边球。

最后，OSS从未对外宣称支持CNAME功能（原因就不解释了）。

希望各位OSS用户理解和支持。

四、OSS定义了的所用 XML 的 namespace: xmlns=” http://doc.oss.aliyuncs.com ”

原XML格式	新XML格式
<?xml version="1.0" encoding="UTF-8"?> <InitiateMultipartUploadResult”> <Bucket> multipart_upload</Bucket> <Key>multipart.data</Key> <UploadId>0004B9894A22E5B1888A1E29F8236E2D</UploadId> </InitiateMultipartUploadResult>	<?xml version="1.0" encoding="UTF-8"?> <InitiateMultipartUploadResult xmlns=”http://doc.oss.aliyuncs.com”> <Bucket> multipart_upload</Bucket> <Key>multipart.data</Key> <UploadId>0004B9894A22E5B1888A1E29F8236E2D</UploadId> </InitiateMultipartUploadResult>

如有任何疑问，可以在OSS用户群里提问。
OSS用户QQ群： 199055969
OSS用户旺旺群：876041506

-------------------------

引用第18楼mytan于2012-10-02 00:57发表的 回楼主sanbo的帖子 :
Bucket 为 test

object 为 test1/test2.jpg

直接使用url test.oss.aliyuncs.com/test1/test2.jpg 可以正常打开图片
.......

OSS技术上已经实现了CNAME的功能，但是目前检测访问域名备案的问题无法解决，所以还不能开放这个功能

-------------------------

引用第20楼tyyddd于2012-10-07 22:17发表的 Re【重要通知】阿里云开放存储OSS域名、命名规则调整 :
以后到底还能不能用二级域名访问啊

可以！

OSS对内网没有限速

如果你是内网，请先确认是否使用了OSS的内网域名： http://storage.aliyun-inc.com

-------------------------

OSS对内网没有限速

如果你是内网，请先确认是否使用了OSS的内网域名：

http://storage.aliyun-inc.com

用论坛“第三方开发工具”里面的OSS Java客户端上传文件试试看，也许是环境的问题。

据我所知，PHPWIND直接使用OSS的产品正在内测

不太会用，从哪里拖图片上去阿？

不太会用，从哪里拖图片上去阿？

应该填写http://*.baidu.com

OSS返回给你的错误码已经写清楚了。你上传的第一个part，参数有问题
你可以调用List Part接口，查看这个Part的参数和你上传的参数是否一致。