otsch

> As this is a new behavior, this PR should target 6.3 instead of 5.4. @fabpot Is this meant independently of your comment about the new `$normalizeWhitespace` argument?

@fabpot @nicolas-grekas I've created a new PR with target branch 6.3 as requested: https://github.com/symfony/symfony/pull/48940 (if the target branch can be changed in an existing PR, I haven't found how it...

> @otsch it's hidden behind the "edit" button: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request @xabbuh Oh, looks like I'm blind 😂🙈 For me it always looked like only the title changes to an Input when...

🤔 OK, the tests from https://github.com/php-http/client-integration-tests expect a request that gets a 30x response to actually get that response, which makes sense when you don't assume any default configuration of...

Also just found that the implementation of PSR-18 `sendRequest` method in the guzzle client itself (https://github.com/guzzle/guzzle/blob/master/src/Client.php#L134) sets allow_redirects to false in any case, so is it actually not possible/allowed to...

Thank you for the detailed answer! I understand that it totally makes sense to not automatically follow redirects 👍🏻 and actually I need to know about the redirects in my...

> The sendAsync method this package uses With that i meant: both methods `sendRequest` and `sendAsyncRequest` from the `Client` implementation of this package in the end call guzzle's `sendAsync` method,...

No, if it should allow to make the client automatically redirect when providing the guzzle `allow_redirect` config. This still returns a 301 response: And as mentioned I think it's because...

I'd say yes. At least I think that should work 👍🏻

Hi @8ctopus, I like the idea. One thing that came to my mind: the library also supports IDN and as encoding/decoding IDN works differently, we shouldn't pass the whole URL...