-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[HttpClient] Debugging option #34289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
4.4 has a profiler panel, and |
hum, I missed this part - so you mean a monolog processor. PR welcome in the Monolog Bridge I suppose. |
I am also talking about production debugging. I would like the thrown exception to contain the response body / headers / etc. if the client has been declared with a specific option for example. For example instead of having A monolog processor could do the job indeed. Is it better than a new option on the HttpClient in your opinion? |
totally - that's not a concern the HttpClient needs to care about. |
If it can help I did something like this in a monolog processor $exception = $record['context']['exception'] ?? null;
if ($exception instanceof \Exception && $record['message'] !== $exception->getMessage()) {
$record['message'] = sprintf('%s - %s', $record['message'], $exception->getMessage());
}
while ($exception instanceof \Throwable) {
if ($exception instanceof HttpExceptionInterface) {
// It needs to be the 1st statement in order to fullfil the request
$responseContent = mb_strimwidth($exception->getResponse()->getContent(false), 0, 1000);
$record['context']['http_client'][] = $exception->getResponse()->getInfo()
+ ['response_content' => $responseContent];
}
$exception = $exception->getPrevious();
} |
the drawback of reading the response content there is that your logger will now wait until the full body is received. that's why we don't do it in the core. |
@stof Yes, that's why I combine this with a crossfinger + buffer handler to limitate this problem. |
|
@nicolas-grekas Awesome! Which PR enables this? I'll give it a try this week. |
Check #35407 |
Thank you for this suggestion. |
Hello? This issue is about to be closed if nobody replies. |
Hey, I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen! |
Description
At the moment it's quite hard to debug HTTP errors because the only information we get is:
HTTP/1.1 400 Bad Request returned for "https://example.com/".
It would be nice to have an opt-in option that would automatically open response payload and headers in order to log them in Sentry for example. It may require to handle a max lenght on the response payload.
The text was updated successfully, but these errors were encountered: