2011-06-26 18 views
6

Tengo muchas redirecciones dentro de un servidor web VM, que funcionan cuando navego por el servidor con el navegador incorporado (iceweasel). Pero eso no funciona cuando se accede al servidor desde los navegadores de la máquina de alojamiento (probado con FF4/IE8/Chrome/Opera11).redirección de php: encabezados HTML

Todos los métodos de redireccionamiento experimentados se dirigen a un "servidor no disponible o sobrecargado" en los navegadores de la máquina de host.

Si pudiera echar un vistazo a las cabeceras de los registros de Apache y dar algunos consejos acerca de las diferencias (uno principal parece ser la URL GET, siempre que el mismo código está funcionando):

Trabajo solicitud conduce a este registro:

cat /var/log/apache2/access.log | grep 127 | grep random | tail -n1 
127.0.0.1 - authuserid [26/Jun/2011:11:11:52 +0200]  
"GET /index.php?page=100 HTTP/1.1" 200 49151 
"https://www.mydomain.foo/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&random=c0117685e7e65a307989c219efc587b4&sid=n7en2it41h2gumrcq3kmmil3c0&sidf=.ps_AWDkIY" 
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19) Gecko/2011050718 Iceweasel/3.0.6 (Debian-3.0.6-3)" 

para no trabajar petición conduce a este registro:

cat /var/log/apache2/access.log | grep 192 | grep random | tail -n1 
www.mydomain.org:80 192.168.X.Y - authuserid [26/Jun/2011:11:08:07 +0200] 
"GET /index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&random=685de8bcd4d198d6ad7f3cf4b23de5b7 HTTP/1.1" 302 - 
"http://www.mydomain.foo/index.php?page=xyz"  
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1" 

No puedo mostrar la respuesta del encabezado porque no recibo una respuesta y no hay ningún error informado por apache (loglevel = error).

Thx

controles realizados:
que han aumentado el tiempo de espera de los navegadores (FF: network.http.keep-alive.timeout a 3600:. Ningún cambio
he comprobado que no hay cabeceras fueron enviados previamente a la redirección: bien (un vertedero de headers_sent() no muestra encabezados enviados ni línea en blanco o un espacio en el incluye,)
he aumentado el tiempo de espera del servidor Apache por si acaso: ningún cambio
me aseguré de usar una URL absoluta a partir de HTTP/1.1. Probé php, html meta y JS redirigir: ningún cambio

EDIT 1:

Aquí están las cabeceras como se ve por LiveHTTPHeaders en el caso de "no trabajo":


http://www.mydomain.org/menus/noeud4.php
POSTAL /menus/noeud4.php HTTP/1.1 Host
: www.mydomai n.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv: 2.0.1) Gecko/20100101 Firefox/4.0.1
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
Aceptar-Codificación: gzip, deflate
Aceptar-Caracteres: ISO-8859-15, utf-8; q = 0.7 , *; q = 0.7
mantenimiento de conexiones: 3600
DNT: 1
conexion: keep-alive
Referer: http://www.mydomain.org/index.php?page=890
Cookie: PHPSESSID = 4bge5gg1rgkit78k3seqlfcbq2
Autorización: == aW52aXRlZEBjYW1hY2FzYTp5b3VybXlndWVzdEB0b2RheQ básico
Content-Type: application/x- www-form-urlencoded
Content-Length: 98
login = my_superlogin1 & pwd1 = vbigpass3xqz% 40A2L & código de imagen = 91690 & fuente = noeud4.php &> formulaire_valide = soumettre
HTTP/1.1 302 Encontrado
Fecha: Sun 26 Jun 2,011 mil 14:17:27 GMT
Servidor: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_fastcgi/2.4 .6 mod_python/3.3.1 Python/2.5.2> mod_ssl/2.2.9 OpenSSL/0.9.8g PHP/5.3.3
X-Powered-By: PHP/5.3.3
Expira: jue, 19 nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, debe-revalidate, después de la comprobación = 0, pre-check = 0
Pragma: no-cache
Ubicación: http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788
Co ntent-Longitud: 0
mantenimiento de conexiones: timeout = 60
conexión: Keep-Alive
Content-Type: text/html


