Lägg till blockera från URL

Artikel
02/07/2024

Åtgärden Append Block From URL checkar in ett nytt datablock i slutet av en befintlig tilläggsblob.

Åtgärden Append Block From URL tillåts endast om bloben skapades med x-ms-blob-type inställd på AppendBlob. Append Block From URL stöds endast i version 2018-11-09 eller senare.

Förfrågan

Du kan skapa begäran på Append Block From URL följande sätt. HTTPS rekommenderas. Ersätt myaccount med namnet på ditt lagringskonto.

URI för PUT-metodbegäran	HTTP-version
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock`	HTTP/1.1

När du gör en begäran mot den emulerade lagringstjänsten anger du emulatorns värdnamn och Azure Blob Storage port som 127.0.0.1:10000följt av det emulerade lagringskontonamnet.

URI för PUT-metodbegäran	HTTP-version
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=appendblock`	HTTP/1.1

Mer information finns i Använda Azurite-emulatorn för lokal Azure Storage-utveckling.

URI-parametrar

Parameter	Beskrivning
`timeout`	Valfritt. Timeout-parametern uttrycks i sekunder. Mer information finns i Ställa in tidsgränser för Blob Storage-åtgärder.

Begärandehuvuden

I följande tabell beskrivs obligatoriska och valfria begärandehuvuden.

Begärandehuvud	Beskrivning
`Authorization`	Krävs. Anger auktoriseringsschema, kontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage .
`Date` eller `x-ms-date`	Krävs. Anger Coordinated Universal Time (UTC) för begäran. Mer information finns i Auktorisera begäranden till Azure Storage.
`x-ms-version`	Krävs för alla auktoriserade begäranden. Anger vilken version av åtgärden som ska användas för den här begäran. Mer information finns i Versionshantering för Azure Storage-tjänsterna.
`Content-Length`	Krävs. Anger antalet byte som överförs i begärandetexten. Värdet för det här huvudet måste anges till noll. När längden inte är noll misslyckas åtgärden med felkoden 400 (felaktig begäran).
`x-ms-copy-source:name`	Krävs. Anger källblobens URL. Värdet kan vara en URL på upp till 2 KiB som anger en blob. Värdet ska vara URL-kodat, som det skulle visas i en begärande-URI. Källbloben måste antingen vara offentlig eller ha behörighet via en signatur för delad åtkomst. Om källbloben är offentlig krävs ingen auktorisering för att utföra åtgärden. Här följer några exempel på URL:er för källobjekt: `https://myaccount.blob.core.windows.net/mycontainer/myblob` `https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>` `https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>`
`x-ms-copy-source-authorization: <scheme> <signature>`	Valfritt. Anger auktoriseringsschemat och signaturen för kopieringskällan. Mer information finns i Auktorisera begäranden till Azure Storage. Endast schemabärare stöds för Microsoft Entra ID. Det här huvudet stöds i version 2020-10-02 och senare.
`x-ms-source-range`	Valfritt. Laddar bara upp byte för bloben i käll-URL:en i det angivna intervallet. Om detta inte anges laddas hela källblobinnehållet upp som ett enda tilläggsblock. Mer information finns i Ange områdesrubriken för Blob Storage-åtgärder .
`x-ms-source-content-md5`	Valfritt. En MD5-hash för innehållet i tilläggsblocket från URI:n. Denna hash används för att verifiera integriteten för tilläggsblocket under transport av data från URI:n. När du anger det här huvudet jämför lagringstjänsten hashen för det innehåll som har anlänt från copy-source med det här rubrikvärdet. Observera att denna MD5-hash inte lagras med bloben. Om de två hashvärdena inte matchar misslyckas åtgärden med felkoden 400 (felaktig begäran).
`x-ms-source-content-crc64`	Valfritt. En CRC64-hash av innehållet i tilläggsblocket från URI:n. Denna hash används för att verifiera integriteten för tilläggsblocket under transport av data från URI:n. När du anger det här huvudet jämför lagringstjänsten hashen för det innehåll som har anlänt från copy-source med det här rubrikvärdet. Observera att denna CRC64-hash inte lagras med bloben. Om de två hashvärdena inte matchar misslyckas åtgärden med felkoden 400 (felaktig begäran). Om både `x-ms-source-content-md5` - och `x-ms-source-content-crc64` -huvuden finns misslyckas begäran med 400 (felaktig begäran). Det här huvudet stöds i version 2019-02-02 eller senare.
`x-ms-encryption-scope`	Valfritt. Anger krypteringsomfånget som ska användas för att kryptera källinnehållet. Det här huvudet stöds i version 2019-02-02 eller senare.
`x-ms-lease-id:<ID>`	Krävs om bloben har ett aktivt lån. Om du vill utföra den här åtgärden på en blob med ett aktivt lån anger du det giltiga låne-ID:t för det här huvudet.
`x-ms-client-request-id`	Valfritt. Tillhandahåller ett klientgenererat, täckande värde med en teckengräns på 1 kibibyte (KiB) som registreras i loggarna när loggning har konfigurerats. Vi rekommenderar starkt att du använder det här huvudet för att korrelera aktiviteter på klientsidan med begäranden som servern tar emot. Mer information finns i Övervaka Azure Blob Storage.
`x-ms-blob-condition-maxsize`	Valfritt villkorsstyrt huvud. Den maximala längden i byte som tillåts för tilläggsbloben. `Append Block From URL` Om åtgärden gör att bloben överskrider den gränsen, eller om blobstorleken redan är större än det värde som anges i det här huvudet, misslyckas begäran med 412 (förhandsvillkoret misslyckades).
`x-ms-blob-condition-appendpos`	Valfritt villkorsstyrt huvud, som endast används för åtgärden `Append Block from URL` . Ett tal som anger byteförskjutningen som ska jämföras. `Append Block from URL` lyckas bara om tilläggspositionen är lika med det här talet. Om den inte är det misslyckas begäran med 412 (förhandsvillkoret misslyckades).

Den här åtgärden stöder användning av ytterligare villkorsstyrda rubriker för att säkerställa att API:et endast lyckas om ett angivet villkor uppfylls. Mer information finns i Ange villkorsstyrda rubriker för Blob Storage-åtgärder.

Begärandehuvuden (krypteringsnycklar som tillhandahålls av kunden)

Från och med version 2019-02-02 kan du ange följande rubriker på begäran för att kryptera en blob med en nyckel som kunden tillhandahåller. Kryptering med en nyckel som tillhandahålls av kunden (och motsvarande uppsättning rubriker) är valfritt.

Begärandehuvud	Beskrivning
`x-ms-encryption-key`	Krävs. Den Base64-kodade AES-256-krypteringsnyckeln.
`x-ms-encryption-key-sha256`	Krävs. Den Base64-kodade SHA256-hashen för krypteringsnyckeln.
`x-ms-encryption-algorithm: AES256`	Krävs. Anger vilken algoritm som ska användas för kryptering. Värdet för det här huvudet måste vara `AES256`.

Begärandetext

Begärandetexten innehåller innehållet i blocket.

Exempelbegäran

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock  HTTP/1.1  

Request Headers:  
x-ms-version: 2018-11-09  
x-ms-date: <date>  
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-65535
x-ms-blob-condition-appendpos: 2097152  
x-ms-blob-condition-maxsize: 4194304  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0 
If-Match: "0x8CB172A360EC34B"

Svarsåtgärder

Svaret innehåller en HTTP-statuskod och en uppsättning svarshuvuden.

Statuskod

En lyckad åtgärd returnerar statuskoden 201 (skapad). Information om statuskoder finns i Status och felkoder.

Svarshuvuden

Svaret för den här åtgärden innehåller följande rubriker. Svaret kan också innehålla ytterligare standard-HTTP-huvuden. Alla standardhuvuden överensstämmer med HTTP/1.1-protokollspecifikationen.

Svarsrubrik	Description
`Etag`	`ETag` Innehåller ett värde inom citattecken. Klienten använder värdet för att utföra villkorsstyrda `PUT` åtgärder med hjälp av begärandehuvudet `If-Match` .
`Last-Modified`	Datum/tid då bloben senast ändrades. Datumformatet följer RFC 1123. Mer information finns i Representation av datum-tidsvärden i rubriker. Alla skrivåtgärder på bloben (inklusive uppdateringar av blobens metadata eller egenskaper) ändrar blobens senast ändrade tid.
`Content-MD5`	Det här huvudet returneras så att klienten kan söka efter meddelandeinnehållsintegritet. Blob Storage beräknar värdet för det här huvudet. Det är inte nödvändigtvis samma värde som anges i begärandehuvudena. För version 2019-02-02 eller senare returneras det här huvudet endast när begäran har det här huvudet.
`x-ms-content-crc64`	För version 2019-02-02 eller senare. Det här huvudet returneras så att klienten kan söka efter meddelandeinnehållsintegritet. Blob Storage beräknar värdet för det här huvudet. Det är inte nödvändigtvis samma värde som anges i begärandehuvudena. Det här huvudet returneras när `x-ms-source-content-md5` rubriken inte finns i begäran.
`x-ms-request-id`	Det här huvudet identifierar unikt den begäran som gjordes och kan användas för att felsöka begäran.
`x-ms-version`	Anger vilken version av Blob Storage som används för att köra begäran. Det här huvudet returneras för begäranden mot version 2009-09-19 och senare.
`Date`	Ett UTC-datum/tid-värde som genererats av tjänsten som anger tidpunkten då svaret initierades.
`x-ms-blob-append-offset`	Det här svarshuvudet returneras endast för tilläggsåtgärder. Den returnerar förskjutningen som blocket checkades in med i byte.
`x-ms-blob-committed-block-count`	Antalet bekräftade block som finns i bloben. Du kan använda detta för att styra hur många fler tillägg som kan göras.
`x-ms-request-server-encrypted: true/false`	Version 2015-12-11 eller senare. Värdet för det här huvudet anges till `true` om innehållet i begäran har krypterats med hjälp av den angivna algoritmen. Annars är värdet inställt på `false`.
`x-ms-encryption-key-sha256`	Version 2019-02-02 eller senare. Det här huvudet returneras om begäran använde en kundtilldelad nyckel för kryptering. Klienten kan sedan se till att innehållet i begäran har krypterats med hjälp av den angivna nyckeln.
`x-ms-encryption-scope`	Version 2019-02-02 eller senare. Det här huvudet returneras om begäran använde ett krypteringsomfång. Klienten kan sedan se till att innehållet i begäran har krypterats med hjälp av krypteringsomfånget.

Exempelsvar

Response Status:  
HTTP/1.1 201 Created  

Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: <date>  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-blob-append-offset: 2097152  
x-ms-blob-committed–block-count: 1000

Auktorisering

Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. Du kan auktorisera åtgärden enligt beskrivningen Append Block From URL nedan.

Auktoriseringsinformationen i det här avsnittet gäller för kopieringsmålet. Mer information om kopieringskällans auktorisering finns i informationen för begärandehuvudet x-ms-copy-source.

Viktigt

Microsoft rekommenderar att du använder Microsoft Entra ID med hanterade identiteter för att auktorisera begäranden till Azure Storage. Microsoft Entra ID ger överlägsen säkerhet och användarvänlighet jämfört med auktorisering av delad nyckel.

Azure Storage stöder användning av Microsoft Entra ID för att auktorisera begäranden till blobdata. Med Microsoft Entra ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, programtjänstens huvudnamn eller en hanterad Azure-identitet. Säkerhetsobjektet autentiseras av Microsoft Entra ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.

