-
Notifications
You must be signed in to change notification settings - Fork 183
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
Do not call close()
on the response_stream
#752
Conversation
This allows a plain `IOBuffer` to be used with `response_stream`. It seems unnecessary to be calling `close(response_stream)` inside HTTP.request() - given that HTTP.request is a blocking operation, the caller can easily close the stream themselves after `HTTP.request()` returns. This could be considered a breaking change for users who use the internal IO type Base.BufferStream with the response_stream keyword. Fixes #543
Codecov Report
@@ Coverage Diff @@
## master #752 +/- ##
==========================================
- Coverage 76.84% 76.84% -0.01%
==========================================
Files 38 38
Lines 2514 2513 -1
==========================================
- Hits 1932 1931 -1
Misses 582 582
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; I'm disappointed in the testing situation. I thought using the pie-socket site for the websocket tests would work well, but the failures in the CI here seem like random failures.
Downloads.jl uses Are we happy to merge right away, even though this is arguably breaking? |
Yeah, fine by me |
Can we get a release that includes this fix? |
467: Always close the `response_stream` after `HTTP.request` r=mattBrzezinski a=nickrobinson251 - We need to explicitly close the `response_stream` (`HTTP.request` no longer closes it for us) in HTTP.jl v0.9.15+ (see JuliaWeb/HTTP.jl#752) - Since `close` is safe to call multiple times, this should be compatible with old HTTP.jl versions. - Should fix issue #466 (and JuliaCloud/AWSS3.jl#215) - Also since we're fixing this here, we can close JuliaWeb/HTTP.jl#772 ~TODO: add test... i just need to recreate the issue using AWS.jl explicitly (rather than AWSS3)~ done. Co-authored-by: Nick Robinson <nicholas.robinson@invenialabs.co.uk> Co-authored-by: Nick Robinson <npr251@gmail.com>
467: Always close the `response_stream` after `HTTP.request` r=mattBrzezinski a=nickrobinson251 - We need to explicitly close the `response_stream` (`HTTP.request` no longer closes it for us) in HTTP.jl v0.9.15+ (see JuliaWeb/HTTP.jl#752) - Since `close` is safe to call multiple times, this should be compatible with old HTTP.jl versions. - Should fix issue #466 (and JuliaCloud/AWSS3.jl#215) - Also since we're fixing this here, we can close JuliaWeb/HTTP.jl#772 ~TODO: add test... i just need to recreate the issue using AWS.jl explicitly (rather than AWSS3)~ done. Co-authored-by: Nick Robinson <nicholas.robinson@invenialabs.co.uk> Co-authored-by: Nick Robinson <npr251@gmail.com>
This reverts commit 03749a4.
This reverts commit 03749a4.
This allows a plain `IOBuffer` to be used with `response_stream`. It seems unnecessary to be calling `close(response_stream)` inside HTTP.request() - given that HTTP.request is a blocking operation, the caller can easily close the stream themselves after `HTTP.request()` returns. This could be considered a breaking change for users who use the internal IO type Base.BufferStream with the response_stream keyword. Fixes #543
This allows a plain `IOBuffer` to be used with `response_stream`. It seems unnecessary to be calling `close(response_stream)` inside HTTP.request() - given that HTTP.request is a blocking operation, the caller can easily close the stream themselves after `HTTP.request()` returns. This could be considered a breaking change for users who use the internal IO type Base.BufferStream with the response_stream keyword. Fixes #543 Co-authored-by: Jacob Quinn <quinn.jacobd@gmail.com>
This allows a plain `IOBuffer` to be used with `response_stream`. It seems unnecessary to be calling `close(response_stream)` inside HTTP.request() - given that HTTP.request is a blocking operation, the caller can easily close the stream themselves after `HTTP.request()` returns. This could be considered a breaking change for users who use the internal IO type Base.BufferStream with the response_stream keyword. Fixes #543 Co-authored-by: Jacob Quinn <quinn.jacobd@gmail.com>
This allows a plain
IOBuffer
to be used withresponse_stream
.It seems unnecessary to be calling
close(response_stream)
insideHTTP.request() - given that HTTP.request is a blocking operation, the
caller can easily close the stream themselves after
HTTP.request()
returns.
This could be considered a breaking change for users who use the
internal IO type Base.BufferStream with the response_stream keyword.
Fixes #543