-
When an HTTP exception occurs, Guzzle truncates the response body to 120 characters; yes, 120. For development purposes this is almost completely useless as it often leads to error responses like "validation error in field (truncated...)". There have been many attempts over the years to persuade guzzle to bump this limit or make it configurable. These requests were rejected many times (predicated on "it might fill up logs"), but a way was eventually provided in guzzle 7.2. However, it's not straightforward, and they also refused to write docs for it. So it's there, but it's hard to get at, and since Laravel uses Guzzle, we are stuck with it if we want to use the otherwise lovely built-in HttpClient. So how can we get at this and expose it in Laravel? The truncation length can be set in Guzzle's What I was expecting is for Laravel's wrapper to catch a guzzle exception, then transform and rethrow it using its own exception class. No such luck. It's also too late at that point as the message is already truncated by then. So, it would be lovely to be able to get basic debug info out of the HTTP client but I hadn't planned on a yak shaving expedition. Can anyone more familiar with HTTP client internals suggest how this might be done? Meanwhile, I'll continue using the only other route available to solving this ridiculous problem: editing files in |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 6 replies
-
It's nice to know I'm not alone... Here's this problem manifesting on Laravel Envoyer: |
Beta Was this translation helpful? Give feedback.
-
Soory, but... What the problem with calling RequestException::getResponse() to get fully featured response with all the body available? |
Beta Was this translation helpful? Give feedback.
-
Anyone coming here from Google like I did, you can now disable truncating by adding this one line to your
|
Beta Was this translation helpful? Give feedback.
Your assumption is wrong. You have full body response even after exception have been thrown.