To create a PSR-7 response from a regular Symfony HTTP response in Psr18Client and HttplugClient, the static methodHttplugWaitLoop::createPsr7Response is used. It also converts the response body stream to a PSR-7 stream, which generally happens in two steps: First, theResponseStreamInterface is made into a resource using a custom stream wrapper, and then this resource is made into a PSR-7 stream using thecreateStreamFromResource of whatever stream factory is used.

Finally, if the resulting PSR-7 stream is seekable, it is rewound to its start. Depending on the used stream implementation, it is, however, possible that calling->seek(0) throws an exception, despite->isSeekable() returning true. This is because the way some PSR-7 stream implementations check if the underlying resource is seekable is by looking at theseekable stream meta property. For custom stream wrappers, this metadata value appears to be always true, no matter if the stream wrapper implements seeking or not.

Some stream implementations, like the one in nyholm/psr7, prevent this by just trying to callfseek on the resource when the stream is first created and considering it not seekable if the operation fails. Other implementations like guzzle/psr7 don't do this extra check, which is why using the Symfony Psr18Client with a Guzzle stream factory fails. Since the Psr18Client automatically discovers stream factory implementations if none is specified, the Guzzle implementation can become the default if Guzzle happens to be installed in the project.

The solution I'm proposing here is to simply ignore any RuntimeException thrown when trying to seek to the start of the stream. Since rewinding the stream is already optional, this shouldn't cause any issues.