Mer information om auktorisering med Microsoft Entra ID finns i Auktorisera åtkomst till blobar med Microsoft Entra ID.

Behörigheter

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra användare, grupp, hanterad identitet eller tjänstens huvudnamn ska anropa Append Block From URL åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som inkluderar den här åtgärden:

Azure RBAC-åtgärd:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action eller Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Minst privilegierad inbyggd roll:Storage Blob Data-deltagare

Mer information om hur du tilldelar roller med Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.

En signatur för delad åtkomst (SAS) ger säker delegerad åtkomst till resurser i ett lagringskonto. Med en SAS har du detaljerad kontroll över hur en klient kan komma åt data. Du kan ange vilken resurs klienten kan komma åt, vilka behörigheter de har till dessa resurser och hur länge SAS är giltigt.

Åtgärden Append Block From URL stöder tre typer av signaturer för delad åtkomst: SAS för användardelegering, sas för tjänsten och konto-SAS.

Vi rekommenderar att du använder Microsoft Entra autentiseringsuppgifter i stället för lagringskontonyckeln, vilket är enklare att kompromettera. Om din programdesign kräver signaturer för delad åtkomst använder du Microsoft Entra autentiseringsuppgifter för att skapa en SAS för användardelegering när det är möjligt.

När åtkomst med delad nyckel inte tillåts för lagringskontot tillåts inte en SAS-token för tjänsten eller en SAS-kontotoken för en begäran till Blob Storage. Mer information finns i Förstå hur nekande av delad nyckel påverkar SAS-token.

SAS för användardelegering

En SAS för användardelegering skyddas med Microsoft Entra autentiseringsuppgifter och även av de behörigheter som anges för SAS.

Append Block From URL Att anropa åtgärden med en SAS-token som delegerats till en container eller blobresurs kräver behörigheten Lägg till (a) eller Skriv (w) som en del av SAS-token för användardelegering:

Mer information om SAS för användardelegering finns i Skapa en SAS för användardelegering.

Tjänst-SAS

En tjänst-SAS skyddas med lagringskontonyckeln. En tjänst-SAS delegerar åtkomst till en resurs i en enda Azure Storage-tjänst, till exempel bloblagring.

Append Block From URL Att anropa åtgärden med hjälp av en SAS-token som delegerats till en container eller blobresurs kräver behörigheten Lägg till (a) eller Skriv (w) som en del av tjänstens SAS-token.

Mer information om sas-tjänsten finns i Skapa en tjänst-SAS.

Konto-SAS

Ett SAS-konto skyddas med lagringskontonyckeln. En konto-SAS delegerar åtkomst till resurser i en eller flera av lagringstjänsterna. Alla åtgärder som är tillgängliga via en tjänst eller sas för användardelegering är också tillgängliga via ett konto-SAS.

Följande tabell anger den signerade resurstypen och signerade behörigheter som ska anges när åtkomst delegeras:

Åtgärd	Signerad tjänst	Signerad resurstyp	Signerad behörighet
Lägg till blockera från URL	Blob (b)	Objekt (o)	Lägg till (a) eller skriv (w)

Mer information om kontots SAS finns i Skapa ett konto-SAS.

Kommentarer

Append Block From URL laddar upp ett block till slutet av en befintlig tilläggsblob. Datablocket är omedelbart tillgängligt när anropet har slutförts på servern. Högst 50 000 tillägg tillåts för varje tilläggsblob, där. Varje block kan ha olika storlek.

I följande tabell beskrivs de högsta tillåtna block- och blobstorlekarna efter tjänstversion:

Tjänstversion	Maximal blockstorlek (via `Append Block From URL`)	Maximal blobstorlek
Version 2022-11-02 och senare	100 MiB (förhandsversion)	Cirka 4,75 TiB (100 MiB × 50 000 block)
Versioner tidigare än 2022-11-02	4 MiB	Cirka 195 gibibyte (GiB) (4 MiB × 50 000 block)

I version 2020-10-02 och senare stöds Microsoft Entra ID auktorisering för kopieringsåtgärdens källa.

Append Block From URL lyckas bara om bloben redan finns.

Blobar som laddas upp med gör Append Block From URL inte block-ID:t tillgängliga, så du kan inte anropa Hämta blockeringslista mot en tilläggsblob. Om du gör det resulterar det i ett fel.

Du kan ange följande valfria villkorsstyrda rubriker för begäran:

x-ms-blob-condition-appendpos: Du kan ange den här rubriken till en byteförskjutning där klienten förväntar sig att lägga till blocket. Begäran lyckas bara om den aktuella förskjutningen matchar den som anges av klienten. Annars misslyckas begäran med felkoden 412 (förhandsvillkoret misslyckades).

Klienter som använder en enskild skrivare kan använda det här huvudet för att avgöra om en Append Block From URL åtgärd lyckades trots nätverksfel.
x-ms-blob-condition-maxsize: Klienter kan använda det här huvudet för att säkerställa att tilläggsåtgärder inte ökar blobstorleken utöver en förväntad maximal storlek i byte. Om villkoret misslyckas misslyckas begäran med felkoden 412 (förhandsvillkoret misslyckades).

Om du försöker ladda upp ett block som är större än den tillåtna storleken returnerar tjänsten HTTP-felkod 413 (begärandeentiteten är för stor). Tjänsten returnerar också ytterligare information om felet i svaret, inklusive den maximala blockstorleken som tillåts i byte. Om du försöker ladda upp fler än 50 000 block returnerar tjänsten felkoden 409 (konflikt).

Om bloben har ett aktivt lån måste klienten ange ett giltigt låne-ID för begäran för att kunna skriva ett block till bloben. Om klienten inte anger något låne-ID eller anger ett ogiltigt låne-ID returnerar Blob Storage felkoden 412 (förhandsvillkoret misslyckades). Om klienten anger ett låne-ID men bloben inte har något aktivt lån returnerar tjänsten felkoden 412.

Om du anropar Append Block From URL på en befintlig blockblob eller sidblob returnerar tjänsten felkoden 409 (konflikt). Om du anropar Append Block From URL en blob som inte finns returnerar tjänsten felkoden 404 (hittades inte).

Undvik duplicerade eller fördröjda tillägg

I ett scenario med en enskild skrivare kan klienten undvika duplicerade tillägg eller fördröjda skrivningar med hjälp av villkorsrubriken x-ms-blob-condition-appendpos för att kontrollera den aktuella förskjutningen. Klienten kan också undvika dubbletter eller fördröjningar genom att kontrollera ETag villkorligt med hjälp If-Matchav .

I ett scenario med flera skrivare kan varje klient använda villkorsstyrda rubriker. Detta kanske inte är optimalt för prestanda. För högsta samtidiga tilläggsdataflöde bör program hantera redundanta tillägg och fördröjda tillägg i programlagret. Program kan till exempel lägga till epoker eller sekvensnummer i de data som läggs till.

Mer information om priser för den angivna faktureringskategorin finns i Azure Blob Storage Prissättning.

Fakturering

Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via REST-API:et för Blob Storage eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner ackumuleras till exempel till en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Append Block From URL begäranden baserat på lagringskontotypen:

Åtgärd	Typ av lagringskonto	Faktureringskategori
Lägg till blockera från URL (målkonto¹)	Premium-blockblob Standard generell användning v2 Standard generell användning v1	Skrivåtgärder
Lägg till blockera från URL (källkonto²)	Premium-blockblob Standard generell användning v2 Standard generell användning v1	Läsåtgärder

¹Målkontot debiteras för en transaktion för att initiera skrivning.
²Källkontot ådrar sig en transaktion för varje läsbegäran till källan.

Dela via