Blokkerings lijst plaatsen

Put Block ListMet de bewerking wordt een BLOB geschreven door de lijst met blok-id's op te geven waaruit de blob is opgebouwd. Om te kunnen worden geschreven als onderdeel van een blob, moet een blok zijn geschreven naar de server in een eerdere put -bewerking.

U kunt aanroepen Put Block List om een BLOB bij te werken door alleen de blokken te uploaden die zijn gewijzigd, waarna de nieuwe en bestaande blokken samen worden doorgevoerd. U kunt dit doen door op te geven of u een blok wilt door voeren vanuit de lijst vastgelegde blok kering of van de niet-vastgelegde blok kering, of dat u de laatst geüploade versie van het blok wilt door voeren, ongeacht de lijst waarvan het deel kan uitmaken.

Aanvraag

De Put Block List aanvraag kan als volgt worden samengesteld. HTTPS wordt aanbevolen. Vervang MyAccount door de naam van uw opslag account:

URI voor de methode PUT-aanvraag HTTP-versie
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1

URI voor geëmuleerde opslag service

Bij het uitvoeren van een aanvraag voor de geëmuleerde opslag service, geeft u de hostnaam van de emulator en Blob service poort op als 127.0.0.1:10000 , gevolgd door de naam van het geëmuleerde opslag account:

URI voor de methode PUT-aanvraag HTTP-versie
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist HTTP/1.1

De opslag emulator ondersteunt alleen BLOB-grootten tot 2 GiB.

Zie de Azure Storage-emulator gebruiken voor ontwikkeling en testenvoor meer informatie.

URI-parameters

De volgende aanvullende para meters kunnen worden opgegeven voor de aanvraag-URI.

Parameter Beschrijving
timeout Optioneel. De timeout para meter wordt uitgedrukt in seconden. Zie time-outs instellen voor BLOB-service bewerkingenvoor meer informatie.

Aanvraagheaders

In de volgende tabel worden de vereiste en optionele aanvraag headers beschreven.

Aanvraagkoptekst Beschrijving
Authorization Vereist. Hiermee geeft u het autorisatie schema, de account naam en de hand tekening. Zie aanvragen voor Azure Storage autoriserenvoor meer informatie.
Date of x-ms-date Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie aanvragen voor Azure Storage autoriserenvoor meer informatie.
x-ms-version Vereist voor alle geautoriseerde aanvragen. Hiermee geeft u de versie op van de bewerking die moet worden gebruikt voor deze aanvraag. Zie versie beheer voor de Azure Storage servicesvoor meer informatie.
Content-Length Vereist. De lengte van de aanvraag inhoud in bytes. Deze header verwijst naar de lengte van de inhoud van de lijst met blokken, niet van de blob zelf.
Content-MD5 Optioneel. Een MD5-hash van de aanvraag inhoud. Deze hash wordt gebruikt om de integriteit van de aanvraag inhoud tijdens het Trans Port te controleren. Als de twee hashes niet overeenkomen, mislukt de bewerking met fout code 400 (ongeldige aanvraag).

Deze header is gekoppeld aan de aanvraag inhoud en niet met de inhoud van de blob zelf.
x-ms-content-crc64 Optioneel. Een crc64-hash van de aanvraag inhoud. Deze hash wordt gebruikt om de integriteit van de aanvraag inhoud tijdens het Trans Port te controleren. Als de twee hashes niet overeenkomen, mislukt de bewerking met fout code 400 (ongeldige aanvraag).

Deze header is gekoppeld aan de aanvraag inhoud en niet met de inhoud van de blob zelf.

Als de headers content-MD5 en x-MS-content-crc64 aanwezig zijn, mislukt de aanvraag met een 400 (ongeldige aanvraag).

Deze header wordt ondersteund in versions2019-02-02 of hoger.
x-ms-blob-cache-control Optioneel. Hiermee stelt u het cache-besturings element van de blob. Indien opgegeven, wordt deze eigenschap opgeslagen met de BLOB en geretourneerd met een lees aanvraag.

