Placera block

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

Förfrågan

Begäran Put Block kan konstrueras på 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=block&blockid=id HTTP/1.1

Emulerad Storage-tjänst-URI

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 Azure Storage Emulator för utveckling och testning.

URI-parametrar

Parameter Beskrivning
blockid Krävs. Ett giltigt Base64-strängvärde som identifierar blocket. Före kodning måste strängen vara mindre än eller lika med 64 byte i storlek.

För en viss blob måste längden på det värde som anges för parametern blockid ha samma storlek för varje block.

Observera att 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.

Rubriker för begäran

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 att 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 Services.
Content-Length Krävs. Längden på blockinnehållet i byte. Blocket måste vara mindre än eller lika med 4 000 MiB i storlek för version 2019-12-12 och senare. Se Anmärkningar 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.

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

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 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 eller 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 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. Ger ett klientgenererat, täckande värde med en gräns på 1 KiB-tecken som registreras i analysloggarna när loggning av lagringsanalys är aktiverat. Användning av det här huvudet rekommenderas starkt för korrelering av aktiviteter på klientsidan med begäranden som tas emot av servern. Mer information finns i Om Lagringsanalys loggning och Azure-loggning: Använda loggar för att spåra Storage begäranden.

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.

Exempelförfrågan

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.

Svarsrubriker

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 Beskrivning
Content-MD5 Det här huvudet returneras så att klienten kan söka efter meddelandets innehållsintegritet. Värdet för det här huvudet beräknas av Blob-tjänsten. 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 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-tjänsten. 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 Det här huvudet identifierar unikt den begäran som gjordes och kan användas för att felsöka begäran. Mer information finns i Felsöka API-åtgärder.
x-ms-version Anger vilken version av Blob-tjänsten 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-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 den angivna algoritmen och false annars.
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, 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 eller 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 krypteringsomfånget.
x-ms-client-request-id Det här huvudet 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 för x-ms-client-request-id huvudet om det finns i begäran och värdet är högst 1 024 synliga ASCII-tecken. x-ms-client-request-id Om rubriken inte finns i begäran visas inte det här huvudet 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

Den här åtgärden kan anropas av kontoägaren och av alla som har en signatur för delad åtkomst som har behörighet att skriva till den här bloben eller dess container.

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 maximala block- och blobstorlekar som tillåts av tjänstversionen:

Tjänstversion Maximal blockstorlek (via Put Block) Maximal blobstorlek (via Placera blocklista) Maximal blobstorlek via en skrivåtgärd (via Put Blob)
Version 2019-12-12 och senare 4000 MiB Cirka 190,7 TiB (4 000 MiB X 50 000 block) 5 000 MiB (förhandsversion)
Version 2016-05-31 till och med version 2019-07-07 100 MiB Cirka 4,75 TiB (100 MiB X 50 000 block) 256 MiB
Versioner före 2016-05-31 4 MiB Cirka 195 GiB (4 MiB X 50 000 block) 64 MiB

Det maximala antalet obekräftade block som kan associeras med en blob är 100 000. Om det maximala värdet ö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 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 checkade block i bloben inom den tidsperioden samlas bloben in.

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 samlas in och tas bort från Blob-tjänsten. Alla icke-utelämnade block kommer också att 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 icke-utelämnade block in.

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-tjänsten statuskoden 412 (villkoret misslyckades). Om klienten anger ett låne-ID men bloben inte har något aktivt lån returnerar Blob-tjänsten även statuskod 412 (villkoret misslyckades).

För en viss 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 och senare, större än 100 MiB för version 2016-05-31 och senare, och 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 blockstorleken som tillåts i byte.

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

Om du anropar Put Block en sidblob returneras ett fel.

Om du anropar Put Block en arkiverad blob returneras ett fel och bloben Hot/Cool ändrar inte blobnivån.

Se även

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