You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now it is not possible to do something like the following
valstream= requests.get.stream(…)
valresponseStatusCode=???// not possible to get hold of header data hereif (responseStatusCode ==200) {
os.write(..., stream)
} else {
println("Error. Not streaming file.")
}
There seem to be two issues that prevent the status code (and other header data) to be accessible:
The stream headers are only made available through a callback. They will therefore live in a separate scope and are not trivially accessible in the scope of the stream and can't be used to determine how to proceed with processing the stream.
The http request is only started once the stream is accessed. Only then the aforementioned callback is called. This is ibviously too late to make a decision about what to do with the stream.
I came across this while porting a script from python (using the python requests library) in which the desired functionality does work.
Expected behaviour: the return value of requests.get.stream(…) makes contains the stream headers. This means upon call the method performs the request, fetches the headers but does not start to stream the body yet. This behaviour would also resemble that of the python equivalent.
Proposed solution: stream(…) returns a ReadableWithStreamHeaders or a Readable with WithStreamHeaders like this
Right now it is not possible to do something like the following
There seem to be two issues that prevent the status code (and other header data) to be accessible:
I came across this while porting a script from python (using the python requests library) in which the desired functionality does work.
Expected behaviour: the return value of
requests.get.stream(…)
makes contains the stream headers. This means upon call the method performs the request, fetches the headers but does not start to stream the body yet. This behaviour would also resemble that of the python equivalent.Proposed solution:
stream(…)
returns aReadableWithStreamHeaders
or aReadable with WithStreamHeaders
like thisI've already successfully tried to refactor
stream(…)
to incorporate this solution. Am happy to provide a PR.The text was updated successfully, but these errors were encountered: