0

I have some experience with xdebug and if push comes to shove, I can even debug PHP with gdb but Guzzle 6 is so abstracted I can't easily find a good place to add a breakpoint to investigate how 1) request headers 2) request body is put together 3) where the request is sent to 4) what the response is. (Wrapping everything into streams makes this even more impossible) How do you log all API calls using Guzzle 6 answers some of this but that is only helpful if you don't break Guzzle itself -- which is not quite the case when trying to create a middleware... so where can I find a Guzzle 6 internal documentation? Tips and tricks on debugging it?

Community
  • 1
  • 1
chx
  • 11,270
  • 7
  • 55
  • 129

1 Answers1

0

It would be simpler to use xdebug to debug Guzzle and answer your questions.

Some instructions how to use xdebug with PhpStorm, with vim.

It allows to debug PHP script, instead of debugging php interpreter:

Using your favourite IDE set a breakpoint in your middleware and step-into through the stack of handlers. It may worth to add a break on exception.

If you need to use gdb to debug php - I'd recommend to debug it against unittests, where you can exclude all Guzzle complexity by running individual tests.

Going dipper, you can use strace to debug sockets and system calls, and tcpdump to debug it on packets level.

Alex Blex
  • 34,704
  • 7
  • 48
  • 75
  • That presumes my middleware is not broken by itself; that it doesn't break Guzzle; that it doesn't conflict with other midldewares... so yeah it would be simpler to use xdebug to debug Guzzle and answer your questions. How? Mind you, that's what the original question is so I am not quite sure how much this answer helped. – chx Sep 13 '16 at 20:14
  • Fair point. I assumed your middleware is unittested and is not broken. I have added few lines how to use xdebug to find out where middlewares conflict to such degree, that it doesn't reach log middleware. – Alex Blex Sep 13 '16 at 23:00