Implement Put Blob From URL - #2749
Open
Andrew Gaul (gaul) wants to merge 1 commit into
Open
Conversation
Put Blob From URL answered 501, so a client copying a blob in one request had to fall back to the asynchronous Copy Blob and then wait out a copy it had asked to have done by the time it was answered. Read the source the way Put Block From URL already does -- a loopback self-request pinned to the address and port this server is bound to, carrying the caller's path, query and source conditions -- and commit what comes back as a new block blob. The two operations now share that fetch, so authentication, conditions, and the refusal to decompress a source that merely declares an encoding are answered the same way for both, in one place. What the destination ends up with follows the operation's contract. The source's standard properties are copied unless x-ms-copy-source-blob-properties says otherwise, and a blob content header on the request sets that one property either way. Metadata answers to its own rule: named on the request it replaces the source's, named nowhere it is copied. Tags are the request's, or the source's under x-ms-copy-source-tag-option: COPY, which reads them over the same authorized path the content came over -- the extra Get Blob Tags call against the source that the operation is documented to make, so a URL allowed to read the source but not its tags is refused rather than obeyed. Asking for both at once is refused as it already is for Copy Blob From URL. The operation writes a blob, so it joins Put Blob in the shared access signature tables and in the rule that an existing destination demands write permission; an operation missing from those tables fails the request with an internal error rather than a permission one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Implements synchronous Put Blob From URL support for block blobs in Azurite by reusing the existing “loopback self-request” copy-source fetch pattern (previously used for Put Block From URL), ensuring authentication and source conditions are enforced through the standard download path.
Changes:
- Add
putBlobFromUrlimplementation toBlockBlobHandler, including property/metadata/tag handling and source-condition enforcement via a sharedreadCopySource()helper. - Extend SAS permission mappings and “existing destination requires write” logic to include
BlockBlob_PutBlobFromUrl. - Add a comprehensive test suite for Put Blob From URL behavior and update documentation/changelog to reflect support.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| tests/blob/apis/blockblob.test.ts | Adds end-to-end tests for Put Blob From URL covering overwrite, headers/properties, metadata, tags, tiers, conditions, and MD5 behaviors. |
| src/blob/handlers/BlockBlobHandler.ts | Implements Put Blob From URL and refactors shared loopback source-fetch logic used by both putBlobFromUrl and stageBlockFromURL. |
| src/blob/authentication/OperationBlobSASPermission.ts | Registers required blob/container SAS permissions for the new Put Blob From URL operation. |
| src/blob/authentication/OperationAccountSASPermission.ts | Registers account SAS permission requirements for Put Blob From URL. |
| src/blob/authentication/BlobSASAuthenticator.ts | Includes Put Blob From URL in the “if destination exists, must have write” special-case rule. |
| src/blob/authentication/AccountSASAuthenticator.ts | Includes Put Blob From URL in the “if destination exists, must have write” special-case rule for account SAS. |
| README.md | Moves Put Blob From URL into the supported API matrix with the “same Azurite instance only” limitation. |
| ChangeLog.md | Documents the new Put Blob From URL support and its behavioral details. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Put Blob From URL answered 501, so a client copying a blob in one request had to fall back to the asynchronous Copy Blob and then wait out a copy it had asked to have done by the time it was answered. Read the source the way Put Block From URL already does -- a loopback self-request pinned to the address and port this server is bound to, carrying the caller's path, query and source conditions -- and commit what comes back as a new block blob. The two operations now share that fetch, so authentication, conditions, and the refusal to decompress a source that merely declares an encoding are answered the same way for both, in one place.
What the destination ends up with follows the operation's contract. The source's standard properties are copied unless x-ms-copy-source-blob-properties says otherwise, and a blob content header on the request sets that one property either way. Metadata answers to its own rule: named on the request it replaces the source's, named nowhere it is copied. Tags are the request's, or the source's under x-ms-copy-source-tag-option: COPY, which reads them over the same authorized path the content came over -- the extra Get Blob Tags call against the source that the operation is documented to make, so a URL allowed to read the source but not its tags is refused rather than obeyed. Asking for both at once is refused as it already is for Copy Blob From URL.
The operation writes a blob, so it joins Put Blob in the shared access signature tables and in the rule that an existing destination demands write permission; an operation missing from those tables fails the request with an internal error rather than a permission one.
References #2681.