No Redirects following (default guzzle behaviour changed) about guzzle6-adapter HOT 6 CLOSED

Sorry, I didn't mean to say in a negative way against the PSR-18 itself, I completely respect the work that was done.
I just meant that the prevention for my problem's solution is the way that the PSR-18 was designed.
It would be nice if straight from a PSR18 client we would have the ability to tell if it should follow or not redirects, as other configurations like to set a proxy or set the timeout.

from guzzle6-adapter.

@ricardofiorani There is a redirect plugin. I think that should be of interest for you.

from guzzle6-adapter.

That is exactly what I needed!
Thank you @xabbuh! 🙇

from guzzle6-adapter.

this is the expected behaviour according to the specification: https://www.php-fig.org/psr/psr-18/meta/#middleware-and-wrapping-a-client

all psr http clients are expected to behave the same way by default.

depending on what you do, you want to explicitly know about redirections. when building an api client, you probably want exceptions in all but the production environment to realize you are being inefficient, etc.

if it makes sense to have redirections in your project, you have 2 options:

1. you can decorate any psr client with a plugin client and use the php-http redirect plugin
2. you can instantiate the guzzle client yourself and pass it to the guzzle6-adapter: $adapter = new GuzzleAdapter($guzzle); (afaik the default guzzle also throws exceptions on 4xx/5xx responses, which PSR is supposed to also not do)

from guzzle6-adapter.

Oh, I didn't know the problem was deep down on PSR-18 specification itself.

I mean, I'm assuming people want to have the functionality of following redirects as it makes everything easier instead of tumbling another problem on the PSR level. So I just question myself why was it done this way.

Anyway thank you for your help @dbu, I really appreciate it!

from guzzle6-adapter.

Anyway thank you for your help @dbu, I really appreciate it!

glad i could help 👍

Oh, I didn't know the problem was deep down on PSR-18 specification itself.

i don't think its a problem or a mistake of the PSR. it depends on the use case, redirection does not make sense for everyone. the PSR had to chose one way to guarantee a consistent experience over all clients. adding redirection handling is doable in such a scanner - removing it by wrapping the client somehow is impossible.

if you build an api client and don't notice that every single request you do is redirected, the efficiency penalty is massive, so you really want to know about that.

if you build a library to scan some site and want to explicitly know about redirects, you really need a client that does not follow redirects itself.

from guzzle6-adapter.