Versiebeheer voor Azure Storage

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.

Vanaf 11 mei 2026 is de nieuwste volledig uitgerolde versie van de Azure Storage-dienst 2026-04-06, die wordt ondersteund door de nieuwste Azure Storage SDK GA-pakketten. 2026-06-06 is ook breed ingezet, en beide worden ondersteund door de nieuwste bètaversies van de Storage SDK's.

Als in de tabel wordt aangegeven dat an x-ms-version is ingeschakeld in een regio, worden alle voorgaande x-ms-versions ook ingeschakeld. Als u probeert een serviceversie te gebruiken die niet volledig is geïmplementeerd in de regio van uw opslagaccount, kan er een x-ms-versie-niet-overeenkomende fout worden gegenereerd.

De standaardinstelling x-ms-version die wordt gebruikt door de SDK's van het Azure Storage-gegevensvlak, vindt u in de changelogs in de volgende tabel:

De SDK's voor opslag van het gegevensvlak voeren geen GA-releases uit voor de andere officiële pakketfeeds totdat de standaardinstelling x-ms-version voor de release in kwestie volledig is uitgerold in alle regio's. Daarom kan de nieuwste GA SDK-release van de officiële pakketbeheerders veilig in elke regio worden gebruikt.

De nieuwste versie van de Azure-opslagdiensten is 2026-02-06, en wij raden 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 van 2026-06-06 bevat de volgende functies:

• Ondersteuning voor gestructureerd bericht voor Bestand aanmaken.

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. Wanneer u Azure Blob Storage gebruikt, kunt u de standaardversie voor alle aanvragen opgeven door Eigenschappen van de Blob-service instellen aan 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: bij het gebruik 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. Voorbeeld:

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-tabelopslag en Azure Queue Storage die geen handtekening voor gedeelde toegang gebruiken, moeten een x-ms-version-header opgeven. Voor alle aanvragen voor Blob Storage die geen handtekening voor gedeelde toegang gebruiken, moet een x-ms-version header worden opgegeven, tenzij de standaardversie is ingesteld, zoals beschreven in de volgende alinea.

• Als een aanvraag voor Blob Storage geen header bevat x-ms-version , maar de accounteigenaar een standaardversie instelt met behulp van de bewerking Eigenschappen van de Blob-service instellen , 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 , , , , rsccen rscd worden afgedwongen met behulp van de versie die in de rsce parameterheader wordt opgegeven. rsclrsctapi-version Als de api-version header niet is opgegeven, wordt de voorziene SignedVersion serviceversie gebruikt.

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.

Voorbeeld 1

In de volgende voorbeeldaanvraag wordt Lijst 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 versie 2015-04-05 en wordt de bewerking uitgevoerd met versie 2015-04-05.

Voorbeeld 2

In de volgende voorbeeldaanvraag wordt Lijst blobs met sv=2015-04-05 en met de api-version parameter aangeroepen.

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.

Aanvragen via anonieme toegang

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

Opslagaccounts voor algemeen gebruik

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

Voor Blob Storage-accounts

Als voor een anonieme aanvraag naar een Blob Storage-account de x-ms-version header niet is opgegeven en de standaardversie voor de service niet is ingesteld met behulp van Eigenschappen van de Blob-service 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 wordt aanbevolen om een eerdere REST API-versie te gebruiken om te proberen het probleem op te lossen. Als het probleem blijft bestaan, of als de aanbeveling niet haalbaar is, open dan een supportticket om verdere opties te bespreken.

Zie ook

• Storage Services REST-
• best practices voor versiebeheer
• Protocol-versieondersteuning voor .NET-clientbibliotheekversies