response_stream breaks with IOBuffer()
#543
Comments
|
Using Julia 1.6.1 and HTTP 0.9.10 I no longer see this error but instead get an unusable stream: julia> using HTTP
julia> io = IOBuffer(read=true, write=true);
julia> HTTP.get("https://google.com", response_stream=io)
HTTP.Messages.Response:
"""
HTTP/1.1 200 OK
Date: Fri, 18 Jun 2021 17:56:00 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Set-Cookie: 1P_JAR=2021-06-18-17; expires=Sun, 18-Jul-2021 17:56:00 GMT; path=/; domain=.google.com; Secure
Set-Cookie: NID=217=Sz2svs1yEqHxxLW_Ut5xUk03LSxp6zEOglskwqmOvMIOhAvzJE7x9dX-2XfSdzqAU1f4h-gfZ5zmBsKWFI-ms3QeP6jJnQHynhDMNohL5D6bNftc-pIKGXUkFHng0aWkPK905lSCrUOoi2nnV5ICcTXnjuRdLYAMUJsDLv9076w; expires=Sat, 18-Dec-2021 17:56:00 GMT; path=/; domain=.google.com; HttpOnly
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked
[Message Body was streamed]"""
julia> isopen(io)
false
julia> read(io, String)
ERROR: ArgumentError: read failed, IOBuffer is not readable
Stacktrace:
[1] _throw_not_readable()
@ Base ./iobuffer.jl:160
[2] unsafe_read(from::IOBuffer, p::Ptr{UInt8}, nb::UInt64)
@ Base ./iobuffer.jl:164
[3] unsafe_read
@ ./io.jl:722 [inlined]
[4] read!
@ ./io.jl:734 [inlined]
[5] read
@ ./iobuffer.jl:469 [inlined]
[6] read(s::IOBuffer, #unused#::Type{String})
@ Base ./io.jl:966
[7] top-level scope
@ REPL[11]:1 |
This is because HTTP.jl Line 149 in cfcc595 whereas it should call |
|
Actually — should HTTP.get("http://example.com", response_stream=io)
close(io)The |
|
I agree that we probably dont' need to call |
I think the reason the stream is closed is because |
Is there a reason we even need use |
No. That's why I was questioning any kind of close in my second comment.
Exactly 👍 |
I thought so too, but I've just spotted the following example in the io = Base.BufferStream()
@async while !eof(io)
bytes = readavailable(io)
println("GET data: \$bytes")
end
r = HTTP.request("GET", "http://httpbin.org/get", response_stream=io)
close(io)Luckily the docs already suggest that the caller should call |
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
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>
Versions:
Example:
Which results in:
The text was updated successfully, but these errors were encountered: