Placera blockera från URL

Artikel
05/15/2024

Åtgärden Put Block From URL skapar ett nytt block som ska checkas in som en del av en blob där innehållet läse från en URL. Det här API:et är tillgängligt från och med version 2018-03-28.

Förfrågan

Du kan skapa begäran på Put Block From URL följande sätt. Vi rekommenderar att du använder HTTPS. 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=block&blockid=id`	HTTP/1.1

Emulerad lagringstjänstbegäran

När du gör en begäran mot den emulerade lagringstjänsten anger du emulatorns värdnamn och blobtjänstporten som 127.0.0.1:10000, följt av namnet på det emulerade lagringskontot:

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

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

URI-parametrar

Parameter	Beskrivning
`blockid`	Krävs. Ett giltigt Base64-strängvärde som identifierar blocket. Innan kodningen måste strängen vara mindre än eller lika med 64 byte i storlek. För en angiven blob måste längden på det angivna värdet för parametern `blockid` vara samma storlek för varje block. Obs! Base64-strängen måste vara URL-kodad.
`timeout`	Valfritt. Parametern `timeout` uttrycks i sekunder. Mer information finns i Ange tidsgränser för blobtjänståtgärder.

Begärandehuvuden

De obligatoriska och valfria begäranderubrikerna beskrivs i följande tabell:

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. För `Put Block From URL`måste versionen vara 2018-03-28 eller senare.
`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 0. När längden inte är 0 misslyckas åtgärden med statuskoden 400 (felaktig begäran).
`x-ms-copy-source:name`	Krävs. Anger url:en för källbloben. Värdet kan vara en URL på upp till 2 kibibyte (KiB) som anger en blob. Värdet ska vara URL-kodat, eftersom det visas i en begärande-URI. Källbloben måste vara antingen offentlig eller auktoriserad 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 är 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 ett ägarschema stöds för Microsoft Entra. Det här huvudet stöds i versionerna 2020-10-02 och senare.
`x-ms-source-range`	Valfritt. Laddar bara upp blobens byte i käll-URL:en i det angivna intervallet. Om det här huvudet inte anges laddas hela källblobinnehållet upp som ett enda block. Mer information finns i Ange intervallrubriken för Blob Service-åtgärder.
`x-ms-source-content-md5`	Valfritt. En MD5-hash för blockinnehållet från URI:n. Den här hashen används för att verifiera blockets integritet under transporten av data från URI:n. När det här huvudet anges jämför lagringstjänsten hash-värdet för det innehåll som har kommit från kopieringskällan med det här rubrikvärdet. Obs! Den här MD5-hashen lagras inte 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 för blockinnehållet från URI:n. Den här hashen används för att verifiera blockets integritet under transporten av data från URI:n. När det här huvudet anges jämför lagringstjänsten hash-värdet för det innehåll som har kommit från kopieringskällan med det här rubrikvärdet. Obs! Den här CRC64-hashen lagras inte 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 versionerna 2019-02-02 och 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 versionerna 2019-02-02 och 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 loggningen 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.

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

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

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

Inga.

Exempelbegäran

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

Svarsåtgärder

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

Statuskod

En lyckad åtgärd returnerar statuskoden 201 (skapad).

Mer 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 HTTP-standardhuvuden. Alla standardhuvuden överensstämmer med HTTP/1.1-protokollspecifikationen.

Svarsrubrik	Description
`Content-MD5`	Returneras så att klienten kan söka efter meddelandeinnehållsintegritet. Värdet för det här huvudet beräknas av Blob Storage. Det är inte nödvändigtvis samma som värdet som anges i begärandehuvudena. För versionerna 2019-02-02 och senare returneras det här huvudet endast när begäran har det här huvudet.
`x-ms-content-crc64`	För versionerna 2019-02-02 och senare. Returneras så att klienten kan söka efter meddelandeinnehållsintegritet. Värdet för det här huvudet beräknas av Blob Storage. Det är inte nödvändigtvis samma som värdet som anges i begärandehuvudena. Returneras när `x-ms-source-content-md5` rubriken inte finns i begäran.
`x-ms-request-id`	Identifierar begäran som gjordes unikt och du kan använda den för att felsöka begäran. Mer information finns i Felsöka API-åtgärder.
`x-ms-version`	Blob Storage-versionen som användes för att köra begäran.
`Date`	Ett UTC-datum/tid-värde som genereras av tjänsten, vilket anger den tid då svaret initierades.
`x-ms-request-server-encrypted: true/false`	Version 2015-12-11 och senare. Värdet för det här huvudet anges till `true` om innehållet i blocket krypteras med den angivna algoritmen. Annars är värdet inställt på `false`.
`x-ms-encryption-key-sha256`	Version 2019-02-02 och senare. Returneras om begäran använde en kundtilldelad nyckel för kryptering, så att klienten kan se till att innehållet i begäran krypteras med hjälp av den angivna nyckeln.
`x-ms-encryption-scope`	Version 2019-02-02 och senare. Returneras om begäran använde ett krypteringsomfång, så att klienten kan se till att innehållet i begäran krypteras korrekt med hjälp av krypteringsomfånget.
`x-ms-client-request-id`	Kan användas för att felsöka begäranden och motsvarande svar. Värdet för det här huvudet är lika med värdet `x-ms-client-request-id` för huvudet om det finns i begäran och värdet inte innehåller fler än 1 024 synliga ASCII-tecken. `x-ms-client-request-id` Om rubriken inte finns i begäran visas den inte i svaret.

