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-08-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-08-04 innehåller följande funktioner:

  • Skapa egenskaper för resurs och ange resurs stöder nu begärandehuvudet x-ms-enable-snapshot-virtual-directory-access . Den här egenskapen returneras nu som ett svarshuvud av Hämta resursegenskaper och som DET XML-element EnableSnapshotVirtualDirectoryAccess som returneras av listresurser.
  • Autentiseringsrelaterade felsvarskroppar kommer nu att innehålla ExtendedErrorDetail XML-elementet, vilket ger mer kontext om autentiseringsfelet. Mer information finns i Status och felkoder

Ange tjänstversioner i begäranden

Hur du anger vilken version av lagringstjänsterna som ska användas för en begäran gäller hur begäran auktoriseras. 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 x-ms-version du 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: Om du vill auktorisera en begäran med delad nyckel eller delad nyckel Lite skickar x-ms-version du huvudet på begäran. 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å versionshanteringsalternativ 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 begäran som görs med SAS. Om huvudet api-version inte anges anger värdet för parametern SignedVersion (sv) även 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 in. 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 rubriken på begäran. Värdet x-ms-version för begärandehuvudet måste anges i formatet ÅÅÅÅ-MM-DD. 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 något x-ms-version huvud, men kontoägaren har angett en standardversion med åtgärden Ange egenskaper för blobtjänsten , 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 version 2014-02-14 eller senare stöder två versionshanteringsalternativ:

  • Frågeparametern api-version definierar rest-protokollversionen 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, setn, spksrk, epkoch erk tolkas med den angivna versionen.

REST-protokollparametrar som rscc, rscd, rsce, rscloch rsct framtvingas med hjälp av den version som anges i api-version parameterhuvudet. Om rubriken api-version inte anges används den tjänstversion som anges för SignedVersion .

Parametern api-version är inte en del av sträng-till-inloggning i auktoriseringshuvudet, enligt beskrivningen i Skapa en tjänst-SAS.

I följande tabell förklaras versionsschemat som används av tjänsten för auktorisering och för att anropa REST-protokollet när parametern SignedVersion är inställd på 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
Valfri giltig version av 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.

Anteckning

.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änstegenskaper, använder tjänsten den tidigaste möjliga versionen för att bearbeta begäran. Men om containern offentliggjordes med en Set 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änstegenskaper, anvä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 genomförbar, öppnar du ett supportärende för att diskutera ytterligare alternativ.

Se även