Als deze eigenschap niet is opgegeven met de aanvraag, wordt deze voor de BLOB gewist als de aanvraag is voltooid.
x-ms-blob-content-type Optioneel. Hiermee stelt u het inhouds type van de blob. Indien opgegeven, wordt deze eigenschap opgeslagen met de BLOB en geretourneerd met een lees aanvraag.

Als het inhouds type niet is opgegeven, wordt het ingesteld op het standaard type application/octet-stream .
x-ms-blob-content-encoding Optioneel. Hiermee stelt u de inhouds codering van de blob. Indien opgegeven, wordt deze eigenschap opgeslagen met de BLOB en geretourneerd met een lees aanvraag.

Als deze eigenschap niet is opgegeven met de aanvraag, wordt deze voor de BLOB gewist als de aanvraag is voltooid.
x-ms-blob-content-language Optioneel. De inhouds taal van de BLOB instellen. Indien opgegeven, wordt deze eigenschap opgeslagen met de BLOB en geretourneerd met een lees aanvraag.

Deze eigenschap is niet opgegeven met de aanvraag en wordt vervolgens voor de BLOB gewist als de aanvraag is voltooid.
x-ms-blob-content-md5 Optioneel. Een MD5-hash van de blob-inhoud. Deze hash wordt niet gevalideerd omdat de hashes voor de afzonderlijke blokken zijn gevalideerd toen elke upload werd verzonden.

Met de bewerking BLOB ophalen wordt de waarde van deze header geretourneerd in de antwoord header content-MD5.

Als deze eigenschap niet is opgegeven met de aanvraag, wordt deze voor de BLOB gewist als de aanvraag is voltooid.
x-ms-meta-name:value Optioneel. Door de gebruiker gedefinieerde naam/waarde-paren die zijn gekoppeld aan de blob.

Vanaf versie 2009-09-19 moeten meta gegevens namen voldoen aan de naamgevings regels voor C#-id's.
x-ms-encryption-scope Optioneel. Hiermee wordt het versleutelings bereik aangegeven dat moet worden gebruikt om de BLOB te versleutelen. Deze waarde moet overeenkomen met het versleutelings bereik dat wordt gebruikt voor het versleutelen van alle blokken die worden doorgevoerd. Deze header wordt ondersteund in versie 2019-02-02 of hoger.
x-ms-tags Optioneel. Hiermee stelt u de opgegeven Tags voor de query teken reeks code ring in op de blob. Zie de opmerkingen voor aanvullende informatie. Ondersteund in versie 2019-12-12 en hoger.
x-ms-lease-id:<ID> Vereist als de BLOB een actieve lease heeft. Als u deze bewerking wilt uitvoeren op een blob met een actieve lease, geeft u de geldige lease-ID voor deze header op.
x-ms-client-request-id Optioneel. Biedt een door de client gegenereerde, ondoorzichtige waarde met een limiet van 1 KiB tekens die wordt vastgelegd in de analyse Logboeken wanneer opslag analyse logboek registratie is ingeschakeld. Het gebruik van deze header wordt ten zeerste aanbevolen voor het correleren van activiteiten aan clientzijde met aanvragen die door de server worden ontvangen. Zie voor meer informatie over Opslaganalyse logboek registratie en logboek registratie van Azure: Logboeken gebruiken om opslag aanvragen bij te houden.
x-ms-blob-content-disposition Optioneel. Hiermee stelt u de koptekst van de BLOB Content-Disposition . Beschikbaar voor versie 2013-08-15 en hoger.

Content-DispositionIn het veld koptekst wordt extra informatie over het verwerken van de reactie Payload en kunnen ook worden gebruikt om aanvullende meta gegevens toe te voegen. Als deze eigenschap is ingesteld op attachment , geeft dit aan dat de gebruiker-agent de reactie niet moet weer geven, maar in plaats daarvan een dialoog venster Opslaan als weer te geven.

