Append Blob Seal
The purpose of the Append Blob Seal
operation is to allow users and applications to seal append blobs, marking them as read-only. This document outlines the proposed REST API specs for this feature.
Request
You can construct the Append Blob Seal
request as follows. HTTPS is recommended. Replace myaccount
with the name of your storage account.
PUT method request URI | HTTP version |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=seal |
HTTP/1.1 |
Headers
Append Blob Seal
returns common API headers, ETag
/LMT
(last-modified-time), x-ms-request-id
, x-ms-version
, content-length
, and Date
. Append Blob Seal
doesn't change the ETag
/LMT
.
Response header | Value | Description |
---|---|---|
x-ms-blob-sealed |
true/false | Optional. False by default. If the blob is sealed, this header is included in the response when you seal and get properties of a blob. This header should appear in GetBlob , GetBlobProperties , AppendBlobSeal , and ListBlobs for append blobs. |
Query parameters
No additional URI parameters.
Request body
None.
Response
The response includes an HTTP status code and a list of response headers.
Status code
You might receive any of the following status codes:
200 (Success): The blob is sealed. The call is idempotent and will succeed if the blob is already sealed.
409 (InvalidBlobType): The service returns this status code if the call is on an existing page blob or block blob.
404 (BlobNotFound): The service returns this status code if the call is on a non-existent blob.
Authorization
Authorization is required when calling any data access operation in Azure Storage. You can authorize the Append Blob Seal
operation as described below.
Important
Microsoft recommends using Microsoft Entra ID with managed identities to authorize requests to Azure Storage. Microsoft Entra ID provides superior security and ease of use compared to Shared Key authorization.
Azure Storage supports using Microsoft Entra ID to authorize requests to blob data. With Microsoft Entra ID, you can use Azure role-based access control (Azure RBAC) to grant permissions to a security principal. The security principal may be a user, group, application service principal, or Azure managed identity. The security principal is authenticated by Microsoft Entra ID to return an OAuth 2.0 token. The token can then be used to authorize a request against the Blob service.
To learn more about authorization using Microsoft Entra ID, see Authorize access to blobs using Microsoft Entra ID.
Permissions
Listed below are the RBAC action necessary for a Microsoft Entra user, group, managed identity, or service principal to call the Append Blob Seal
operation, and the least privileged built-in Azure RBAC role that includes this action:
- Azure RBAC action: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- Least privileged built-in role: Storage Blob Data Contributor
To learn more about assigning roles using Azure RBAC, see Assign an Azure role for access to blob data.
Remarks
If an append blob has a lease, you need a lease ID to seal the blob.
After you seal a blob, you can still update properties, blob index tags, and metadata. Soft-deleting a sealed blob preserves the sealed state. You can overwrite sealed blobs.
If you take a snapshot of a sealed blob, the snapshot includes the sealed flag. For existing snapshots in the new version, Microsoft returns the property.
When you copy a sealed blob, the sealed flag is propagated by default. A header is exposed that allows the flag to be overwritten.
A new XML element will be added to the ListBlob
response, named Sealed
. The value can be either true
or false
.
If you call AppendBlock
on a blob that is already sealed, the service returns the error message shown in the following table. This applies to older versions of the API.
Error code | HTTP status code | User message |
---|---|---|
BlobIsSealed | Conflict (409) | The specified blob is sealed, and its contents can't be modified unless the blob is re-created after a delete. |
If you call Append Blob Seal
on an append blob that has already been sealed, you simply see a status code of 200 (Success).
Billing
Pricing requests can originate from clients that use Blob Storage APIs, either directly through the Blob Storage REST API, or from an Azure Storage client library. These requests accrue charges per transaction. The type of transaction affects how the account is charged. For example, read transactions accrue to a different billing category than write transactions. The following table shows the billing category for Append Blob Seal
requests based on the storage account type:
Operation | Storage account type | Billing category |
---|---|---|
Append Blob Seal | Premium block blob Standard general-purpose v2 Standard general-purpose v1 |
Write operations |
To learn about pricing for the specified billing category, see Azure Blob Storage Pricing.