Skip to content

Implement Put Blob From URL - #2749

Open
Andrew Gaul (gaul) wants to merge 1 commit into
Azure:mainfrom
gaul:put-blob-from-url
Open

Implement Put Blob From URL#2749
Andrew Gaul (gaul) wants to merge 1 commit into
Azure:mainfrom
gaul:put-blob-from-url

Conversation

@gaul

Copy link
Copy Markdown
Contributor

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.

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>
Copilot AI lite review requested due to automatic review settings August 25, 2026 16:11

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 putBlobFromUrl implementation to BlockBlobHandler, including property/metadata/tag handling and source-condition enforcement via a shared readCopySource() 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants