Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

avoid chunked transfers in putBlob when possible #26

Merged
merged 2 commits into from
Dec 11, 2021
Merged

Conversation

tanmaykm
Copy link
Member

@tanmaykm tanmaykm commented Dec 8, 2021

This is to avoid Downloads.jl from initiating chunked transfer when a file IOStream is supplied to putBlob.

In 0.4.0, we have switched to using Downloads.jl as the HTTP client instead of HTTP.jl. This issue happens because Downloads.jl
is not able to determine the content length when an IO instance is provided to upload data from, and switches to using a chunked transfer encoding. And the putBlob Azure API endpoint does not support chunked transfers.

The solution is to not use chunked transfers for putBlob. This PR (JuliaLang/Downloads.jl#167) to Downloads.jl would let it also look into the content-length header that we supply to determine the data size to expect in the IO instance we pass.

But until the Downloads.jl PR is merged (and backported), we need this change in Azure.jl to detect IO handles that point to locally mappable files and supply the correct content length and IOBuffer of memory mapped file contents as data to upload instead.

fixes: #25

This is to avoid Downloads.jl from initiating chunked transfer when a file IOStream is supplied to `putBlob`.

In 0.4.0, we have switched to using Downloads.jl as the HTTP client instead of HTTP.jl. This issue happens because Downloads.jl
is not able to determine the content length when an IO instance is provided to upload data from, and switches to using a chunked transfer encoding. And the putBlob Azure API endpoint does not support chunked transfers.

The solution is to not use chunked transfers for putBlob. This PR (JuliaLang/Downloads.jl#167) to Downloads.jl would let it also look into the content-length header that we supply to determine the data size to expect in the IO instance we pass.

But until the Downloads.jl PR is merged (and backported), we need this change in Azure.jl to detect IO handles that point to locally mappable files and supply the correct content length and `IOBuffer` of memory mapped file contents as data to upload instead.

fixes: #25
@tanmaykm tanmaykm merged commit 0e2b55e into master Dec 11, 2021
@delete-merged-branch delete-merged-branch bot deleted the tan/fixputblob branch December 11, 2021 11:01
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.

The value for one of the HTTP headers is not in the correct format
1 participant