Dela via

Versionshantering för Azure Storage

  • Artikel

Azure Storage stöder flera versioner. Om du vill göra en begäran mot lagringstjänsterna måste du ange den version som du vill använda för den åtgärden, såvida inte begäran är anonym.

Den aktuella versionen av Azure Storage-tjänsterna är 2024-11-04, och vi rekommenderar att du använder den där det är möjligt. En lista över alla andra versioner som stöds och information om hur du använder varje version finns i Tidigare Azure Storage-tjänstversioner.

Tjänstversionen 2024-11-04 innehåller följande funktioner:

Ange tjänstversioner i begäranden

Hur du anger vilken version av lagringstjänsterna som ska användas för en begäran relaterar till hur begäran är auktoriserad. I följande avsnitt beskrivs auktoriseringsalternativ och hur tjänstversionen anges för var och en.

  • Begäranden som använder en OAuth 2.0-token från Microsoft Entra: Om du vill auktorisera en begäran med Microsoft Entra-ID skickar du x-ms-version-huvudet på begäran med en tjänstversion av 2017-11-09 eller senare. Mer information finns i Anropa lagringsåtgärder med OAuth-token i Auktorisera med Microsoft Entra ID.

  • begäranden som använder delad nyckel eller delad nyckel Lite: Skicka x-ms-version-huvudet på begäran om du vill auktorisera en begäran med delad nyckel eller delad nyckel lite. När det gäller Azure Blob Storage kan du ange standardversionen för alla begäranden genom att anropa Ange blobtjänstegenskaper.

  • Begäranden som använder en signatur för delad åtkomst (SAS): Du kan ange två versionsalternativ för en signatur för delad åtkomst. Det valfria api-version-huvudet anger vilken tjänstversion som ska användas för att köra API-åtgärden. Den obligatoriska SignedVersion (sv)-parametern anger den tjänstversion som ska användas för att auktorisera den begäran som görs med SAS. Om api-version-huvudet inte har angetts anger värdet för parametern SignedVersion (sv) också vilken version som ska användas för att köra API-åtgärden.

  • Begäranden som använder anonym åtkomst: Vid anonym åtkomst mot Blob Storage skickas ingen version. Heuristiken för att avgöra vilken version som ska användas för begäran beskrivs i nästa avsnitt.

Auktorisera begäranden med hjälp av Microsoft Entra-ID, delad nyckel eller delad nyckel lite

Om du vill auktorisera en begäran med Microsoft Entra ID, Delad nyckel eller Delad nyckel Lite anger du x-ms-version-huvudet på begäran. Värdet för x-ms-version begärandehuvud måste anges i formatet ÅÅÅÅ-MM-DD. Till exempel:

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

Följande regler beskriver hur dessa begäranden utvärderas för att avgöra vilken version som ska användas för att bearbeta begäran.

  • Om en begäran har ett giltigt x-ms-version huvud använder lagringstjänsten den angivna versionen. Alla begäranden till Azure Table Storage och Azure Queue Storage som inte använder en signatur för delad åtkomst måste ange ett x-ms-version-huvud. Alla begäranden till Blob Storage som inte använder en signatur för delad åtkomst måste ange ett x-ms-version-huvud om inte standardversionen har angetts, enligt beskrivningen i nästa stycke.

  • Om en begäran till Blob Storage inte har ett x-ms-version-huvud, men kontoägaren har angett en standardversion med hjälp av åtgärden Ange blobtjänstegenskaper, används den angivna standardversionen som version för begäran.

Auktorisera begäranden med hjälp av en signatur för delad åtkomst

En signatur för delad åtkomst (SAS) som genereras med hjälp av version 2014-02-14 eller senare stöder två versionsalternativ:

  • Frågeparametern api-version definierar restprotokollversionen som ska användas för bearbetning av en begäran som görs med hjälp av SAS.

  • Frågeparametern SignedVersion (sv) definierar den SAS-version som ska användas för auktorisering.

Frågeparametern SignedVersion används för auktorisering när en klient gör en begäran med hjälp av SAS. Auktoriseringsparametrar som si, sr, sp, sig, st, se, tn, spk, srk, epkoch erk tolkas med den angivna versionen.

REST-protokollparametrar som rscc, rscd, rsce, rscloch rsct tillämpas med hjälp av den version som anges i api-version parameterrubrik. Om api-version-huvudet inte har angetts används den tjänstversion som tillhandahålls för SignedVersion.

Parametern api-version är inte en del av sträng-till-inloggningen i auktoriseringshuvudet, enligt beskrivningen i Create a service SAS.

I följande tabell beskrivs versionsschemat som används av tjänsten för auktorisering och för att anropa REST-protokollet när parametern SignedVersion anges till version 2014-02-14 eller senare.

Värdet för parametern api-version Version som används för auktorisering Version som används för protokollbeteende
Inte angivet Version som anges i parametern sv Version som anges i parametern sv
Alla giltiga lagringstjänster i format XXXX-XX-XX Version som anges i parametern sv Giltig version av lagringstjänster XXXX-XX-XX

Exempel 1

Följande exempelbegäran anropar listblobar med sv=2015-04-05och utan parametern api-version.

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

I det här fallet autentiserar och auktoriserar tjänsten begäran med hjälp av version 2015-04-05, och den kör åtgärden med hjälp av version 2015-04-05.

Exempel 2

Följande exempelbegäran anropar listblobar med sv=2015-04-05 och med parametern 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

Här auktoriserar tjänsten begäran med hjälp av version 2015-04-05 och kör åtgärden med hjälp av version 2012-02-12.

Not

.NET Storage-klientbiblioteket anger alltid REST-protokollversionen (i parametern api-version) till den version som den baseras på.

Begäranden via anonym åtkomst

Begäranden som görs via anonym åtkomst hanteras på olika sätt, beroende på vilken typ av lagringskonto de görs mot.

För allmänna lagringskonton

Om en anonym begäran till ett allmänt lagringskonto inte anger x-ms-version-huvudet och standardversionen för tjänsten inte har angetts med hjälp av Ange blobtjänstegenskaperanvänder tjänsten den tidigaste möjliga versionen för att bearbeta begäran. Men om containern offentliggjordes med en Ange container-ACL åtgärd som utfördes med version 2009-09-19 eller senare bearbetas begäran med version 2009-09-19.

För Blob Storage-konton

Om en anonym begäran till ett Blob Storage-konto inte anger x-ms-version-huvudet och standardversionen för tjänsten inte har angetts med hjälp av Ange blobtjänstegenskaperanvänder tjänsten den tidigaste möjliga versionen för att bearbeta begäran. För ett Blob Storage-konto är den tidigaste möjliga versionen 2014-02-14.

Kända problem

I det här avsnittet beskrivs kända problem för REST-API:er för Azure Storage.

InvalidHeaderValue felmeddelande

I sällsynta fall kan program som gör direkta REST API-anrop få ett InvalidHeaderValue felmeddelande. Felet ser ut ungefär som i följande exempel:

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>

Vi rekommenderar att du använder en tidigare REST API-version för att se om problemet löser sig. Om problemet kvarstår eller om rekommendationen inte är möjlig kan du öppna ett supportärende för att diskutera ytterligare alternativ.

Se även