http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788
GET /index.php?page=100 & new_session = a4da9106dba2ffd40345a5eb624d7788 HTTP/1.1
Host: www.mydomain.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv: 2.0.1) Gecko/20100101 Firefox/4.0.1
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
Aceptar-Codificación: gzip, deflate
Aceptar-Caracteres: ISO-8859-15, utf-8; q = 0.7 , *; q = 0,7
Keep-Alive: 3600
DNT: 1
conexion: keep-alive
Referer: http://www.mydomain.org/index.php?page=890
Cookie: PHPSESSID =bge5gg1rgkit78k3seqlfcbq Autorización: == aW52aXRlZEBjYW1hY2FzYTp5b3VybXlndWVzdEB0b2RheQ básica

HTTP/1.1 302 Encontrado
Fecha: Sun 26 Jun 2 011 14:19:59 GMT
Servidor: Apache/2.2.9 (Debian) DAV/2 SVN/1.5 .1 mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2> mod_ssl/2.2.9 OpenSSL/0.9.8g PHP/5.3.3 X-Powered-By: PHP/5.3.3
Expira: Jue 19 Nov 1 981 08:52:00 GMT
Cache-Control: no-store, no-cache, debe-revalidate, post-check = 0, pre-check = 0
Pragma: no -cache
Ubicación: https://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&sid=4bge5gg1rgkit78k3seqlfcbq2&sidf=.ps_Z5wRio
Content-Length: 0
mantenimiento de conexiones: timeout = 60
conexión: Keep-Alive
Content-Type: text/html


Edit2: Comparando ambos casos de petición/respuesta (trabajo/no funciona), que aísla los siguientes 2 diferencias principales entre otros:

En las respuestas de "trabajo":
Estado: 200 cuales No tengo la respuesta de "no trabajo", pero no entiendo por qué.

en la respuesta "no laborables":
DNT: 1
que representa la opción Do Not Track (me) from FF4.
Así que traté de desactivar esta opción, pero el mismo resultado.

Me puedo perder algo seguro. Todo parece como si el servidor estuviera caído. Tal vez la cookie de sesión (76 kb) es demasiado grande. También probé la degradación de Firefox 4 a 3.6 ya que este otro parámetro cambió, pero aún obtengo la misma respuesta con FF3.6 como FF4.

+1

¿Puedes usar LiveHTTPHeaders (para Firefox) o algo similar para ver los encabezados? – Halcyon

+1

Parece un problema con los nombres de dominio/DNS/VHosting. ¿Tiene algún alias configurado en el archivo VM '/ etc/hosts' que necesita copiarse en el equipo host? ¿La máquina host proporciona servicios de DNS a la máquina virtual que necesita ser reemplazada cuando no está trabajando dentro de la máquina virtual? Si la solicitud del host utiliza un nombre de dominio diferente, ¿está utilizando VHosts de Apache basados ​​en nombre, esto podría significar que las solicitudes de la máquina host se enrutan a una configuración de VHost diferente? – Robin

+0

@Frits van Campen: Thx, eso es lo que estaba tratando de lograr usando firebug. Edité con los encabezados de "bloqueo". – hornetbzz

Respuesta

1

Como se puede ver en las solicitudes publicadas que intenta golpear: http://www.mydomain.org/menus/noeud4.php pero te redirige a http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788 y luego otra vez a https://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&sid=4bge5gg1rgkit78k3seqlfcbq2&sidf=.ps_Z5wRio

¿Mantiene el envío de 302 cabeceras?

Supongo que el script noeud4.php es un script de inicio de sesión que probablemente creará una sesión y probablemente establezca algunas cookies. Mi suposición sería verificar si eso se está haciendo correctamente, y descubrir por qué arroja el 302.

+0

buena suposición: el formulario page_890 publica datos en noeud4, que analiza los datos, inicia algunas cookies en el servidor. A continuación, page_890 redirige al formulario si no son datos compatibles o indexa si está bien. Luego, index.php obtiene cookies sidf y sidf para mantener la sesión para un siguiente paso cambiar a https si se cumplen todas las condiciones de inicio de sesión: si es así, el índice se redirige a sí mismo pero cambia a https. – hornetbzz

+0

@Frits, @bob, @robin: Thx chicos. No estoy seguro de lo que hice exactamente, pero parece que cambiar 2 bloques de código e iluminar la cookie de sesión resolvió el problema. Todo este código es demasiado delicado, ya que todavía hay algunos problemas. A continuación usaré un marco ... Acepto la respuesta, ya que esto me ayudó significativamente a encontrar el por qué. – hornetbzz

+0

Nota: También desactivé mod_expire y mod_deflate en Apache. – hornetbzz