Conversation
* Storage STG99/Content Validation - Main Function and Blob Support (#6407) * Content Validation * Add blob support * fix init * update logic * update logic * update * Update * Update build failure * Update init * Fix clang format * update docs * Rebase main * Storage/Content Validation Part2 (#6530) * Add file and datalake support * Update test cases * Update Logic * Update test case * Fix failure * Update test case. * update test record * fix cspell.
* Cross-tenant principal bound sas * Fix test failure
…for Delete Blob API (#6869) * Source CMK and Delete condition for AccessTier * Rename * Fix Cspell
* Add test cases for STG101 feature * Fix clang format
There was a problem hiding this comment.
Pull request overview
This PR implements Storage STG101 features for Azure Storage SDK for C++. The main changes include:
Changes:
- Updates API version from 2026-02-06 to 2026-04-06 across all storage services
- Adds structured message support with CRC64 validation for uploads/downloads
- Implements delegated user tenant ID for cross-tenant SAS scenarios
- Adds dynamic SAS with custom request headers and query parameters
Reviewed changes
Copilot reviewed 63 out of 63 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| swagger/README.md files | Updated API version and spec references to 2026-04-06 |
| rest_client.cpp/.hpp files | Updated API version constant and added SignedDelegatedUserTid fields |
| *_sas_builder.cpp/.hpp | Added RequestHeaders/RequestQueryParameters support and updated string-to-sign |
| structured_message_*.cpp/.hpp | New implementation for encoding/decoding structured messages with CRC64 |
| *_client.cpp | Integrated structured message and validation options |
| *_options.hpp | Added TransferValidationOptions and DelegatedUserTid |
| test files | Enabled cross-tenant tests and added structured message tests |
| datalake_utilities.cpp/.hpp | Fixed typo and added validation options mapping (with bug) |
sdk/storage/azure-storage-files-datalake/src/datalake_utilities.cpp
Outdated
Show resolved
Hide resolved
sdk/storage/azure-storage-files-datalake/test/ut/datalake_file_client_test.cpp
Outdated
Show resolved
Hide resolved
* Content validation client option support * Update test cases * Fix test case * FIx test case * Fix test case * Fix test failure
| /** | ||
| * @brief Optional. Configures whether to do content validation for blob uploads. | ||
| */ | ||
| Azure::Nullable<TransferValidationOptions> UploadValidationOptions; |
There was a problem hiding this comment.
What's the benefit of using nullable here?
There was a problem hiding this comment.
Is there a semantic difference between a null validation option and a non-null but default one?
There was a problem hiding this comment.
The same question goes for the ones in other option bags
There was a problem hiding this comment.
The logic to use this option is that:
Azure::Nullable<TransferValidationOptions> validationOptions
= options.ValidationOptions.HasValue() ? options.ValidationOptions
: m_downloadValidationOptions;
So in the API level, we should support Nullable option to see if customer set the API level option, and for the client_option, it's actuallty unnecessary. But I think keep align with the API level and Client level option schema is better?
sdk/storage/azure-storage-common/src/structured_message_decoding_stream.cpp
Outdated
Show resolved
Hide resolved
sdk/storage/azure-storage-common/src/structured_message_decoding_stream.cpp
Show resolved
Hide resolved
sdk/storage/azure-storage-common/src/structured_message_decoding_stream.cpp
Outdated
Show resolved
Hide resolved
sdk/storage/azure-storage-common/src/structured_message_decoding_stream.cpp
Outdated
Show resolved
Hide resolved
| totalReadContent += bytesRead; | ||
| if (m_currentSegmentOffset == m_currentSegmentLength) | ||
| { | ||
| m_currentRegion = StructuredMessageCurrentRegion::SegmentFooter; |
There was a problem hiding this comment.
Let's say the customer issues a request to download a small blob, all the blob data, and structured headers, footers etc are all transferred in one shot.
The first time the code enters this while loop, it processes StreamHeader region, then SegmentHeader region, then SegmentContent region.
Then in this region, totalReadContent will be increased to the size of the blob (also the number of bytes this cutomer has requested). Then the m_currentRegion variable will be set to SegmentFooter.
Then the while loop breaks because totalReadContent is now equal to count.
Will the logic in SegmentFooter and StreamFooter still get called?
* Fix comments * Add end line * Fix build failure * Update test case * Update * Add comments
Pull Request Checklist
Please leverage this checklist as a reminder to address commonly occurring feedback when submitting a pull request to make sure your PR can be reviewed quickly:
See the detailed list in the contributing guide.