2010-04-19 19 views
5

He estado usando Uploadify en mi aplicación PHP durante los últimos meses, y he estado tratando de rastrear un error difícil de alcanzar. Recibo correos electrónicos cuando ocurren errores fatales, y me proporcionan una buena cantidad de detalles. He recibido docenas de ellos. Sin embargo, no he podido reproducir el problema yo mismo. Algunos usuarios (como yo) no experimentan ningún problema, mientras que otros sí lo hacen.¿Por qué faltarían algunos datos POST al usar Uploadify?

Antes de dar detalles del problema, aquí está el flujo.

  • Visitas de usuario pantalla de edición de una página en el CMS que estoy usando.
  • La identificación del registro para la página se coloca en un formulario como un valor oculto.
  • El usuario hace clic en el botón de búsqueda Uploadify y selecciona un archivo (solo se permite la selección de un solo archivo).
  • El usuario hace clic en el botón Enviar de mi formulario.
  • jQuery intercepta la acción de envío de formularios, activa Uploadify para comenzar a cargar y devuelve false para la acción de envío (cancela manualmente el evento de envío de formularios para que Uploadify pueda hacerse cargo).
  • Uploadify sube a un script de proceso personalizado.
  • Uploadify termina de cargar y desencadena la devolución de llamada de compleción de Javascript.
  • La devolución de llamada de Javascript llama $ ('# myForm'). Submit() para enviar el formulario.

Ahora eso es lo que DEBERÍA suceder. Recibí informes de la congelación de la carga al 100% y también otros en los que se muestra "Error de E/S".

Lo que está sucediendo es que el formulario se envía con la devolución de llamada de finalización, pero algunos parámetros de publicación presentes en el formulario simplemente no están en los datos de la publicación. La identificación para la página, que antes dije que se agrega al formulario como un campo oculto, simplemente no está allí en los datos de la publicación ($ _POST) - no hay ningún elemento para 'id' en la matriz $ _POST. Lo extraño es que los datos de la publicación contienen valores para algunos campos. Por ejemplo, tengo una entrada de tipo texto llamada "nombre" que es para el nombre del registro, y aparece en los datos de la publicación.

Aquí es lo que he reunido:

  • Esto ha estado sucediendo en Mac OS X 10.5 y 10.6, Windows XP y Windows 7. Me pueden enviar cadenas exactas de agente de usuario si eso ayuda.
  • Los usuarios deben usar Flash 10.0.12 o posterior. Lo hemos hecho para que el formulario vuelva a usar un campo de "archivo" normal si tienen < 10.0.12.

¿Alguien tiene CUALQUIER idea de cuál podría ser la causa?

+0

+1 porque he tenido los mismos problemas con Uploadify. Los clientes informan de errores, particularmente cuando las cargas de imágenes devuelven errores de E/S o congelamiento. No se puede reproducir el error en el desarrollo, definitivamente no relacionado con el tamaño del archivo/conexión. – Jeriko

Respuesta

3
IOError: Client read error (Timeout?) 

Tengo el mismo error mucho, aunque mi lado del servidor es python/django. Supuse que era el cliente el tiempo de espera, pero mirando hacia atrás los registros para usted ahora parece ser una coincidencia de este cese cuando cambié algo en las rutinas de autenticación. ¿Es posible que el servidor esté recibiendo el archivo pero luego se niega a escribirlo en el almacenamiento?

Además, sabe que varios clientes de flash no envían cookies? Debe solucionarlo inyectando las claves de sesión en la variable 'scriptData' de uploadify.

x --------------------------------

Editar. Este código python/django comienza la rutina a la que se envía uploadify:

# Adobe Flash doesn't always send the cookies, esp. from Apple Mac's. 
# So we've told flash to send the session keys via POST. So recreate the 
# session now. Also facilitates testing via curl. 
cookie_name = settings.SESSION_COOKIE_NAME 
if request.member.is_anonymous() and request.POST.has_key(cookie_name): 

     # Convert posted session keys into a session and fetch session 
     request.COOKIES[cookie_name] = request.POST[cookie_name] 
     SessionMiddleware().process_request(request) 

# boot anyone who is still anonymous 
if request.member.is_anonymous(): 
    response['message'] = "Your session is invalid. Please login." 
    return HttpResponse(simplejson.dumps(response), mimetype='application/json') 
+0

Sí, estamos inyectando valores necesarios a través de scriptData. Tal vez deberíamos intentar enviar la identificación de la sesión también. No estoy seguro acerca de no escribir. Algo que necesito verificar –

+0

A menos que sus clientes sean homogéneos, debe enviar las claves de sesión a través de scriptdata; no puede confiar en Flash para enviar cookies. Muchas combinaciones no funcionan. No recuerdo específicamente, pero era como flash en Mac + FF que enviaba cookies pero flash en Mac + Safari no, o viceversa. Del mismo modo, Windows tiene combinaciones que flash no enviarán cookies. –

+0

Básicamente lo que estamos haciendo es enviar parámetros como "user_id: 1234, blah: 'something'". Y luego, el script de carga los está recibiendo, y estamos configurando valores manualmente para $ _COOKIE, así: $ _COOKIE ['user_id'] = $ _POST ['user_id']. Esto ha funcionado hasta ahora ... ¿quizás esto no funcionaría todo el tiempo? –

0

Uploadify puede modificar el formulario. Eche un vistazo al árbol html/DOM del formulario en el momento en que uploadify ha terminado y llama a su devolución de llamada.

0

¿Ha intentado usar Live HTTP Headers en Firefox para ver si hay algún tipo de reescritura que está causando que se pierdan los datos de la publicación?

Cuestiones relacionadas