Dela via

Placera block

  • Artikel

Åtgärden Put Block skapar ett nytt block som ska checkas in som en del av en blob.

Förfrågan

Du kan skapa begäran på Put Block 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:10000fö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 den kodas måste strängen vara mindre än eller lika med 64 byte i storlek.

För en angiven blob måste längden på värdet för parametern blockid ha 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 Blob Service-åtgärder.

Begärandehuvuden

De obligatoriska och valfria begärandehuvudena 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.
Content-Length Krävs. Längden på blockinnehållet i byte. Blocket måste vara mindre än eller lika med 4 000 mebibyte (MiB) i storlek för version 2019-12-12 och senare. Se avsnittet Kommentarer för begränsningar i äldre versioner.

När längden inte anges misslyckas åtgärden med statuskoden 411 (längd krävs).
Content-MD5 Valfritt. En MD5-hash för blockinnehållet. Den här hashen används för att verifiera blockets integritet under transporten. När det här huvudet anges jämför lagringstjänsten hashen för det innehåll som har anlänt 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-content-crc64 Valfritt. En CRC64-hash för blockinnehållet. Den här hashen används för att verifiera blockets integritet under transporten. När det här huvudet anges jämför lagringstjänsten hashen för det innehåll som har anlänt med det här rubrikvärdet.

Obs! Denna CRC64-hash lagras inte med bloben.

Om de två hashvärdena inte matchar misslyckas åtgärden med felkoden 400 (felaktig begäran).

Om både Content-MD5- och x-ms-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 innehållet i begäran. 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 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.

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

Från och med version 2019-02-02 kan följande huvuden anges i begäran om att kryptera en blob med en nyckel som tillhandahålls av kunden. 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=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 14:37:35 GMT  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 1048576

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

Svarsrubrik Description
Content-MD5 Returneras så att klienten kan söka efter meddelandets innehållsintegritet. Värdet för det här huvudet beräknas av Blob Storage, och det är inte nödvändigtvis samma värde 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 version 2019-02-02 och senare returneras det här huvudet så att klienten kan söka efter meddelandets innehållsintegritet. Värdet för det här huvudet beräknas av Blob Storage, och det är inte nödvändigtvis samma värde som anges i begäranderubrikerna.

Det här huvudet returneras när 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 Anger den Blob Storage-version som användes för att köra begäran. Det här huvudet returneras för begäranden som gjordes mot version 2009-09-19 eller senare.
Date Ett UTC-datum/tid-värde som genereras av tjänsten, vilket anger när 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 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 och senare. Det här huvudet returneras om begäran använde en nyckel som tillhandahålls av kunden 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. Det här huvudet returneras om begäran använde ett krypteringsomfång, så att klienten kan se till att innehållet i begäran krypteras med hjälp av krypteringsomfånget.
x-ms-client-request-id Kan användas för att felsöka begäranden och deras 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 finns den inte i svaret.

Exempelsvar

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 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 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 kunna anropa Put Block åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som inkluderar den här åtgärden:

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

Kommentarer

Put Block laddar upp ett block för framtida inkludering i en blockblob. Varje block i en blockblob kan ha olika storlek. En blockblob kan innehålla högst 50 000 bekräftade block.

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

Tjänstversion Maximal blockstorlek (via Put Block) Maximal blobstorlek (via Put Block List) Maximal blobstorlek via en enda skrivåtgärd (via Put Blob)
Version 2019-12-12 och senare 4 000 MiB Cirka 190,7 tebibyte (TiB) (4 000 MiB-× 50 000 block) 5 000 MiB
Versioner 2016-05-31 till och med 2019-07-07 100 MiB Cirka 4,75 TiB (100 MiB × 50 000 block) 256 MiB
Tidigare versioner än 2016-05-31 4 MiB Cirka 195 gibibyte (GiB) (4 MiB × 50 000 block) 64 MiB

Det maximala antalet obekräftade block som kan associeras med en blob är 100 000. Om det här antalet överskrids returnerar tjänsten statuskoden 409 (RequestEntityTooLargeBlockCountExceedsLimit).

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 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 include=uncommittedblobs alternativet har angetts. Blocket eller blocken som du laddar upp checkas inte in förrän du anropar Put Block List den nya bloben. En blob som skapas på det här sättet underhålls på servern i en vecka. Om du inte har lagt till fler block eller allokerade block i bloben inom den tidsperioden är bloben skräpinsamling.

Ett block som har laddats upp med Put Block åtgärden blir inte en del av en blob förrän det 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 det ogenomförda blocket inkluderas.

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

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

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

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

Om du försöker ladda upp ett block som är större än 4 000 MiB för version 2019-12-12 eller senare, större än 100 MiB för version 2016-05-31 eller senare, eller större än 4 MiB för äldre versioner, returnerar tjänsten statuskod 413 (begärandeentiteten är för stor). Tjänsten returnerar också ytterligare information om felet i svaret, inklusive den maximala tillåtna blockstorleken, i byte.

Anrop Put Block uppdaterar inte den senaste ändringstiden för en befintlig blob.

Om du anropar Put Block på en sidblob returneras ett fel.

Om du anropar Put Block på en arkiverad blob 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 ackumuleras till exempel till en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Put Block begäranden baserat på lagringskontotypen:

Åtgärd Typ av lagringskonto Faktureringskategori
Placera block Premium-blockblob
Standard generell användning v2
Standard generell användning v1		 Skrivåtgärder1

1Put Block åtgärder skriver block till tillfällig lagring med lagringskontots standardåtkomstnivå. Om du till exempel laddar upp en blob till arkivnivån debiteras alla Put Block åtgärder som ingår i uppladdningen som skrivåtgärder baserat på lagringskontots standardåtkomstnivå, inte målnivån. Put Block List och Put Blob -åtgärder debiteras dock som skrivåtgärder baserat på blobens målnivå.

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

Se även

Auktorisera begäranden till Azure Storage
Status- och felkoder
Felkoder för Blob Service
Ange tidsgränser för blobtjänståtgärder