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 owncreateRequest() is used.

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

Side note: a similar patch will be required onHttplugClient.

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 agetProtocolVersion method that always returns a string, meaning that the protocol version is set for every request. While most PSR-7 implementations use1.1 by default in the request constructor, the constructor itself is not part of the PSR-7 specification.

The currentPsr18Client implementation assumes that if the protocol version is set to1.1, this is because the caller has forgotten to set it to2.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 thereis 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.

Closing in favor of#62059