Exempelsvar

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Auktorisering

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

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 Put 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/blobar/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 Put 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.

Put 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 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.

Att anropa åtgärden Put Block From URL med hjälp av en SAS-token som delegerats till en container eller blobresurs kräver behörigheten 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
Placera blockera från URL	Blob (b)	Objekt (o)	Skriva (w)

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

Kommentarer

Put Block From URL laddar upp ett block för framtida inkludering i en blockblob. En blockblob kan innehålla högst 50 000 block. Varje block kan ha olika storlek. Den maximala storleken för ett block som laddas upp med Put Block From URL är 100 mebibyte (MiB). Information om hur du laddar upp större block (upp till 4 000 MiB) finns i Placera block.

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

En blob kan ha högst 100 000 obekräftade block när som helst. Om det maximala värdet överskrids returnerar tjänsten statuskoden 409 (RequestEntityTooLargeBlockCountExceedsLimit).

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

Tjänstversion	Maximal blockstorlek (via `Put Block From URL`)	Maximal blobstorlek (via `Put Block List`)	Maximal blobstorlek via en enda skrivåtgärd (via `Put Blob From URL`)
Version 2020-04-08 och senare	4 000 MiB	Cirka 190,7 tebibyte (TiB) (4 000 MiB-× 50 000 block)	5 000 MiB
Tidigare versioner än 2020-04-08	100 MiB	Cirka 4,75 TiB (100 MiB × 50 000 block)	256 MiB

När du har laddat upp en uppsättning block kan du skapa eller uppdatera bloben på servern från den här uppsättningen genom att anropa åtgärden Placera blocklista . Varje block i uppsättningen identifieras av ett block-ID som är unikt i den bloben. Block-ID:t är begränsade till en viss blob, så olika blobar kan ha block med samma ID:t.

Om du anropar Put Block From URL en blob som ännu inte finns skapas en ny blockblob med innehållslängden 0. Den här bloben räknas upp av List Blobs åtgärden om alternativet include=uncommittedblobs anges. Blocket eller blocken som du laddade upp checkas inte in förrän du anropar Put Block List den nya bloben. En blob som skapats på det här sättet underhålls på servern i en vecka. Om du inte har lagt till fler block eller checkat in block i bloben inom den tidsperioden är bloben skräpinsamling.

Ett block som har laddats upp med åtgärden Put Block From URL blir inte en del av en blob förrän den har checkats in med Put Block List. Innan Put Block List anropas för att checka in den nya eller uppdaterade bloben returnerar alla anrop till Get Blob blobinnehållet utan att inkludera det ogenomförda blocket.

Om du laddar upp ett block som har samma block-ID som ett annat block som ännu inte har checkats in, checkas det senast uppladdade blocket med det ID:t in vid nästa lyckade Put Block List åtgärd.

När Put Block List anropas checkas alla oangivna block som anges i blocklistan in som en del av den nya bloben. Alla icke-utelämnade block som inte har angetts i blocklistan för bloben är skräp som samlas in och tas bort från Blob Storage. Alla icke-utelämnade block samlas också in skräp om det inte finns några lyckade anrop till Put Block From URL eller Put Block List på samma blob inom en vecka efter den senaste lyckade Put Block From URL åtgärden. Om Put Blob anropas på bloben samlas alla obekräftade block in.

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

För en angiven blob måste alla block-ID:t vara samma längd. Om ett block laddas upp med ett block-ID med en annan längd än block-ID:na för befintliga obekräftade block returnerar tjänsten felsvarskoden 400 (felaktig begäran).

Anropet Put Block From URL uppdaterar inte den senaste ändrade tiden för en befintlig blob.

Ett fel returneras när en sidblob anropas Put Block From URL .

Om du anropar Put Block From URL en "arkivblob" returneras ett fel, och om du anropar den på en hot blob eller cool så ändras inte blobnivån.

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 till exempel tillfaller en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Put Block From URL begäranden baserat på lagringskontotypen:

Åtgärd	Typ av lagringskonto	Faktureringskategori
Placera Blockera från URL (målkonto¹)	Premium-blockblob Standard generell användning v2 Standard generell användning v1	Skrivåtgärder
Placera 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ällobjektet.

Om käll- och målkontona finns i olika regioner (till exempel USA, norra och USA, södra) debiteras dessutom bandbredden som används för att överföra begäran till källlagringskontot som utgående. Utgående mellan konton i samma region är kostnadsfri.

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

Dela via