The current behavior allows defaulting to 2.0 when ppl didn't specify any protocol. This happens most of the time.
Merging as is would be a regression for many as it would mean switching to HTTP/1.1 when 2.0 is used today.
That's a drawback of the PSR-7 interface; not being able to tell if ppl really did intent to use that version of HTTP, or if that's just some default.

An idea might be to find a way to tell the difference when our own createRequest() is used.

Another idea: add a dedicated option to the client (usable by calling withOptions()).

Side note: a similar patch will be required on HttplugClient.

The current behavior allows defaulting to 2.0 when ppl didn't specify any protocol. This happens most of the time. Merging as is would be a regression for many as it would mean switching to HTTP/1.1 when 2.0 is used today. That's a drawback of the PSR-7 interface; not being able to tell if ppl really did intent to use that version of HTTP, or if that's just some default.

The PSR-7 interface defines a getProtocolVersion method that always returns a string, meaning that the protocol version is set for every request. While most PSR-7 implementations use 1.1 by default in the request constructor, the constructor itself is not part of the PSR-7 specification.

The current Psr18Client implementation assumes that if the protocol version is set to 1.1, this is because the caller has forgotten to set it to 2.0. However, in my project, this is a deliberate decision.

Any caller code can change the protocol version set in the PSR-7, no matter which PSR-7 implementation is being used, so I see no need to create a dedicated option in the client.

What do you think about proposing this as a feature retargeting the PR to Symfony 8?

I think I already shared my vision, and its rationale :)
So no: doing this change on 8.0 will lead to the same concern - a regression for most.

most PSR-7 implementations use 1.1 by default in the request constructor, the constructor itself is not part of the PSR-7 specification.

The request factory is, so there is a standardized way to create PSR-7 objects. And of course nobody calls >withProtocolVersion() - because why hardcode for a specific version anyway.

I suggested two alternatives:

• an option at the client level
• tracking calls to >withProtocolVersion(), by returning a decorated request when calling $client->createRequest()

Possibly implementing both proposals.