Het antwoord van de bewerkingen Get BLOB en Eigenschappen van BLOB ophalen omvat de content-disposition-header.
x-ms-access-tier Optioneel. Versie 2018-11-09 en nieuwer. Hiermee wordt aangegeven welke laag moet worden ingesteld op een blob. Voor blok-blobs wordt alleen ondersteund in Blob Storage-of General Purpose v2-accounts met versie 2018-11-09 en hoger. Geldige waarden voor blok-BLOB-lagen zijn Hot / Cool / Archive . Zie opslag lagen warm, cool en Archivevoor gedetailleerde informatie over de blok-BLOB-laag.

Met deze bewerking wordt ook het gebruik van voorwaardelijke kopteksten ondersteund om de blokkerings lijst alleen door te voeren als aan een opgegeven voor waarde is voldaan. Zie voorwaardelijke headers opgeven voor BLOB-service bewerkingenvoor meer informatie.

Aanvraag headers (door de klant verschafte versleutelings sleutels)

Vanaf versie 2019-02-02 kunnen de volgende headers worden opgegeven voor de aanvraag om een BLOB te versleutelen met een door de klant opgegeven sleutel. Versleuteling met een door de klant opgegeven sleutel (en de bijbehorende set kopteksten) is optioneel.

Aanvraagheader Beschrijving
x-ms-encryption-key Vereist. De met base64 gecodeerde AES-256-versleutelings sleutel.
x-ms-encryption-key-sha256 Vereist. De met base64 gecodeerde SHA256-hash van de versleutelings sleutel.
x-ms-encryption-algorithm: AES256 Vereist. Hiermee geeft u de algoritme op die moet worden gebruikt voor versleuteling. De waarde van deze header moet zijn AES256 .

Aanvraagbody

In de hoofd tekst van de aanvraag kunt u opgeven welke blokkerings lijst het Blob service moet controleren op het aangevraagde blok. Op deze manier kunt u een bestaande BLOB bijwerken door afzonderlijke blokken in te voegen, te vervangen of te verwijderen, in plaats van de hele BLOB opnieuw te uploaden. Zodra u de gewijzigde blok keringen of blokken hebt geüpload, kunt u een nieuwe versie van de BLOB door voeren door de nieuwe blokken toe te voegen aan de bestaande blokken die u wilt blijven gebruiken.

Als u een BLOB wilt bijwerken, kunt u opgeven dat de service moet zoeken naar een blok-ID in de lijst vastgelegde blokken, in de lijst met niet-vastgelegde blokken of eerst in de lijst met niet-vastgelegde blokken en vervolgens in de lijst vastgelegde blokken. Om aan te geven welke benadering u moet gebruiken, geeft u de blok-ID binnen het juiste XML-element op in de aanvraag tekst, als volgt:

  • Geef de blok-ID binnen het Committed element op om aan te geven dat de BLOB service alleen de vastgelegde blokkerings lijst voor het benoemde blok moet doorzoeken. Als het blok niet is gevonden in de lijst vastgelegde blokken, wordt het niet geschreven als onderdeel van de BLOB en retourneert de Blob service status code 400 (ongeldige aanvraag).

  • Geef de blok-ID binnen het Uncommitted element op om aan te geven dat de BLOB service alleen de niet-vastgelegde blokkerings lijst voor het benoemde blok moet doorzoeken. Als het blok niet is gevonden in de lijst met niet-vastgelegde blokken, wordt het niet als onderdeel van de BLOB geschreven en retourneert de Blob service status code 400 (ongeldige aanvraag).

  • Geef de blok-ID binnen het Latest element op om aan te geven dat de BLOB service eerst moet zoeken in de lijst met niet-vastgelegde blokken. Als het blok wordt gevonden in de lijst die niet is doorgevoerd, is die versie van het blok het meest recent en moet het naar de BLOB worden geschreven. Als het blok niet is gevonden in de lijst met niet-vastgelegde, moet de service in de lijst vastgelegde blokken zoeken naar het benoemde blok en dat blok naar de BLOB schrijven als deze is gevonden.

