2013-07-01 24 views
7

Tôi đang sử dụng Bộ lưu trữ Azure Blob để lưu trữ các tệp phương tiện và cung cấp quyền truy cập vào các tệp này bằng cách sử dụng Chữ ký Truy cập Được chia sẻ; mọi thứ đều hoạt động tốt trong lĩnh vực này.Tiêu đề HTTP RANGE có hoạt động với Chữ ký Truy cập Chia sẻ Lưu trữ Azure Blob không?

Tuy nhiên, tôi có ứng dụng khách cần truy cập "tiếp tục" vào các tệp này và làm như vậy bằng cách sử dụng tiêu đề HTTP RANGE. Khi nó làm cho một yêu cầu như thế này, nó là không hài lòng với kết quả nó được trở lại từ Azure.

Tôi không chắc chắn cách xem chi tiết ở phía Azure để xem yêu cầu có thành công không, hoặc nếu nó vừa trả lại thứ gì đó mà khách hàng không mong đợi và tôi không có khả năng hiển thị lỗi trong máy khách.

Đây là những gì tiêu đề phạm vi đến trông giống như:

RANGE: bytes=4258672- 

Từ các tài liệu Azure Tôi đã đọc nó xuất hiện để hỗ trợ tiêu đề PHẠM VI, tuy nhiên tôi tự hỏi nếu có một cuộc xung đột sử dụng PHẠM VI và Chia sẻ kết nối Chữ ký cùng nhau?

Cập nhật: Có vẻ như Azure có thể trả lại mã trạng thái không chính xác cho các yêu cầu RANGE, điều này khiến ứng dụng khách của tôi từ chối phản hồi. Các tài liệu nói rằng Azure sẽ phản ứng với một mã trạng thái HTTP 206 khi trả lời một yêu cầu PHẠM VI, tuy nhiên khi tôi đưa ra một yêu cầu PHẠM VI như thế này:

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 trả về như sau:

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 

Trả lời

6

We got này thẳng ra.

Như @BrentDaCodeMonkey đã đề cập, Azure trả về phản hồi 206 dự kiến ​​nếu bạn đang sử dụng phiên bản API 2011-01-18 hoặc tốt hơn, nhưng trong trường hợp của chúng tôi, chúng tôi không bắt nguồn yêu cầu để chúng tôi không thể chỉ định điều này bằng cách sử dụng tiêu đề yêu cầu. Tuy nhiên, một số người bạn của Microsoft đã cho chúng tôi biết rằng bạn có thể thiết lập phiên bản API trên toàn cầu cho một tài khoản lưu trữ, nhưng bạn cần sử dụng REST API để làm như vậy (nó không phải là thứ bạn có thể làm trong UI quản lý).). Bài viết này giải thích cách:

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

Sau khi thiết lập các DefaultServiceVersion để 2011/01/18, chúng tôi bây giờ nhận lại dự kiến ​​206 tình trạng cho các yêu cầu RANGE.

+0

Chỉ cần một người đứng đầu từ một lập trình viên thất vọng đã dành gần hai ngày làm việc thông qua cùng một vấn đề này - nó phải là phiên bản 2011-08-18 hoặc cao hơn. Sử dụng kết quả 2011-01-18 trong một lỗi Tài liệu XML không hợp lệ. –

+0

Vì nó không được đề cập bất cứ nơi nào ở đây, tôi chỉ muốn thêm rằng sửa chữa này chảy qua Azure CDN nếu bạn đang sử dụng nó. –

1

Có nó hoạt động. Tôi đã sử dụng SAS để truyền video sang điện thoại di động, sử dụng tiêu đề Phạm vi.

Dễ dàng xác minh bằng một chút mã.

2

tôi đã tìm đến một số thành viên của nhóm sản phẩm và đã được đưa ra như sau ...

200 vs 206 là do những món quà của lá cờ "-I" trong lệnh curl. Điều này dẫn đến một yêu cầu HEAD thay vì một GET mà về cơ bản là "nhận được blob tài sản" cuộc gọi thay vì một "nhận được blob" mà sẽ gây ra tiêu đề phạm vi được bỏ qua. Ngoài ra, hãy đảm bảo chỉ định tiêu đề phiên bản là "x-ms-phiên bản: 2011-08-18" trở lên vì định dạng phạm vi "startByte-" chỉ được hỗ trợ trên phiên bản sau này.

Để biết thêm thông tin về tiêu đề phạm vi, xem: http://msdn.microsoft.com/en-us/library/windowsazure/ee691967.aspx

+0

Hi Brent, tôi đã làm một số thử nghiệm tối nay và sửa đổi lệnh curl của tôi để lấy các tập tin và viết các tiêu đề của phản ứng vào một tập tin riêng biệt. Làm điều này tôi đã có thể xác nhận rằng khi byte bắt đầu và kết thúc của phạm vi được chỉ định, phản hồi 206 được trả về, tuy nhiên khi byte kết thúc không được chỉ định (IE, "-r 500-"), trạng thái 200 được trả về . Theo trang này: http://msdn.microsoft.com/en-us/library/windowsazure/ee691967.aspx định dạng kết thúc mở được hỗ trợ cho các yêu cầu phạm vi, vì vậy các yêu cầu này phải trả lại 206, đúng không? – jasongullickson

+0

bạn có xóa cờ "-I" không? – BrentDaCodeMonkey

+0

Vâng, đây là ví dụ: curl -i -o 1.mp3 "https://murfie.blob.core.windows.net/168464/1.mp3?st=2013-07-13T05%3A10%3A49.6268343Z&se= 2013-07-13T06% 3A10% A49.5103467Z & sr = b & sp = r & sig = oXniO9YpmMsr8bgkcpvxDgpZlZzIRCNuc9TIZ8tkynY% 3D "-D 1mp3head.txt -r 500- – jasongullickson

1

Đối với những người đang đấu tranh với API dịch vụ Azure và ủy quyền phức tạp, tôi khuyên bạn nên sử dụng đoạn mã C# rất đơn giản này theo cách rất đơn giản (ít nhất là đối với tôi).

 var credentials = new Microsoft.WindowsAzure.Storage.Auth.StorageCredentials("storagename", "storagekey"); 
     var account = new Microsoft.WindowsAzure.Storage.CloudStorageAccount(credentials, true); 
     var client = account.CreateCloudBlobClient(); 
     var properties = await client.GetServicePropertiesAsync(); 
     properties.DefaultServiceVersion = "2013-08-15"; 
     await client.SetServicePropertiesAsync(properties); 
Các vấn đề liên quan