[HttpClient] Ignore RuntimeExceptions thrown when rewinding the PSR-7 created in HttplugWaitLoop::createPsr7Response #58901
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To create a PSR-7 response from a regular Symfony HTTP response in Psr18Client and HttplugClient, the static method
HttplugWaitLoop::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 call
fseek
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.