De aanvraag tekst voor deze versie van Put Block List maakt gebruik van de volgende XML-indeling:

<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Committed>first-base64-encoded-block-id</Committed>  
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>  
  <Latest>third-base64-encoded-block-id</Latest>  
  ...  
</BlockList>  
  

Voorbeeldaanvraag

Stel dat Put Block List u drie blokken hebt geüpload die u nu wilt door voeren om te demonstreren. In het volgende voor beeld wordt een nieuwe BLOB door gegeven door aan te geven dat de meest recente versie van elk opgegeven blok moet worden gebruikt. Het is niet nodig om te weten of deze blokken al zijn doorgevoerd.

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Latest>AAAAAA==</Latest>  
  <Latest>AQAAAA==</Latest>  
  <Latest>AZAAAA==</Latest>  
</BlockList>  
  

Ga vervolgens na of u de BLOB wilt bijwerken. De nieuwe BLOB heeft de volgende wijzigingen:

  • Een nieuw blok met ID ANAAAA== . Dit blok moet eerst worden geüpload met een aanroep naar een put-blok en wordt weer gegeven in de lijst van niet-vastgelegde blokken tot het aanroepen van Put Block List .

  • Een bijgewerkte versie van het blok met ID AZAAAA== . Dit blok moet eerst worden geüpload met een aanroep naar een put-blok en wordt weer gegeven in de lijst van niet-vastgelegde blokken tot het aanroepen van Put Block List .

  • Het blok met de ID verwijderen AAAAAA== . Aangezien dit blok niet is opgenomen in de volgende aanroep naar Put Block List , wordt het blok in feite verwijderd uit de blob.

In het volgende voor beeld ziet u de aanroep voor Put Block List het bijwerken van de blob:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Uncommitted>ANAAAA==</Uncommitted>  
  <Committed>AQAAAA==</Committed>  
  <Uncommitted>AZAAAA==</Uncommitted>  
</BlockList>  
  

Antwoord

Het antwoord bevat een HTTP-status code en een set antwoord headers.

Statuscode

Met een geslaagde bewerking wordt de status code 201 (gemaakt) geretourneerd.

Zie status-en fout codesvoor meer informatie over status codes.

Antwoordheaders

Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord kan ook aanvullende standaard-HTTP-headers bevatten. Alle standaard headers voldoen aan de specificatie van het HTTP/1.1-protocol.

Antwoord Beschreven
ETag De entiteits code bevat een waarde die de client kan gebruiken om voorwaardelijke bewerkingen uit te voeren met GET/PUT behulp van de If-Match aanvraag header. Als de aanvraag versie 2011-08-18 of hoger is, is de ETag-waarde tussen aanhalings tekens.
Last-Modified De datum/tijd waarop de BLOB voor het laatst is gewijzigd. De datum notatie volgt RFC 1123. Zie de weer gave van Date-Time waarden in koptekstenvoor meer informatie.

Elke bewerking die de BLOB wijzigt, met inbegrip van een update van de meta gegevens of eigenschappen van de blob, wijzigt het tijdstip van de laatste wijziging van de blob.
Content-MD5 Deze header wordt geretourneerd, zodat de client kan controleren op integriteit van berichten inhoud. Deze header verwijst naar de inhoud van de aanvraag, wat in dit geval de lijst met blokken is, en niet de inhoud van de blob zelf. Voor versions2019-02-02 of hoger wordt deze header alleen geretourneerd wanneer de aanvraag deze header bevat.
x-ms-content-crc64 Voor versie 2019-02-02 en hoger wordt deze header geretourneerd, zodat de client kan controleren op integriteit van bericht inhoud. Deze header verwijst naar de inhoud van de aanvraag, wat in dit geval de lijst met blokken is, en niet de inhoud van de blob zelf.

