-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
sink tmpfile() closed before it can be used (scoping issue) #2400
Comments
Hm.. I understand this is a bit weird? But what would a fix be? Not close the stream and leave the resource open? That is no good.. |
I guess my point is that the "creator" of the resource is also responsible for managing (=closing) it, and not the library working with it. |
Any progress on this? |
I don't have more information than presented in this issue. |
@mfn I think I may have a workaround for you. Seems to be working for us: $tmp = tmpfile();
// Assign the response to a variable to keep the tmpfile open
$response = $guzzle->request('GET', 'http://example.com/csv/', [
'sink' => $tmp
]);
// The we pass it straight into a CSV reader.
$reader = Reader::createFromStream($tmp);
|
Thanks, but I'm aware. However my use-case requires processing this data somewhere else where the response is already out of scope! |
Ok, sorry. |
hi there, No plan to make the ressource closing optional or something ? Best regards, Salim |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions. |
Nothing changed, behaviour is still the same with:
See example from initial description:
|
@mfn I have no experience with this in PHP, but can't you simply wrap the tmpfile resource in a custom 'Stream' that simply does not do the fclose bit on __destruct and feed that to Guzzle? |
Interesting idea, I tried it in 5 mins but it went nowhere. Also, the When I pass |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions. |
not stale |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions. |
not stale |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions. |
Thank you @GrahamCampbell ! |
Thank me when it's fixed, lol. ;) |
lol, looking forward to it! (i.e. the acceptable solution) |
Guzzle version(s) affected: 6.3.3
Description
When using the
sink
option and providing atmpfile()
, that handle is closed when theResponse
gets out of scope.How to reproduce
Output on my system (osx, but the same on linux; I added the empty line for clarity):
The underlying problem is that when using
sink
a stream is used within\GuzzleHttp\Psr7\Response
.That stream is
\GuzzleHttp\Psr7\Stream
and has a __destruct implementation:This caught me by surprise and I would have loved to use the sink with tmpfile. Notwithstanding the debugging necessary to figure this out 😄
I eventually had to change the implementation to
tempnam
for now (this also uses streams but the reference is a filename).No amount of googling brought this up so in this interest I created this issue.
Not sure what a fix could be as I don't have insights why there is even a manual
fclose
here.I would have expected:
But Guzzlehttp interfered here.
The text was updated successfully, but these errors were encountered: