Delen via

Versiebeheer voor Azure Storage

  • Artikel

Azure Storage ondersteunt meerdere versies. Als u een aanvraag wilt indienen voor de opslagservices, moet u de versie opgeven die u voor die bewerking wilt gebruiken, tenzij de aanvraag anoniem is.

De huidige versie van de Azure-opslagservices is 2024-11-04 en we raden u aan deze waar mogelijk te gebruiken. Zie voor een lijst met alle andere ondersteunde versies en voor informatie over het gebruik van elke versie eerdere versies van de Azure Storage-service.

De serviceversie 2024-11-04 bevat de volgende functies:

Serviceversies opgeven in aanvragen

Hoe u de versie opgeeft van de opslagservices die moeten worden gebruikt voor een aanvraag, heeft betrekking op hoe deze aanvraag is geautoriseerd. In de volgende secties worden autorisatieopties beschreven en hoe de serviceversie voor elke versie wordt opgegeven.

  • aanvragen die gebruikmaken van een OAuth 2.0-token van Microsoft Entra: als u een aanvraag met Microsoft Entra-id wilt autoriseren, geeft u de x-ms-version header op de aanvraag door met een serviceversie van 2017-11-09 of hoger. Zie Opslagbewerkingen aanroepen met OAuth-tokens in Autoriseren met Microsoft Entra IDvoor meer informatie.

  • aanvragen die gebruikmaken van gedeelde sleutel of gedeelde sleutel lite: als u een aanvraag wilt autoriseren met een gedeelde sleutel of gedeelde sleutel lite, geeft u de x-ms-version header op de aanvraag door. In het geval van Azure Blob Storage kunt u de standaardversie voor alle aanvragen opgeven door Blob Service-eigenschappen instellenaan te roepen.

  • aanvragen die gebruikmaken van een SAS-(Shared Access Signature): u kunt twee opties voor versiebeheer opgeven voor een shared access Signature. De optionele api-version header geeft aan welke serviceversie moet worden gebruikt om de API-bewerking uit te voeren. De vereiste SignedVersion (sv) parameter specificeert de serviceversie die moet worden gebruikt om de aanvraag te autoriseren die is gedaan met de SAS. Als de api-version header niet is opgegeven, geeft de waarde van de parameter SignedVersion (sv) ook de versie aan die moet worden gebruikt om de API-bewerking uit te voeren.

  • aanvragen die gebruikmaken van anonieme toegang: in het geval van anonieme toegang tegen Blob Storage wordt er geen versie doorgegeven. De heuristiek voor het bepalen welke versie voor de aanvraag moet worden gebruikt, worden beschreven in de volgende secties.

Aanvragen autoriseren met behulp van Microsoft Entra ID, Gedeelde sleutel of Gedeelde Sleutel Lite

Als u een aanvraag wilt autoriseren met Microsoft Entra ID, Gedeelde sleutel of Gedeelde Sleutel Lite, geeft u de x-ms-version header op voor de aanvraag. De x-ms-version aanvraagheaderwaarde moet worden opgegeven in de notatie JJJJ-MM-DD. Bijvoorbeeld:

Request Headers:  
x-ms-version: 2020-04-08

In de volgende regels wordt beschreven hoe deze aanvragen worden geëvalueerd om te bepalen welke versie moet worden gebruikt om de aanvraag te verwerken.

  • Als een aanvraag een geldige x-ms-version header heeft, gebruikt de opslagservice de opgegeven versie. Alle aanvragen voor Azure Table Storage en Azure Queue Storage die geen handtekening voor gedeelde toegang gebruiken, moeten een x-ms-version-header opgeven. Alle aanvragen voor Blob Storage die geen handtekening voor gedeelde toegang gebruiken, moeten een x-ms-version-header opgeven, tenzij de standaardversie is ingesteld, zoals beschreven in de volgende alinea.

  • Als een aanvraag voor Blob Storage geen x-ms-version header heeft, maar de accounteigenaar een standaardversie heeft ingesteld met behulp van de Eigenschappen van blobservice instellen bewerking, wordt de opgegeven standaardversie gebruikt als de versie voor de aanvraag.

Aanvragen autoriseren met een handtekening voor gedeelde toegang

Een Shared Access Signature (SAS) die wordt gegenereerd met versie 2014-02-14 of hoger, ondersteunt twee opties voor versiebeheer:

  • De api-version queryparameter definieert de REST-protocolversie die moet worden gebruikt voor het verwerken van een aanvraag die wordt gedaan met behulp van de SAS.

  • De SignedVersion (sv) queryparameter definieert de SAS-versie die moet worden gebruikt voor autorisatie.

De SignedVersion queryparameter wordt gebruikt voor autorisatie wanneer een client een aanvraag doet met behulp van de SAS. Autorisatieparameters zoals si, sr, sp, sig, st, se, tn, spk, srk, epken erk worden allemaal geïnterpreteerd met behulp van de opgegeven versie.

REST-protocolparameters zoals rscc, rscd, rsce, rsclen rsct worden afgedwongen met behulp van de versie die is opgegeven in de api-version parameterheader. Als de api-version header niet is opgegeven, wordt de serviceversie gebruikt die wordt geleverd voor SignedVersion.

De parameter api-version maakt geen deel uit van de tekenreeks-naar-aanmelding in de autorisatieheader, zoals beschreven in Een service-SAS-maken.

In de volgende tabel wordt het versiebeheerschema uitgelegd dat wordt gebruikt door de service voor autorisatie en voor het aanroepen van het REST-protocol wanneer de parameter SignedVersion is ingesteld op versie 2014-02-14 of hoger.

Waarde van api-versie parameter Versie die wordt gebruikt voor autorisatie Versie die wordt gebruikt voor protocolgedrag
Niet opgegeven Versie die is opgegeven in de parameter sv Versie die is opgegeven in de parameter sv
Elke geldige versie van opslagservices in indeling XXXX-XX-XX Versie die is opgegeven in de parameter sv Geldige versie van opslagservices XXXX-XX-XX

Voorbeeld 1

In de volgende voorbeeldaanvraag wordt list-blobs aanroepen met sv=2015-04-05en zonder de parameter api-version.

https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2015-04-05&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d

In dit geval verifieert en autoriseert de service de aanvraag met versie 2015-04-05 en wordt de bewerking uitgevoerd met versie 2015-04-05.

Voorbeeld 2

De volgende voorbeeldaanvraag roept List Blobs- aan met sv=2015-04-05 en met de parameter api-version.

https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2015-04-05&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d&api-version=2012-02-12

Hier autoriseert de service de aanvraag met versie 2015-04-05 en wordt de bewerking uitgevoerd met versie 2012-02-12.

Notitie

De .NET Storage-clientbibliotheek stelt altijd de REST-protocolversie (in de parameter api-version) in op de versie waarop deze is gebaseerd.

Aanvragen via anonieme toegang

Aanvragen die via anonieme toegang worden gedaan, worden anders verwerkt, afhankelijk van het type opslagaccount waarop ze worden uitgevoerd.

Voor opslagaccounts voor algemeen gebruik

Als een anonieme aanvraag voor een opslagaccount voor algemeen gebruik de x-ms-version header niet opgeeft en de standaardversie voor de service niet is ingesteld met behulp van Blob Service-eigenschappen instellen, gebruikt de service de vroegst mogelijke versie om de aanvraag te verwerken. Als de container echter openbaar is gemaakt met een Container-ACL instellen bewerking die is uitgevoerd met versie 2009-09-19 of hoger, wordt de aanvraag verwerkt met versie 2009-09-19.

Voor Blob Storage-accounts

Als een anonieme aanvraag voor een Blob Storage-account de x-ms-version header niet opgeeft en de standaardversie voor de service niet is ingesteld met behulp van Blob Service-eigenschappen instellen, gebruikt de service de vroegst mogelijke versie om de aanvraag te verwerken. Voor een Blob Storage-account is de vroegst mogelijke versie 2014-02-14.

Bekende problemen

In deze sectie vindt u informatie over bekende problemen voor de REST API's van Azure Storage.

InvalidHeaderValue foutbericht

In zeldzame scenario's kunnen toepassingen die directe REST API-aanroepen maken, een InvalidHeaderValue foutbericht ontvangen. De fout ziet er ongeveer als volgt uit:

HTTP/1.1 400 The value for one of the HTTP headers is not in the correct format.
Content-Length: 328
Content-Type: application/xml
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: <REMOVED>
Date: Fri, 19 May 2023 17:10:33 GMT
 
<?xml version="1.0" encoding="utf-8"?><Error><Code>InvalidHeaderValue</Code><Message>The value for one of the HTTP headers is not in the correct format.
RequestId:<REMOVED>
Time:2023-05-19T17:10:34.2972651Z</Message><HeaderName>x-ms-version</HeaderName><HeaderValue>yyyy-mm-dd</HeaderValue></Error>

Het is raadzaam om een eerdere REST API-versie te gebruiken om te zien of het probleem wordt opgelost. Als het probleem zich blijft voordoen of als de aanbeveling niet haalbaar is, een ondersteuningsticket openen om meer opties te bespreken.

Zie ook