Deze header wordt geretourneerd wanneer Content-md5 de header niet aanwezig is in de aanvraag.
x-ms-request-id Deze header identificeert de aanvraag die is ingediend en kan worden gebruikt voor het oplossen van problemen met de aanvraag. Zie API-bewerkingen voor problemen oplossenvoor meer informatie.
x-ms-version Hiermee wordt de versie van de Blob service aangegeven die wordt gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn gemaakt met versie 2009-09-19 en hoger.
Date Een UTC-datum/tijd-waarde die wordt gegenereerd door de service die het tijdstip aangeeft waarop het antwoord is geïnitieerd.
x-ms-request-server-encrypted: true/false Versie 2015-12-11 of nieuwer. De waarde van deze header wordt ingesteld op true als de inhoud van de aanvraag is versleuteld met het opgegeven algoritme en false anders.
x-ms-encryption-key-sha256 Versie 2019-02-02 of nieuwer. Deze header wordt geretourneerd als voor de aanvraag een door de klant geleverde sleutel voor versleuteling is gebruikt, zodat de client kan garanderen dat de inhoud van de aanvraag wordt versleuteld met de opgegeven sleutel.
x-ms-encryption-scope Versie 2019-02-02 of nieuwer. Deze header wordt geretourneerd als de aanvraag een versleutelings bereik heeft gebruikt, zodat de client kan garanderen dat de inhoud van de aanvraag is versleuteld met het versleutelings bereik.
x-ms-version-id: <DateTime> Versie 2019-12-12 en nieuwer. Deze header retourneert een ondoorzichtige DateTime waarde waarmee de BLOB op unieke wijze wordt geïdentificeerd. De waarde van deze header geeft de versie van de BLOB aan en kan worden gebruikt in volgende aanvragen voor toegang tot de blob.
x-ms-client-request-id Deze header kan worden gebruikt om problemen met aanvragen en bijbehorende antwoorden op te lossen. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id koptekst als deze in de aanvraag aanwezig is en de waarde Maxi maal 1024 zicht bare ASCII-tekens bevat. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, wordt deze header niet in het antwoord weer gegeven.

Voorbeeldreactie

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 00:17:44 GMT  
ETag: “0x8CB172A360EC34B”  
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>  

Autorisatie

Deze bewerking kan worden aangeroepen door de eigenaar van het account en door iedereen met een Shared Access Signature die gemachtigd is om naar deze BLOB of de container te schrijven.

Als voor een aanvraag labels met de x-ms-tags aanvraag header worden opgegeven, moet de aanroeper voldoen aan de autorisatie vereisten van de bewerking voor het instellen van BLOB-Tags .

Opmerkingen

De Put Block List bewerking dwingt de volg orde af waarin blokken moeten worden gecombineerd om een BLOB te maken.

Dezelfde blok-ID kan meer dan één keer worden opgegeven in de lijst met blokken. Als een blok-ID meer dan één keer is opgegeven, wordt het bereik van de bytes in elk van die locaties in de blokkerings lijst voor de laatste doorgevoerde BLOB weer gegeven. Als een blok-ID meermaals voor komt in de lijst, moeten beide exemplaren van de blok-ID worden opgegeven in dezelfde blokkerings lijst. Met andere woorden, beide exemplaren moeten worden opgegeven in het Committed element, het Uncommitted element of het Latest element.

Met Put Block List kunt u een bestaande BLOB wijzigen door afzonderlijke blokken in te voegen, bij te werken of te verwijderen, zonder de hele BLOB opnieuw te uploaden. U kunt blok-Id's opgeven in zowel de huidige doorgevoerde blokkerings lijst als de lijst met niet-vastgelegde blokken om een nieuwe BLOB te maken of de inhoud van een bestaande BLOB bij te werken. Op deze manier kunt u een BLOB bijwerken door een paar nieuwe blokken op te geven in de lijst met niet-vastgelegde blok keringen, en de rest van de lijst vastgelegde blokken die al deel uitmaakt van de bestaande blob.

Als er een blok-ID is opgegeven in het Latest element en dezelfde blok-id voor komt in de lijst met vastgelegde en niet-doorgevoerde blokken, wordt Put Block List het blok door gegeven in de blok kering van niet-vastgelegde blokken. Als de blok-ID voor komt in de lijst vastgelegde blokken, maar niet in de lijst met geblokkeerde blok keringen, wordt Put Block List het blok door doorgevoerd in de lijst vastgelegde blokken.

