Et alors, tu as trouvé la source du problème? Cordialement
-- MrJK GPG: https://jeznet.org/jez.asc Le 23 mars 2015 13:58, Mrjk <mrjk...@gmail.com> a écrit : > Bah, les problèmes d'heure, ça fait souvent des effets de bords ... qui > sait ? > > Pour régler le problème: > -> Si décalage de quelques minutes: il faut installer le daemon ntpd pour > qu'il aille se synchroniser avec un serveur NTP. La machine sera à l'heure > exacte. > -> Si décalage de fuseau horaire: Il faut regarder la directive > date.timezone dans le php.ini du mod_apache (ou du FPM). Cf: > http://php.net/manual/fr/datetime.configuration.php#ini.date.timezone > > Dans tous les cas, je recommande l'installation d'un client NTP, surtout > si tu as un pool de serveur ... > > > -- > MrJK > GPG: https://jeznet.org/jez.asc > > Le 23 mars 2015 10:58, Christophe LE PORT <c.lep...@hotmail.fr> a écrit : > > Bonjour, >> >> merci encore pour votre aide. >> Je suis sur les tests ce matin, mais comme c'est aléatoire c'est assez >> long pour valider les étapes. >> >> En créant une page php avec >> > // Start full report >> > echo "<h1>SERVER: DATE</h1>"; >> > echo "<pre>"; >> > print_r(date("Y/m/d h:i:sa")); >> > echo "</pre>"; >> > echo "<h1>HTTP: REQUEST HEADER</h1>"; >> > echo "<pre>"; >> > print_r(getallheaders()); >> > echo "</pre>"; >> >> Je me suis rendu compte que l'heure donnée par php ne corresponds pas >> avec celle donnée par le serveur. >> >> Savez-vous quels impacts cela peut-il avoir ? >> >> Merci >> >> >> >> >> > From: frsag-requ...@frsag.org >> > Subject: Lot FRsAG, Vol 183, Parution 1 >> > To: frsag@frsag.org >> > Date: Mon, 23 Mar 2015 01:22:58 +0100 >> > >> > Envoyez vos messages pour la liste FRsAG à >> > frsag@frsag.org >> > >> > Pour vous (dés)abonner par le web, consultez >> > http://www.frsag.org/mailman/listinfo/frsag >> > >> > ou, par email, envoyez un message avec 'help' dans le corps ou dans le >> > sujet à >> > frsag-requ...@frsag.org >> > >> > Vous pouvez contacter l'administrateur de la liste à l'adresse >> > frsag-ow...@frsag.org >> > >> > Si vous répondez, n'oubliez pas de changer l'objet du message afin >> > qu'il soit plus spécifique que "Re: Contenu du digest de FRsAG..." >> > >> > >> > Thèmes du jour : >> > >> > 1. Re: Apache rafraichissement page (Baptiste) >> > 2. Re: Apache rafraichissement page (Emmanuel Thierry) >> > 3. Re: Apache rafraichissement page (Christophe LE PORT) >> > 4. Re: Apache rafraichissement page (j...@captainadmin.com) >> > 5. Re: Apache rafraichissement page (Mrjk) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Sun, 22 Mar 2015 12:00:00 +0100 >> > From: Baptiste <bed...@gmail.com> >> > To: Christophe LE PORT <c.lep...@hotmail.fr> >> > Cc: "frsag@frsag.org" <frsag@frsag.org> >> > Subject: Re: [FRsAG] Apache rafraichissement page >> > Message-ID: >> > <caodhi7q4m+ch0pdgt2xbwb3v6wtnmoixokkzw6w3ejznkgd...@mail.gmail.com> >> > Content-Type: text/plain; charset=ISO-8859-1 >> > >> > 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.lep...@hotmail.fr>: >> > > Bonjour, >> > > >> > > J'ai un soucis avec httpd 2.4.6 sur centos 7 >> > > >> > > Le serveur apache marche bien seulement quand j'ouvre une page sur le >> port >> > > 80 et que je rafraichis la page au bout d' un certain temps (environ >> >5mn) , >> > > ça plante (comme çi la page n'existait pas) >> > > >> > > Via notre reverse, il nous affiche l'erreur suivante : >> > > >> > > Proxy Error >> > > >> > > The proxy server received an invalid response from an upstream server. >> > > The proxy server could not handle the request GET /test.php. >> > > >> > > Reason: Error reading from remote server >> > > >> > > >> > > Au niveau des entêtes html, voici le cas d'un fonctionnement normal : >> > > >> > > Host: test.site15.net >> > > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) >> Gecko/20100101 >> > > Firefox/36.0 >> > > Accept: >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> > > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 >> > > Accept-Encoding: gzip, deflate >> > > Connection: keep-alive >> > > >> > > >> > > Cache-Control: no-cache >> > > Connection: Keep-Alive >> > > Content-Type: text/html; charset=UTF-8 >> > > Date: Sun, 22 Mar 2015 09:07:10 GMT >> > > Keep-Alive: timeout=5, max=100 >> > > Server: Apache/2.4.6 (CentOS) PHP/5.4.16 >> > > Transfer-Encoding: chunked >> > > Via: 1.1 test.site15.net >> > > X-Debug-Token: 674072 >> > > X-Powered-By: PHP/5.4.16 >> > > >> > > Voici la réponse html lors d'un plantage : >> > > >> > > Connection: Keep-Alive >> > > Content-Length: 401 >> > > Content-Type: text/html; charset=iso-8859-1 >> > > Date: Sun, 22 Mar 2015 09:30:03 GMT >> > > Keep-Alive: timeout=5, max=100 >> > > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> > > >> > > >> > > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que je >> fais une >> > > requête sur le port 80. >> > > >> > > Sur une analyse wireshark, on peut observer que le serveur envoi des >> TCP RST >> > > après la demande de GET du client alors qu'une connexion tcp est bien >> établi >> > > juste avant d'envoyer le GET HTTP. >> > > >> > > J'ai essayé de jouer avec le paramètre keepalive, sans succès ! >> > > >> > > Si quelqu'un à des pistes ? >> > > >> > > Merci, >> > > >> > > Christophe >> > > >> > >> > >> > Salut, >> > >> > Tu pourrais partager la trace réseau, même en PV? >> > Ainsi que les logs Apache... >> > J'ai déjà vu ce genre de comportement avec HAProxy, mais avec un >> > client chrome, c'etait lié au "pre-connect" et à une mauvaise gestion >> > du buffer de reception côté client. >> > >> > Baptiste >> > >> > >> > ------------------------------ >> > >> > Message: 2 >> > Date: Sun, 22 Mar 2015 12:15:44 +0100 >> > From: Emmanuel Thierry <m...@sekil.fr> >> > To: Christophe LE PORT <c.lep...@hotmail.fr> >> > Cc: "frsag@frsag.org" <frsag@frsag.org> >> > Subject: Re: [FRsAG] Apache rafraichissement page >> > Message-ID: <b0a99c40-f8b1-451e-a4c5-bdedf505d...@sekil.fr> >> > Content-Type: text/plain; charset=iso-8859-1 >> > >> > Bonjour, >> > >> > Le 22 mars 2015 à 11:31, Christophe LE PORT a écrit : >> > >> > > >> > > Connection: Keep-Alive >> > > Content-Length: 401 >> > > Content-Type: text/html; charset=iso-8859-1 >> > > Date: Sun, 22 Mar 2015 09:30:03 GMT >> > > Keep-Alive: timeout=5, max=100 >> > > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> > > >> > > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que je >> fais une requête sur le port 80. >> > >> > Le header Server de apache est le même que tu l'utilises en HTTP ou >> HTTPS. Ça veut juste dire que ton apache a été compilé avec le support TLS. >> > >> > Cordialement >> > Emmanuel Thierry >> > >> > >> > >> > ------------------------------ >> > >> > Message: 3 >> > Date: Sun, 22 Mar 2015 16:30:10 +0100 >> > From: Christophe LE PORT <c.lep...@hotmail.fr> >> > To: Baptiste <bed...@gmail.com>, "webmas...@ajeux.com" >> > <webmas...@ajeux.com> >> > Cc: "frsag@frsag.org" <frsag@frsag.org> >> > Subject: Re: [FRsAG] Apache rafraichissement page >> > Message-ID: <dub119-w40f81e84e5d8b5e9298cffe7...@phx.gbl> >> > Content-Type: text/plain; charset="iso-8859-1" >> > >> > Merci pour vos réponses, >> > @Manu -> Le problème est identique que ce soit en direct ou en passant >> par le reverse >> > >> > @Baptiste et Olivier >> > Il n'y aucune trace au niveau des logs httpd (passé en mode debug) sur >> le serveur apache >> > Au niveau du proxy, il me retourne ces 2 lignes : >> > [Sun Mar 22 16:09:41.754637 2015] [proxy_http:error] [pid 19583] >> (104)Connection reset by peer: [client 2.2.227.125:64566] AH01102: error >> reading status line from remote server 192.168.0.234:80[Sun Mar 22 >> 16:09:41.755049 2015] [proxy:error] [pid 19583] [client 2.2.227.124:64566] >> AH00898: Error reading from remote server returned by /test.php >> > >> > > Date: Sun, 22 Mar 2015 12:00:00 +0100 >> > > Subject: Re: [FRsAG] Apache rafraichissement page >> > > From: bed...@gmail.com >> > > To: c.lep...@hotmail.fr >> > > CC: frsag@frsag.org >> > > >> > > 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.lep...@hotmail.fr>: >> > > > Bonjour, >> > > > >> > > > J'ai un soucis avec httpd 2.4.6 sur centos 7 >> > > > >> > > > Le serveur apache marche bien seulement quand j'ouvre une page sur >> le port >> > > > 80 et que je rafraichis la page au bout d' un certain temps >> (environ >5mn) , >> > > > ça plante (comme çi la page n'existait pas) >> > > > >> > > > Via notre reverse, il nous affiche l'erreur suivante : >> > > > >> > > > Proxy Error >> > > > >> > > > The proxy server received an invalid response from an upstream >> server. >> > > > The proxy server could not handle the request GET /test.php. >> > > > >> > > > Reason: Error reading from remote server >> > > > >> > > > >> > > > Au niveau des entêtes html, voici le cas d'un fonctionnement normal >> : >> > > > >> > > > Host: test.site15.net >> > > > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) >> Gecko/20100101 >> > > > Firefox/36.0 >> > > > Accept: >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> > > > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 >> > > > Accept-Encoding: gzip, deflate >> > > > Connection: keep-alive >> > > > >> > > > >> > > > Cache-Control: no-cache >> > > > Connection: Keep-Alive >> > > > Content-Type: text/html; charset=UTF-8 >> > > > Date: Sun, 22 Mar 2015 09:07:10 GMT >> > > > Keep-Alive: timeout=5, max=100 >> > > > Server: Apache/2.4.6 (CentOS) PHP/5.4.16 >> > > > Transfer-Encoding: chunked >> > > > Via: 1.1 test.site15.net >> > > > X-Debug-Token: 674072 >> > > > X-Powered-By: PHP/5.4.16 >> > > > >> > > > Voici la réponse html lors d'un plantage : >> > > > >> > > > Connection: Keep-Alive >> > > > Content-Length: 401 >> > > > Content-Type: text/html; charset=iso-8859-1 >> > > > Date: Sun, 22 Mar 2015 09:30:03 GMT >> > > > Keep-Alive: timeout=5, max=100 >> > > > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> > > > >> > > > >> > > > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que je >> fais une >> > > > requête sur le port 80. >> > > > >> > > > Sur une analyse wireshark, on peut observer que le serveur envoi >> des TCP RST >> > > > après la demande de GET du client alors qu'une connexion tcp est >> bien établi >> > > > juste avant d'envoyer le GET HTTP. >> > > > >> > > > J'ai essayé de jouer avec le paramètre keepalive, sans succès ! >> > > > >> > > > Si quelqu'un à des pistes ? >> > > > >> > > > Merci, >> > > > >> > > > Christophe >> > > > >> > > >> > > >> > > Salut, >> > > >> > > Tu pourrais partager la trace réseau, même en PV? >> > > Ainsi que les logs Apache... >> > > J'ai déjà vu ce genre de comportement avec HAProxy, mais avec un >> > > client chrome, c'etait lié au "pre-connect" et à une mauvaise gestion >> > > du buffer de reception côté client. >> > > >> > > Baptiste >> > >> > -------------- section suivante -------------- >> > Une pièce jointe HTML a été nettoyée... >> > URL: < >> http://www.frsag.org/pipermail/frsag/attachments/20150322/323d5ea9/attachment-0001.html >> > >> > >> > ------------------------------ >> > >> > Message: 4 >> > Date: Sun, 22 Mar 2015 23:28:41 +0100 >> > From: j...@captainadmin.com >> > To: frsag@frsag.org >> > Subject: Re: [FRsAG] Apache rafraichissement page >> > Message-ID: <1453bd49c0ee26948f69ae321b684...@captainadmin.com> >> > Content-Type: text/plain; charset=UTF-8; format=flowed >> > >> > Bonsoir, >> > >> > Il faut vérifier si le flux arrive toujours sur le serveur final avec >> un >> > tcpdump par exemple. >> > En regardant les logs apache, a supposer que ton vhost soit >> correctement >> > configuré, tu devrais avoir des informations dans /var/log/httpd/*.log >> > qui te permettront de trouver plus facilement l'erreur. >> > >> > Si tu rafraichis plusieurs fois, le problème persiste ou la page ne >> > s'affiche toujours pas? >> > Ton test.php pourrait-être un simple >> > <?php >> > >> > // Show all information, defaults to INFO_ALL >> > phpinfo(); >> > >> > ?> >> > >> > pour être sur que ce en soit pas php qui pose problème ? >> > >> > Bonne soirée >> > http://www.captainadmin.com >> > >> > >> > >> > >> > Le 22-03-2015 16:30, Christophe LE PORT a écrit : >> > > Merci pour vos réponses, >> > > >> > > @Manu -> Le problème est identique que ce soit en direct ou en >> > > passant par le reverse >> > > >> > > @Baptiste et Olivier >> > > >> > > Il n'y aucune trace au niveau des logs httpd (passé en mode debug) >> > > sur le serveur apache >> > > >> > > Au niveau du proxy, il me retourne ces 2 lignes : >> > > >> > > [Sun Mar 22 16:09:41.754637 2015] [proxy_http:error] [pid 19583] >> > > (104)Connection reset by peer: [client 2.2.227.125:64566] AH01102: >> > > error reading status line from remote server 192.168.0.234:80 >> > > >> > > [Sun Mar 22 16:09:41.755049 2015] [proxy:error] [pid 19583] [client >> > > 2.2.227.124:64566] AH00898: Error reading from remote server returned >> > > by /test.php >> > > >> > >> Date: Sun, 22 Mar 2015 12:00:00 +0100 >> > >> Subject: Re: [FRsAG] Apache rafraichissement page >> > >> From: bed...@gmail.com >> > >> To: c.lep...@hotmail.fr >> > >> CC: frsag@frsag.org >> > >> >> > >> 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.lep...@hotmail.fr>: >> > >> > Bonjour, >> > >> > >> > >> > J'ai un soucis avec httpd 2.4.6 sur centos 7 >> > >> > >> > >> > Le serveur apache marche bien seulement quand j'ouvre une page sur >> > > le port >> > >> > 80 et que je rafraichis la page au bout d' un certain temps >> > > (environ >5mn) , >> > >> > ça plante (comme çi la page n'existait pas) >> > >> > >> > >> > Via notre reverse, il nous affiche l'erreur suivante : >> > >> > >> > >> > Proxy Error >> > >> > >> > >> > The proxy server received an invalid response from an upstream >> > > server. >> > >> > The proxy server could not handle the request GET /test.php. >> > >> > >> > >> > Reason: Error reading from remote server >> > >> > >> > >> > >> > >> > Au niveau des entêtes html, voici le cas d'un fonctionnement >> > > normal : >> > >> > >> > >> > Host: test.site15.net >> > >> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) >> > > Gecko/20100101 >> > >> > Firefox/36.0 >> > >> > Accept: >> > > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> > >> > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 >> > >> > Accept-Encoding: gzip, deflate >> > >> > Connection: keep-alive >> > >> > >> > >> > >> > >> > Cache-Control: no-cache >> > >> > Connection: Keep-Alive >> > >> > Content-Type: text/html; charset=UTF-8 >> > >> > Date: Sun, 22 Mar 2015 09:07:10 GMT >> > >> > Keep-Alive: timeout=5, max=100 >> > >> > Server: Apache/2.4.6 (CentOS) PHP/5.4.16 >> > >> > Transfer-Encoding: chunked >> > >> > Via: 1.1 test.site15.net >> > >> > X-Debug-Token: 674072 >> > >> > X-Powered-By: PHP/5.4.16 >> > >> > >> > >> > Voici la réponse html lors d'un plantage : >> > >> > >> > >> > Connection: Keep-Alive >> > >> > Content-Length: 401 >> > >> > Content-Type: text/html; charset=iso-8859-1 >> > >> > Date: Sun, 22 Mar 2015 09:30:03 GMT >> > >> > Keep-Alive: timeout=5, max=100 >> > >> > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> > >> > >> > >> > >> > >> > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que >> > > je fais une >> > >> > requête sur le port 80. >> > >> > >> > >> > Sur une analyse wireshark, on peut observer que le serveur envoi >> > > des TCP RST >> > >> > après la demande de GET du client alors qu'une connexion tcp est >> > > bien établi >> > >> > juste avant d'envoyer le GET HTTP. >> > >> > >> > >> > J'ai essayé de jouer avec le paramètre keepalive, sans succès ! >> > >> > >> > >> > Si quelqu'un à des pistes ? >> > >> > >> > >> > Merci, >> > >> > >> > >> > Christophe >> > >> > >> > >> >> > >> >> > >> Salut, >> > >> >> > >> Tu pourrais partager la trace réseau, même en PV? >> > >> Ainsi que les logs Apache... >> > >> J'ai déjà vu ce genre de comportement avec HAProxy, mais avec un >> > >> client chrome, c'etait lié au "pre-connect" et à une mauvaise >> > > gestion >> > >> du buffer de reception côté client. >> > >> >> > >> Baptiste >> > > >> > > _______________________________________________ >> > > Liste de diffusion du FRsAG >> > > http://www.frsag.org/ >> > >> > >> > ------------------------------ >> > >> > Message: 5 >> > Date: Mon, 23 Mar 2015 01:22:32 +0100 >> > From: Mrjk <mrjk...@gmail.com> >> > To: j...@captainadmin.com >> > Cc: French SysAdmin Group <frsag@frsag.org> >> > Subject: Re: [FRsAG] Apache rafraichissement page >> > Message-ID: >> > <CAPhPNGNk2h=u9a0mcj7tvjpxtnno2dmc+8htn5qw6adsxul...@mail.gmail.com> >> > Content-Type: text/plain; charset="utf-8" >> > >> > Bonsoir, >> > >> > Avec les informations que tu nous a indiquées, j'essayerai de répondre >> aux >> > questions suivantes. >> > >> > Je pars du constat que: Le problème est reproduisible directement sur la >> > machine (sans le HAProxy), cependant il peut toujours y avoir un >> problème >> > de réseau. >> > >> > Test 1: >> > ######### >> > Essayer de reproduire le problème depuis le localhost de ton serveur >> (wget >> > --headers="Host:mondomaine.com" 127.0.0.1/test.php) >> > --> Si le problème se reproduit à l'identique depuis le localhost et >> depuis >> > ton poaste local, le problème n'est pas au niveau du réseau, mais au >> niveau >> > de la machine. >> > --> Si le problème ne se reproduit pas, c'est probablement un problème >> de >> > firewall ou de proxy (mais visiblement, ce n'est pas le cas) >> > >> > Test 2: >> > ######### >> > Essayer de voir si c'est Apache le problème, ou plutôt le module PHP >> > (mod_php ou PHP-FPM). Essayer de servir un fichier html et un fichier >> PHP, >> > pour voir si le problème se reproduit sur le HTML >> > --> Si le problème existe sur les deux, le problème vient d'apache >> > --> Si le problème vient seulement du code PHP, le problème vient de ... >> > PHP ^^ >> > >> > Test 3: >> > ######### >> > Si c'est PHP, et en supposant que ce ne soit pas un problème de >> > programmation, il faut essayer de reproduire le pb avec une page comme >> > ci-dessous (à toi de le modifier pour qu'il corresponde à tes besoins). >> > Après, il faut aller éplucher les logs pour voir ce qu'il se passe: >> > >> > Note: Faire attention si y'a du cache PHP, ça peut être interressant de >> le >> > désactiver pendant les tests, en supposant que ce ne soit pas la source >> du >> > problème. >> > >> > <?php >> > >> > // Disable cache >> > header("Expires: on, 01 Jan 1970 00:00:00 GMT"); >> > header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); >> > header("Cache-Control: no-store, no-cache, must-revalidate"); >> > header("Cache-Control: post-check=0, pre-check=0", false); >> > header("Pragma: no-cache"); >> > >> > // Send a syslog message >> > openlog('apache2', LOG_CONS | LOG_NDELAY | LOG_PID, LOG_USER | >> LOG_PERROR); >> > syslog(LOG_NOTICE, 'Debug: Notice test message (1/3)'); >> > syslog(LOG_INFO, 'Debug: Info test message (2/3)'); >> > syslog(LOG_ERR, 'Debug: Error test message (3/3)'); >> > closelog(); >> > >> > // Start full report >> > echo "<h1>SERVER: DATE</h1>"; >> > echo "<pre>"; >> > print_r(date("Y/m/d h:i:sa")); >> > echo "</pre>"; >> > echo "<h1>HTTP: REQUEST HEADER</h1>"; >> > echo "<pre>"; >> > print_r(getallheaders()); >> > echo "</pre>"; >> > >> > echo "<h1>HTTP: SERVER</h1>"; >> > echo "<pre>"; >> > print_r ($_SERVER); >> > echo "</pre>"; >> > >> > echo "<h1>HTTP: POST DATA</h1>"; >> > echo "<pre>"; >> > print_r($_POST); >> > echo "</pre>"; >> > >> > echo "<h1>PHP: PHPINFO</h1>"; >> > phpinfo(); >> > ?> >> > >> > Test 4: >> > ######### >> > - Penser au contexte: le problème arrive tout le temps? Quand y'a de la >> > charge? Quand y'en a pas? Pendant des backups? Pendant un check de la >> > supervision (omg) ? >> > - Penser au cache PHP, si y'en a un ... >> > - Penser à la conf de PHP et/ou Apache >> > - Si tu as un pool de serveur derrière, penser à la concurrence: des >> > modifications sur des fichiers lockées, des requetes mysql en attente, >> des >> > accès concurrents, etc ... >> > - Faire un strace sur le process qui sert le fichier (franchement pas >> > facile avec le mod_php, mais ça se fait, l'idée est de sortir la >> machine de >> > ton pool de prod, si tu en a un, pour faire tes tests) >> > >> > Test 5: >> > ######### >> > En dernier recours, essayer de voir si le problème se reproduit dans un >> > environnement neuf, et essayer de faire le diff des confs. C'est long et >> > pas élégant, mais c'est pour ça que c'est le test 5 et qu'il y'en a pas >> > après ^^ >> > >> > >> > Et si c'est pas dans tout ce que j'ai dit, je parie une bière que c'est >> un >> > problème de code, ou sous-jacent :-D On sous-estime toujours les codeurs >> > dans l'accomplissement de leur exploits techniques, huhu (</troll>) :D >> > >> > Bon courage, je serai curieux de savoir ce que c'était au final :-) >> > -- >> > MrJK >> > GPG: https://jeznet.org/jez.asc >> > >> > Le 22 mars 2015 23:28, <j...@captainadmin.com> a écrit : >> > >> > > Bonsoir, >> > > >> > > Il faut vérifier si le flux arrive toujours sur le serveur final avec >> un >> > > tcpdump par exemple. >> > > En regardant les logs apache, a supposer que ton vhost soit >> correctement >> > > configuré, tu devrais avoir des informations dans >> /var/log/httpd/*.log qui >> > > te permettront de trouver plus facilement l'erreur. >> > > >> > > Si tu rafraichis plusieurs fois, le problème persiste ou la page ne >> > > s'affiche toujours pas? >> > > Ton test.php pourrait-être un simple >> > > <?php >> > > >> > > // Show all information, defaults to INFO_ALL >> > > phpinfo(); >> > > >> > > ?> >> > > >> > > pour être sur que ce en soit pas php qui pose problème ? >> > > >> > > Bonne soirée >> > > http://www.captainadmin.com >> > > >> > > >> > > >> > > >> > > Le 22-03-2015 16:30, Christophe LE PORT a écrit : >> > > >> > >> Merci pour vos réponses, >> > >> >> > >> @Manu -> Le problème est identique que ce soit en direct ou en >> > >> passant par le reverse >> > >> >> > >> @Baptiste et Olivier >> > >> >> > >> Il n'y aucune trace au niveau des logs httpd (passé en mode debug) >> > >> sur le serveur apache >> > >> >> > >> Au niveau du proxy, il me retourne ces 2 lignes : >> > >> >> > >> [Sun Mar 22 16:09:41.754637 2015] [proxy_http:error] [pid 19583] >> > >> (104)Connection reset by peer: [client 2.2.227.125:64566] AH01102: >> > >> error reading status line from remote server 192.168.0.234:80 >> > >> >> > >> [Sun Mar 22 16:09:41.755049 2015] [proxy:error] [pid 19583] [client >> > >> 2.2.227.124:64566] AH00898: Error reading from remote server >> returned >> > >> by /test.php >> > >> >> > >> Date: Sun, 22 Mar 2015 12:00:00 +0100 >> > >>> Subject: Re: [FRsAG] Apache rafraichissement page >> > >>> From: bed...@gmail.com >> > >>> To: c.lep...@hotmail.fr >> > >>> CC: frsag@frsag.org >> > >>> >> > >>> 2015-03-22 11:31 GMT+01:00 Christophe LE PORT <c.lep...@hotmail.fr >> >: >> > >>> > Bonjour, >> > >>> > >> > >>> > J'ai un soucis avec httpd 2.4.6 sur centos 7 >> > >>> > >> > >>> > Le serveur apache marche bien seulement quand j'ouvre une page sur >> > >>> >> > >> le port >> > >> >> > >>> > 80 et que je rafraichis la page au bout d' un certain temps >> > >>> >> > >> (environ >5mn) , >> > >> >> > >>> > ça plante (comme çi la page n'existait pas) >> > >>> > >> > >>> > Via notre reverse, il nous affiche l'erreur suivante : >> > >>> > >> > >>> > Proxy Error >> > >>> > >> > >>> > The proxy server received an invalid response from an upstream >> > >>> >> > >> server. >> > >> >> > >>> > The proxy server could not handle the request GET /test.php. >> > >>> > >> > >>> > Reason: Error reading from remote server >> > >>> > >> > >>> > >> > >>> > Au niveau des entêtes html, voici le cas d'un fonctionnement >> > >>> >> > >> normal : >> > >> >> > >>> > >> > >>> > Host: test.site15.net >> > >>> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) >> > >>> >> > >> Gecko/20100101 >> > >> >> > >>> > Firefox/36.0 >> > >>> > Accept: >> > >>> >> > >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> > >> >> > >>> > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 >> > >>> > Accept-Encoding: gzip, deflate >> > >>> > Connection: keep-alive >> > >>> > >> > >>> > >> > >>> > Cache-Control: no-cache >> > >>> > Connection: Keep-Alive >> > >>> > Content-Type: text/html; charset=UTF-8 >> > >>> > Date: Sun, 22 Mar 2015 09:07:10 GMT >> > >>> > Keep-Alive: timeout=5, max=100 >> > >>> > Server: Apache/2.4.6 (CentOS) PHP/5.4.16 >> > >>> > Transfer-Encoding: chunked >> > >>> > Via: 1.1 test.site15.net >> > >>> > X-Debug-Token: 674072 >> > >>> > X-Powered-By: PHP/5.4.16 >> > >>> > >> > >>> > Voici la réponse html lors d'un plantage : >> > >>> > >> > >>> > Connection: Keep-Alive >> > >>> > Content-Length: 401 >> > >>> > Content-Type: text/html; charset=iso-8859-1 >> > >>> > Date: Sun, 22 Mar 2015 09:30:03 GMT >> > >>> > Keep-Alive: timeout=5, max=100 >> > >>> > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips >> > >>> > >> > >>> > >> > >>> > Je me demande ce que viens faire "OpenSSL/1.0.1e-fips" alors que >> > >>> >> > >> je fais une >> > >> >> > >>> > requête sur le port 80. >> > >>> > >> > >>> > Sur une analyse wireshark, on peut observer que le serveur envoi >> > >>> >> > >> des TCP RST >> > >> >> > >>> > après la demande de GET du client alors qu'une connexion tcp est >> > >>> >> > >> bien établi >> > >> >> > >>> > juste avant d'envoyer le GET HTTP. >> > >>> > >> > >>> > J'ai essayé de jouer avec le paramètre keepalive, sans succès ! >> > >>> > >> > >>> > Si quelqu'un à des pistes ? >> > >>> > >> > >>> > Merci, >> > >>> > >> > >>> > Christophe >> > >>> > >> > >>> >> > >>> >> > >>> Salut, >> > >>> >> > >>> Tu pourrais partager la trace réseau, même en PV? >> > >>> Ainsi que les logs Apache... >> > >>> J'ai déjà vu ce genre de comportement avec HAProxy, mais avec un >> > >>> client chrome, c'etait lié au "pre-connect" et à une mauvaise >> > >>> >> > >> gestion >> > >> >> > >>> du buffer de reception côté client. >> > >>> >> > >>> Baptiste >> > >>> >> > >> >> > >> _______________________________________________ >> > >> Liste de diffusion du FRsAG >> > >> http://www.frsag.org/ >> > >> >> > > _______________________________________________ >> > > Liste de diffusion du FRsAG >> > > http://www.frsag.org/ >> > > >> > -------------- section suivante -------------- >> > Une pièce jointe HTML a été nettoyée... >> > URL: < >> http://www.frsag.org/pipermail/frsag/attachments/20150323/3a894fe7/attachment.html >> > >> > >> > ------------------------------ >> > >> > Subject: Pied de page des remises groupées >> > >> > _______________________________________________ >> > FRsAG mailing list FRsAG@frsag.org >> > http://www.frsag.org/mailman/listinfo/frsag >> > >> > ------------------------------ >> > >> > Fin de Lot FRsAG, Vol 183, Parution 1 >> > ************************************* >> >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ >> >> >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
