6

I use remote debug with PhpStorm, xdebug and nginx + php-fpm. Nginx repsond with 502 error code (Bad Gateway) when I pass XDEBUG_SESSION_START=my_ide_key in request GET parameter. At the same time my code breakpoints in IDE work fine. When I don't pass XDEBUG_SESSION_START parameter nginx respond with well-formatted HTML and code 200. But obvious without this parameter it is no debugging.

In nginx error log I see notifications about to big header received from upstream. I try to dump communication between php-fpm and nginx and just one different thing is one Set-Cookie header:

Set-Cookie: XDEBUG_SESSION=666; expires=Mon, 16-Sep-2013 16:07:28 GMT; path=/

I try to find when this headers appears in response. And I found that in my smarty plugin Smarty_Internal_Template destructors (after last code line of my start up script) if I call headers_list() I see growing up amount of Set-Cookie headers (equal destructor calls and Set-Cookie headers amount). I am sure that there is no one explicit header('Set-Cookie: XDEBUG_SESSION=...') call in my code. I try to upgrade and downgrade xdebug version but still have same behavior. Place code remove_header('Set-Cookie') at Smarty_Internal_Template solves my problem but that is ugly hack!

Any ideas about this strange situation?

Ivan Velichko
  • 6,348
  • 6
  • 44
  • 90
  • 1
    Some additional information: it looks like the 'Set-Cookie' header gets called for every registered shutdown function (from when I saw upon stepping through the execution of my shutdown functions). Smarty is not being used at all in my case. Seems it's just a php-shutdown-function-in-general thing. – jdunk Jan 04 '16 at 19:27
  • 1
    Another oddity that may or may not be related: `headers_list()` also shows me that *two* 'Set-Cookie' headers for XDEBUG_SESSION are already set by line 1 of my php code. – jdunk Jan 04 '16 at 19:30

1 Answers1

1

I would suggest not using XDEBUG_SESSION_START in this case. To me it looks like XDEBUG_SESSION_START is triggering some code execution on the server side to set the cookie. And that is interfering with smarty template code.

In all of my experience with PHPStorm, I have found that the best way to turn on xdebug is through the bookmarklet, which you can generate here:

https://www.jetbrains.com/phpstorm/marklets/

The bookmarklet sets the cookie in the browser itself. So, no code is executed in the server to set XDEBUG_SESSION and path variables and that could reduce or eliminate the interference with smarty code.

Also, one tip with PHPStorm is to make sure that the PHPStorm is up and running and the network connection is working properly between PHPStorm and php-fpm (I presume that is what you are using in combination with nginx).

If php-fpm cannot connect to PHPStorm, in my experience, the code will eventually execute on the server but it will be very slow.

There have been a few times when I have seen this wrongly as a performance problem and wasted lots of time.

Devang Mehta
  • 137
  • 1
  • 5
  • I'm afraid that I can't verify or even evaluate your answer because I'm not at PHP anymore. So, I would like to receive any comments from the bounty-starter @jdunk. – Ivan Velichko Jan 01 '16 at 12:17
  • 1
    @Devang, while I appreciate the effort, this really does not answer the question, which is "Why are these extra 'Set-Cookie' headers getting added at shutdown time?" While it's true that using the cookie instead of the GET param does result in those extra headers not being produced, this requires using the cookie, and cookies are for persistence. Using the GET param is the only way to say "this request only" so that, for example, when a browser fires off several other requests which also get processed by php, one isn't stuck in a debugger loop well beyond that first request. – jdunk Jan 04 '16 at 19:01
  • 1
    The purpose in my posting the bounty was for insight particular to xdebug and/or why those headers are getting set. I have my own workaround, and @Ostrovski provided one in his question. The bounty is for a somewhat satisfying answer re: the mechanics of those xdebug headers. – jdunk Jan 04 '16 at 19:10
  • I see the point. I think off the top of my head I wouldn't know. Like @Ostrovski, I am not that active in php these days, we are moving to python. To do a debugging effort in php will take too much time. My suggestion is contact jetbrains directly and refer this question to them. I am sure one of their developers will like the bounty. – Devang Mehta Jan 06 '16 at 06:45