HTTP RANGE标头是否可以与Azure Blob存储共享访问签名一起使用？ [英] Do HTTP RANGE headers work with Azure Blob Storage Shared Access Signatures?

问题描述

我正在使用Azure Blob存储来存储媒体文件并使用共享访问签名提供对这些文件的访问;在这方面，一切都运行良好。

I'm using Azure Blob Storage to store media files and providing access to these files using Shared Access Signatures; everything is working well in this regard.

但是，我有一个客户端应用程序，需要恢复对这些文件的访问，并使用HTTP RANGE标头。当它发出这样的请求时，它对从Azure返回的结果感到不满。

However, I have a client application that needs to "resume" access to these files and does so using an HTTP RANGE header. When it makes a request like this, it is unhappy with the result it gets back from Azure.

我不知道如何查看Azure端的详细信息看看请求是否失败，或者它是否只是返回了客户端没想到的东西，而且我没有对客户端的调试可见性。

I'm not sure how to view the details on the Azure side to see if the request failed, or if it just returned something the client didn't expect, and I have no debugging visibility into the client.

这是传入的范围标题看起来像：

Here's what the incoming range header looks like:

RANGE: bytes=4258672-

从Azure文档中我看到它似乎支持RANGE标题，但是我想知道是否一起使用RANGE和共享访问签名存在冲突？

From the Azure documentation I've read it appears to support RANGE headers, however I'm wondering if there is a conflict using RANGE and Shared Access Signatures together?

更新：
似乎Azure可能会为RANGE请求返回错误的状态代码，这会导致我的客户端应用拒绝响应。该文档指出Azure在响应RANGE请求时将响应HTTP状态代码206，但是当我发出这样的RANGE请求时：

Update: It appears that Azure may be returning an incorrect status code for RANGE requests, which is causing my client apps to reject the response. The documentation states that Azure will respond with an HTTP status code of 206 when responding to a RANGE request, however when I issue a RANGE request like this:

curl -I -H "User-Agent: Bonos" -r 500- "https://murfie.blob.core.windows.net/168464/1.mp3?st=2013-07-03T16%3A34%3A32.4832235Z&se=2013-07-03T17%3A34%3A32.4613735Z&sr=b&sp=r&sig=mJgQGW%2Fr3v8HN2%2BVV3Uady7J68nFqeHyzQb37HAhfuE%3D"

Azure返回以下内容：

Azure returns the following:

HTTP/1.1 200 OK
Content-Length: 19988911
Content-Type: application/octet-stream Charset=UTF-8
Last-Modified: Fri, 07 Jun 2013 16:44:50 GMT
ETag: 0x8D031B57670B986
Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 77312761-65a9-42ef-90cd-ff718a80b231
Date: Wed, 03 Jul 2013 16:41:01 GMT

推荐答案

我们得到了这个拉直out。

We got this straightened out.

作为@BrentDaCode Monkey提到，如果您使用的是API版本2011-01-18或更高版本，Azure会返回预期的206响应，但在我们的情况下，我们不会发起请求，因此我们无法使用请求标头指定此项。

As @BrentDaCodeMonkey mentioned, Azure returns the expected 206 response if you're using API version 2011-01-18 or better, but in our case we don't originate the request so we can't specify this using the request header.

然而，一些微软朋友告诉我们，您可以为存储帐户全局设置API版本，但是您需要使用REST API这样做（它不是您可以在管理UI中执行的操作）。这篇文章解释了如何：

However, some Microsoft friends tipped us of to the fact that you can set the API version globally for a storage account, but you need to use the REST API to do so (it's not something you can do in the management UI). This post explains how:

http： //msdn.microsoft.com/en-us/library/windowsazure/hh452235.aspx

将DefaultServiceVersion设置为2011-01-18后，我们现在回到RANGE请求的预期206状态。

After setting the DefaultServiceVersion to 2011-01-18, we're now getting back the expected 206 status for RANGE requests.

这篇关于HTTP RANGE标头是否可以与Azure Blob存储共享访问签名一起使用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！