Elk blok in een blok-Blob kan een andere grootte hebben. Een blok-Blob kan Maxi maal 50.000 toegewezen blokken bevatten. Het maximum aantal niet-toegewezen blokken dat kan worden gekoppeld aan een blob is 100.000. In de volgende tabel worden de maximum grootte van het blok en de BLOB beschreven die is toegestaan door de service versie:

Serviceversie Maximale blokgrootte (via Put Block) Maximale blobgrootte (via Put Block List) Maximale blobgrootte via enkele schrijfbewerking (via Put Blob)
Versie 2019-12-12 en hoger 4000-MiB Ongeveer 190,7 TiB (4000 MiB X 50.000 blokken) 5000 MiB (preview)
Versie 2016-05-31 t/m versie 2019-07-07 100 MiB Ongeveer 4,75 TiB (100 MiB x 50.000 blokken) 256 MiB
Versies vóór 2016-05-31 4 MiB Ongeveer 195 GiB (4 MiB x 50.000 blokken) 64 MiB

Wanneer u Put Block List een bestaande BLOB bijwerkt, worden de bestaande eigenschappen en meta gegevens van de BLOB overschreven. Bestaande moment opnamen blijven echter behouden met de blob. U kunt de voorwaardelijke aanvraag headers alleen gebruiken om de bewerking uit te voeren als aan een opgegeven voor waarde is voldaan.

Als de Put Block List bewerking mislukt als gevolg van een ontbrekend blok, moet u het ontbrekende blok uploaden.

Eventuele niet-doorgevoerde blokken worden opgeruimd als er geen geslaagde aanroepen naar Put Block of Put Block List op de BLOB binnen een week na de laatste geslaagde Put Block bewerking zijn. Als put-BLOB wordt aangeroepen voor de blob, worden alle niet-doorgevoerde blokken permanent opgeruimd.

Als er labels zijn opgenomen in de x-ms-tags header, moeten deze worden gecodeerd met de query teken reeks. Code sleutels en-waarden moeten voldoen aan de vereisten voor naamgeving en lengte zoals opgegeven in BLOB-labels instellen. Verder kan de x-ms-tags koptekst labels bevatten tot Maxi maal 2 KiB. Als er meer Tags vereist zijn, gebruikt u de bewerking BLOB Tags instellen .

Als de BLOB een actieve lease heeft, moet de client een geldige lease-ID opgeven in de aanvraag om de blokkerings lijst door te voeren. Als de client geen lease-ID specificeert of een ongeldige lease-ID opgeeft, retourneert de Blob service status code 412 (de voor waarde is mislukt). Als de client een lease-ID opgeeft, maar de BLOB geen actieve lease heeft, retourneert de Blob service ook de status code 412 (de voor waarde is mislukt). Als de client een lease-ID opgeeft voor een blob die nog niet bestaat, retourneert de Blob service status code 412 (de voor waarde is mislukt) voor aanvragen die zijn gedaan met versie 2013-08-15 en hoger; voor eerdere versies van de Blob service wordt de status code 201 (gemaakt) geretourneerd.

Als de BLOB een actieve lease heeft en u aanroept Put Block List om de BLOB bij te werken, wordt de lease behouden op de bijgewerkte blob.

Put Block List is alleen van toepassing op blok-blobs. Aanroepen Put Block List op een pagina-BLOB resulteert in de status code 400 (ongeldige aanvraag).

Als u een gearchiveerde BLOB overschrijft, wordt hot / cool de laag overgenomen van de oude BLOB als de x-MS-Access-tier-header niet is ingesteld.

Zie ook

Meer informatie over blok-blobs, toevoeg-blobs en pagina-blobs
Aanvragen voor Azure Storage autoriseren
Status en fout codes
Fout codes voor BLOB-service
Time-outs instellen voor BLOB-service bewerkingen