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ärandehuvudena.

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 har gjorts mot version 2009-09-19 eller senare.
Date Ett DATUM-/tidsvärde för UTC 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 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. 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 rubriken om det finns i begäran och värdet inte innehåller fler än 1 024 synliga ASCII-tecken. Om rubriken x-ms-client-request-id 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.

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 hjälp av Microsoft Entra ID.

Behörigheter

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra användare, grupp eller tjänstens huvudnamn ska kunna anropa Put Block åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som innehåller den här åtgärden:

Mer information om hur du tilldelar roller med hjälp av 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 statuskod 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 blockeringslista . Varje block i uppsättningen identifieras med 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 checkat in block i bloben inom den tidsperioden är bloben skräpinsamling.

Ett block som har laddats upp med åtgärden Put Block 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, 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 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 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 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:t för befintliga obekräftade 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ärandeentitet för stor). Tjänsten returnerar också ytterligare information om felet i svaret, inklusive den maximala tillåtna blockstorleken, i byte.

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

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

Om du anropar Put Block en arkiverad blob returneras ett fel, och om du anropar den på en hot eller cool bloben ä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 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ärder

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

Se även

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