Xdebug set cookie XDEBUG_SESSION troppe volte

Uso il debug remoto con PhpStorm, xdebug e nginx + php-fpm. Nginx repsond con 502 codice di errore (Bad Gateway) quando passo XDEBUG_SESSION_START=my_ide_key nel parametro richiesta GET. Allo stesso tempo, i miei breakpoint di codice in IDE funzionano bene. Quando non passo il parametro XDEBUG_SESSION_START, nginx risponde con codice HTML ben formattato e codice 200. Ma ovvio senza questo parametro non è il debug.Xdebug set cookie XDEBUG_SESSION troppe volte

Nel registro degli errori di nginx vengono visualizzate le notifiche relative alla grande intestazione ricevuta da monte. Io cerco di scaricare la comunicazione tra PHP-FPM e nginx e solo una cosa diversa è uno Set-Cookie intestazione:

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

cerco di trovare quando questo intestazioni appare in risposta. E ho trovato questo nel mio smarty plug-in Smarty_Internal_Template distruttori (dopo l'ultima riga di codice del mio script di avvio) se chiamo headers_list() vedo crescere la quantità di intestazioni Set-Cookie (pari chiamate di distruttore e quantità di intestazioni Set-Cookie). Sono sicuro che non c'è nessuna chiamata esplicita header('Set-Cookie: XDEBUG_SESSION=...') nel mio codice. Provo ad aggiornare e downgrade la versione di xdebug, ma ho lo stesso comportamento. Il codice di luogo remove_header('Set-Cookie') a Smarty_Internal_Template risolve il mio problema ma quello è brutto hack!

Qualche idea su questa strana situazione?

fonte

2013-09-16 Ivan Velichko

Alcune informazioni aggiuntive: sembra che l'intestazione 'Set-Cookie' venga chiamata per ogni funzione di arresto registrato (da quando ho visto l'esecuzione delle mie funzioni di spegnimento). Smarty non viene usata affatto nel mio caso. Sembra che sia solo una funzione di php-shutdown-in-general. – jdunk

Un'altra stranezza che può essere correlata o meno: 'headers_list()' mi mostra anche che * due * intestazioni Set-Cookie per XDEBUG_SESSION sono già impostate dalla riga 1 del mio codice php. – jdunk

In questo caso, suggerisco di non utilizzare XDEBUG_SESSION_START. Mi sembra che XDEBUG_SESSION_START stia attivando alcuni codici di esecuzione sul lato server per impostare il cookie. E questo sta interferendo con il codice del modello smarty.

In tutta la mia esperienza con PhpStorm, ho trovato che il modo migliore per accendere xdebug è attraverso il bookmarklet, che è possibile generare qui:

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

Il bookmarklet imposta il cookie nel browser stesso. Pertanto, nel server non viene eseguito alcun codice per impostare XDEBUG_SESSION e le variabili di percorso e questo potrebbe ridurre o eliminare l'interferenza con il codice smarty.

Inoltre, un suggerimento con PHPStorm è assicurarsi che PHPStorm sia attivo e in esecuzione e che la connessione di rete funzioni correttamente tra PHPStorm e php-fpm (presumo che sia quello che si sta utilizzando in combinazione con nginx).

Se php-fpm non è in grado di connettersi a PHPStorm, nella mia esperienza, il codice verrà eseguito sul server ma sarà molto lento.

Ci sono state alcune volte in cui ho visto questo in modo errato come un problema di prestazioni e ho perso un sacco di tempo.

fonte

2016-01-01 11:44:55

Ho paura di non poter verificare o valutare la tua risposta perché non sono più in PHP. Quindi, vorrei ricevere eventuali commenti dal bounty-starter @jdunk. –

@Devang, mentre apprezzo lo sforzo, questo in realtà non risponde alla domanda, che è "Perché queste intestazioni extra 'Set-Cookie' vengono aggiunte al momento dell'arresto?" Mentre è vero che l'uso del cookie al posto del parametro GET fa sì che tali intestazioni extra non vengano prodotte, ciò richiede l'utilizzo del cookie e i cookie sono per la persistenza.L'utilizzo del parametro GET è l'unico modo per dire "solo questa richiesta" in modo che, ad esempio, quando un browser attiva diverse altre richieste che vengono elaborate da php, non si è bloccati in un loop del debugger ben oltre quella prima richiesta . – jdunk

Lo scopo nel postare la taglia è stato per insight in particolare su xdebug e/o sul perché queste intestazioni sono state impostate. Ho una mia soluzione, e @Ostrovski ne ha fornito uno nella sua domanda. La taglia è per una risposta piuttosto soddisfacente: la meccanica di quegli header xdebug. – jdunk

Xdebug set cookie XDEBUG_SESSION troppe volte

risposta

Problemi correlati