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
Allow manipulating the handler stack per request #3152
Comments
As you also said, it's hard to recommend a solution that works for every scenario. A couple things I would try before meddling with the
In my experience, HTTP middleware are often misused (another example that comes to mind is handling errors in middleware).
This is potentially a backward incompatible change. Another potential use case for this option could be overwriting the entire I could imagine an option that accepts a function and returns a That being said, I haven't worked on Guzzle for a while, so I don't know if it would have any major implications. Let's wait for other maintainers to chime in. |
@GrahamCampbell I'd love to hear your thoughts about the topic since you've been spearheading Guzzle maintenance lately (for which I'm eternally grateful). |
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. |
Description
#2514 removes the only (reflection-free) way to manipulate the handler stack.
Example
Additional context
#2514 (comment) says
This simply doesn't work if I want some requests cached and some I don't want to. Currently Drupal injects an instance of
Client
and I can just run getConfig handler and push the cache middleware and be done. Drupal uses a compiled container so changing the definition is really tricky run time.Overall, trying to predict every use case is hard.
We could add a
merge
method toHandlerStack
which accepts anotherHandlerStack
, creates a pristine new HandlerStack, operates both the original and the one being merged and pushes the handlers on the new one.And then
Client::prepareDefaults
could look at the request options, if ahandler
is provided then it calls said merge.It's not 100% compared to the current situation because you can't splice a handler before another but it's a big step ahead.
The text was updated successfully, but these errors were encountered: