J'utilise l'entreposage d'Azure Blob pour stocker des fichiers multimédias et donner accès à ces fichiers à l'aide de signatures d'accès partagées; Tout fonctionne bien à cet égard.
Cependant, j'ai une application cliente qui doit "reprendre" l'accès à ces fichiers et le fait à l'aide d'un en-tête de plage HTTP. Quand cela fait une demande comme celle-ci, elle est mécontente du résultat qu'il revenait d'Azure. P>
Je ne sais pas comment afficher les détails du côté azur pour voir si la demande a échoué ou si Il vient de retourner quelque chose que le client ne s'attendait pas et je n'ai aucune visibilité de débogage dans le client. P>
Voici ce que l'en-tête de la plage entrante ressemble à: p> Mise à jour: forte >
Il semble que Azure puisse renvoyer un code d'état incorrect pour les demandes de plage, ce qui entraîne les applications de mon client de rejeter la réponse. La documentation indique que Azure répondra avec un code d'état HTTP de 206 lors de la réponse à une demande de plage, toutefois, lorsque je délivrant une demande de gamme, comme celui-ci: P> 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
4 Réponses :
Oui, ça marche. J'ai utilisé SAS pour diffuser la vidéo sur les téléphones mobiles, qui utilisent des en-têtes de plage.
Son facile à vérifier avec un peu de code aussi.
J'ai contacté quelques membres de l'équipe de produits et a reçu ce qui suit ...
Le 200 vs 206 est due aux cadeaux du drapeau "-I" dans la commande CURL. Il en résulte une demande de tête au lieu d'un get qui est essentiellement comme "Obtenir des propriétés BLOB" au lieu d'un "GET BLOB" qui entraînera l'ignorer l'en-tête de la plage. Assurez-vous également de spécifier les en-têtes de version comme «X-MS-Version: 2011-08-18» ou ultérieure, car le format de plage «Démarrage» n'a été pris en charge que sur cette version ultérieure.
Pour plus d'informations sur les en-têtes de plage, voir: http: // msdn .microsoft.com / fr-US / US / Bibliothèque / WindowsAzure / EE691967.aspx
Bonjour Brent, j'ai fait des tests ce soir et j'ai modifié ma commande Curl pour récupérer le fichier et écrire les en-têtes de la réponse à un fichier séparé. Ce faisant, j'ai pu confirmer que lorsque l'octet de départ et de fin de la plage est spécifié, une réponse 206 est renvoyée, toutefois, lorsque l'octet de fin n'est pas spécifié ("-R 500-"), un statut de 200 est renvoyé. . Selon cette page: msdn.microsoft.com/en-us/library /windowsazure/ee691967.aspx Le format ouvert est pris en charge pour les demandes de gamme. Ces demandes devraient donc renvoyer une 206, correcte?
Avez-vous supprimé le drapeau "-i"?
Oui, voici un exemple: curl -i -o 1.mp3 " murfie.blob.core.windows.net/168464/... " - D 1mp3head.txt -r 500-
euh, c'est toujours là, premier paramètre
C'est en minuscule "i", ("Inclure les en-têtes de protocole dans la sortie (H / F)") non majuscule "i" ("Afficher les informations de document uniquement")
kk. Je vais vérifier à nouveau et voir ce que je revenais. :)
C'est un peu malheureux que l'appel «Get Blu Properties» ne renvoie pas l'en-tête «Accepter-Ranges». Certains systèmes attendent le même ensemble d'en-têtes pour une demande de tête en tant que demande d'obtention et utilisez la demande de tête pour déterminer si des demandes de portée sont même possibles. Avec la mise en œuvre actuelle, le système doit ESSAYER REAL Demande de plage, puis retomber au téléchargement complet s'il ne reçoit pas de gamme.
Nous avons eu cette redressée.
Comme @BrentDacodemonkey Mentionné, Azure renvoie la réponse attendue 206 Si vous utilisez la version API 2011-01-18 ou mieux, mais dans notre cas, nous ne provenons pas de la demande afin que nous ne puissions donc pas spécifier cela à l'aide de la demande. En-tête.
Cependant, certains amis Microsoft nous ont appuyé sur le fait que vous pouvez définir la version API globalement pour un compte de stockage, mais vous devez utiliser l'API de repos pour le faire (ce n'est pas quelque chose que vous pouvez faire dans la gestion de la gestion) . Cet article explique comment:
http://msdn.microsoft.com/en-us/library/windowsazure/hh452235 .aspx
Après avoir défini la défaillance duerviceVersion sur 2011-01-18, nous récupérons maintenant le statut de 206 prévu pour les demandes de gamme.
Juste une tête d'un codeur frustré qui a passé près de deux jours à travailler dans ce même problème - il devrait être la version 2011-08-18 ou plus. Utiliser 2011-01-18 entraîne une erreur de document XML non valide.
Comme il n'est pas mentionné nulle part ici, je veux juste ajouter que ce correctif s'écoule à l'Azure CDN si vous l'utilisez.
Puis-je faire une demande au reste API via Postman? Je reçois cette erreur:> La signature Mac trouvée dans la requête HTTP n'est pas la même que la signature calculée.
Pour ceux qui luttent avec l'API de service Azure et l'autorisation délicate, je recommande le ce très simple cippet C # qui fait exactement la même chose de manière très simple (au moins pour moi).
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 = client.GetServiceProperties();
properties.DefaultServiceVersion = "2013-08-15";
client.SetServiceProperties(properties);
Toute façon d'y parvenir chez PHP / Laravel?