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

Unwanted behaviour on Zend\Http\Client eq not thread safe #23

Closed
weierophinney opened this issue Dec 31, 2019 · 3 comments
Closed

Unwanted behaviour on Zend\Http\Client eq not thread safe #23

weierophinney opened this issue Dec 31, 2019 · 3 comments

Comments

@weierophinney
Copy link
Member

Hi,

We are using our application with around 25 workers (with beanstalkd and 25 listening proccesses). Most of the time we use the Client object to retrieve external content. And we do mime type checks which uses the headers.

Some of the use cases have setStream used.

And some times it will occur that the stream which is set by Client is the same filename used by another proccesses Client object. So we get a json mime type for an xml file by example.

It seems to go wrong on line 691 in \Zend\Http\Client object where tempnam is used. And as we can read from the documentation it is not really save to use.

http://php.net/manual/en/function.tempnam.php#98232

I suppose we should be using setStream with an own unique filename for each process to be safe. But that would be a workaround on the issue.

Thanks!


Originally posted by @muhammedeminakbulut at zendframework/zend-http#30

@weierophinney
Copy link
Member Author

You could define a different config streamtmpdir for each process


Originally posted by @Maks3w at zendframework/zend-http#30 (comment)

@weierophinney
Copy link
Member Author

We've tried that just now. But we keep getting an content type thats not correct.


Originally posted by @muhammedeminakbulut at zendframework/zend-http#30 (comment)

@weierophinney
Copy link
Member Author

This package is considered feature-complete, and is now in security-only maintenance mode, following a decision by the Technical Steering Committee.
If you have a security issue, please follow our security reporting guidelines.
If you wish to take on the role of maintainer, please nominate yourself

You can continue using laminas/laminas-http safely.
Its successor will be PSR-7 in a later revision of laminas/laminas-mvc.

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

No branches or pull requests

1 participant