Implement Put Blob From URL

[Andrew Gaul (gaul)]

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.

[Copilot]

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.

[Andrew Gaul (gaul)]

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.

[Copilot]

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.

[Andrew Gaul (gaul)]

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.

[Copilot]

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.

[Andrew Gaul (gaul)]

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.

[Copilot]

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.

[Andrew Gaul (gaul)]

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.

[Copilot]

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.

[Andrew Gaul (gaul)]

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.

[Copilot]

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.

[Andrew Gaul (gaul)]

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.

[Copilot]

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.

[Andrew Gaul (gaul)]

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.

[Copilot]

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.