Question

因此，我们正在构建基于Web的音频流平台，其中音频文件存储在blob存储中。我们正在为blob创建一个SAS URL，然后将其提供给javascript播放器（极光）。

这在大多数情况下工作正常，但是当我多次切换曲目时，在某个时刻我开始收到403对文件的HEAD请求的响应。

如果我点击firebug中的RESEND，它只是重新发送完全相同的请求，那么有时我仍会得到相同的403错误，但过了一会儿，请求将再次成功，这意味着URL正确形成。

以下是我得到的完整回复

403 Server failed to authenticate the request. Make sure the value of
Authorization header is formed correctly including the signature.
Transfer-Encoding:  chunked Server:  Microsoft-HTTPAPI/2.0
x-ms-request-id:  <removed>
access-control-expose-headers: 
Content-Type,Accept-Ranges,Content-Encoding,Content-Length,Content-Range
Access-Control-Allow-Origin:  * Date:  Fri, 12 Aug 2016 06:31:58 GMT

我开始认为会触发对blob存储的某种限制，例如最大连接数或带宽限制，甚至可能是DOS防御机制。有没有人有任何建议？

我已经阅读了一些关于存储中的诊断的文章，但它们都引用了旧的Azure门户。我的存储帐户仅在新门户中可见。所以我的问题是：任何人都可以指导我使用新的Azure门户来诊断请求被拒绝的原因吗？

修改我已经使用Azure Management Studio来查看存储帐户的日志。我在那里发现了这个日志，它指定了一个'SASNetworkError'：

1.0;2016-08-12T10:26:27.7337647Z;GetBlob;SASNetworkError;206;19002;6;sas;;[xxx];blob;"https://[xxx].blob.core.windows.net:443/files/[xxx].flac?sv=2015-04-05&amp;sr=b&amp;si=flacpolicy636065943797947863&amp;sig=XXXXX&amp;sip=[xxx]";"/[xxx]/files/[xxx].flac";8f7d48a3-0001-0017-5983-f499a7000000;0;[xxx]:40690;2015-04-05;637;0;499;0;0;;;"&quot;0x8D35C8CDDD72689&quot;";Monday, 04-Apr-16 13:27:27 GMT;;"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0";"http://[xxx].azurewebsites.net/";

看起来这是导致错误的原因，但我无法弄清楚失败的原因。

Answer 1

根据此article，

由于网络错误而失败的SAS请求。最常见的情况是客户端在超时到期之前过早关闭连接。

是否有关闭连接的网络中介（如代理）？

Answer 2

我发现了导致错误的原因：容器上最多有5个命名访问策略。我正在为每个游戏创建一个新的访问策略，并以新名称注册。我通过创建一个新策略并将其传递给GetSharedAccessSignature调用来解决这个问题。

通过SAS访问Azure blob存储时禁止偶发403

2 个答案: