how to set up guzzle
Closed this issue · 6 comments
it seems to set up guzzle in a way that it throws exceptions when receiving a 403 response. that exception is correctly converted to a php-http exception, but still not expected if i understand correctly how we wanted things to be set up. (i did not add any plugins, so the plugin to convert error responses to exceptions is not there.)
it seems that we have the Middleware::httpErrors in the guzzle stack. looking at https://github.com/php-http/guzzle6-adapter/blob/master/src/Guzzle6HttpAdapter.php#L32 and https://github.com/guzzle/guzzle/blob/master/src/Client.php#L64-L65 i think we would need to provide an empty or reduced handler stack. this in turn means that using php-http results in a very bare-bone - but the alternative is inconsistent behaviour.
found this while working on FriendsOfSymfony/FOSHttpCache#257 - to see a stack trace, look for Http\Client\Exception\HttpException: Client error:
GET http://localhost:6181/user_context.php`resulted in a403 Forbidden
response:` in the travis output.
I remember that we set exceptions to false in case of guzzle 5, but to be honest, I don't know how this works in case of guzzle 6. But if it is solved as a middleware (like we are going to do) then we should customize the HandlerStack.
i can do a PR to provide an empty stack to avoid guzzle putting things
in the stack.
do we need any middleware? the default is
$stack->push(Middleware::httpErrors(), 'http_errors');
$stack->push(Middleware::redirect(), 'allow_redirects');
$stack->push(Middleware::cookies(), 'cookies');
$stack->push(Middleware::prepareBody(), 'prepare_body');
i guess the first 3 really are handled by our plugins. what about
prepare_body?
and also, if we make the default client extremly barebone, this is not
really convenient for users. they might want at least the body
preparation thing. should we have another service locator for a client
with a bunch of default plugins?
What does prepare body do?
its doing quite a lot: https://github.com/guzzle/guzzle/blob/master/src/PrepareBodyMiddleware.php
size and content encoding things. i would tend to add it, as it "only" adds things if they are not there anyways. still, it will hide problems when developing against guzzle and later running with a different client that does not automatically do this.
I think we could/should have similar plugins, but it is very unlikely that they will ever collide, so I would say we should have it.
in the PrepareBody middleware we also have a plugin which does that : https://github.com/php-http/plugins/blob/master/src/ContentLengthPlugin.php at the exception of the except header