Versiebeheer voor Azure Storage

  • Artikel

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

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

De serviceversie 2023-11-03 bevat de volgende functies:

  • Geen.

Serviceversies opgeven in aanvragen

Hoe u de versie opgeeft van de opslagservices die voor een aanvraag moeten worden gebruikt, is gerelateerd aan de wijze waarop die aanvraag wordt geautoriseerd. In de volgende secties worden autorisatieopties beschreven en wordt beschreven hoe de serviceversie voor elke versie wordt opgegeven.

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

  • Aanvragen die gebruikmaken van een 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 van de aanvraag door. In het geval van Azure Blob Storage kunt u de standaardversie voor alle aanvragen opgeven door Eigenschappen van blobservice instellen aan te roepen.

  • Aanvragen die gebruikmaken van een Shared Access Signature (SAS): 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 geeft de serviceversie op die moet worden gebruikt om de aanvraag te autoriseren die met de SAS wordt gedaan. Als de api-version header niet is opgegeven, geeft de waarde van de SignedVersion (sv) parameter 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 voor Blob Storage wordt er geen versie doorgegeven. De heuristiek om te bepalen welke versie voor de aanvraag moet worden gebruikt, wordt 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 van de aanvraag op. De x-ms-version waarde van de aanvraagheader moet worden opgegeven in de indeling 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 shared access signature gebruiken, moeten een x-ms-version header opgeven. Alle aanvragen voor Blob Storage die geen shared access signature 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 header heeft x-ms-version , maar de accounteigenaar een standaardversie heeft ingesteld met behulp van de bewerking Eigenschappen van blobservice instellen , wordt de opgegeven standaardversie gebruikt als de versie voor de aanvraag.

Aanvragen autoriseren met behulp van een shared access signature

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

  • 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 indient met behulp van de SAS. Autorisatieparameters zoals si, sr, sp, sig, stse, , 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 opgegeven serviceversie gebruikt SignedVersion .

De api-version parameter maakt geen deel uit van de tekenreeks om de autorisatie-header aan te melden, zoals beschreven in Een service-SAS maken.

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

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

Voorbeeld 1

Met de volgende voorbeeldaanvraag worden List-blobs aangeroepen met sv=2015-04-05en zonder de api-version parameter .

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 behulp van versie 2015-04-05 en wordt de bewerking uitgevoerd met behulp van versie 2015-04-05.

Voorbeeld 2

Met de volgende voorbeeldaanvraag worden List-blobs aangeroepen met sv=2015-04-05 en met de api-version parameter .

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 behulp van versie 2015-04-05 en wordt de bewerking uitgevoerd met behulp van versie 2012-02-12.

Notitie

De .NET Storage-clientbibliotheek stelt altijd de REST-protocolversie (in de api-version parameter) 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 waarvoor ze worden gedaan.

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 Eigenschappen voor blobservice instellen, gebruikt de service de vroegst mogelijke versie om de aanvraag te verwerken. Als de container echter openbaar is gemaakt met een set container ACL-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-serviceeigenschappen 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 met de Azure Storage REST API's.

InvalidHeaderValue Foutbericht

In zeldzame scenario's kunnen toepassingen die directe REST API-aanroepen doen, 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>

U wordt aangeraden een eerdere REST API-versie te gebruiken om te zien of het probleem is opgelost. Als het probleem zich blijft voordoen of als de aanbeveling niet haalbaar is, opent u een ondersteuningsticket om verdere opties te bespreken.

Zie ook