.net - ultimate - La primera carga de MVC3 HttpPostedFileBase no proporciona datos, pero lo hace posteriormente
marvel vs capcom infinite (3)
Buena pregunta. La autenticación fue lo primero que me vino a la mente. Es normal obtener dos no autorizados y el tercero autorizado. Así es como funciona NTLM.
Si es necesario que funcione también en Chrome y no pueda esperar la solución, sugeriría habilitar la autenticación de formularios que redirige al mismo dominio pero en un puerto diferente, donde reside la aplicación de inicio de sesión con autenticación de Windows. Esta aplicación establece la cookie de formulario o no y te envía de vuelta a tu aplicación principal. El proceso está bien descrito aquí: http://msdn.microsoft.com/en-us/library/ms972958.aspx
De esta manera, su NTLM se realiza una vez y luego tiene una cookie, por lo que NTLM no se usa con su solicitud POST y todo debería funcionar como se esperaba.
Sólo pensé que iba a compartir este :)
Antecedentes del tema.
EDITAR 3 Puedo verificar que esto parece estar funcionando nuevamente en Chrome 20. ¡Gracias!
Actualización de TLDR
EDITAR 2 Después de un poco más de reflexión, parece ser un error en Chrome 19. Por favor, consulte aquí:
Nada como un error de última hora! :-)
Firefox-latest e IE8 / 9 funcionan como se espera. Los registros de Fiddler muestran el mismo comportamiento, con la gran diferencia de que la verificación de autorización del segundo 401 no envía la carga útil del formulario confusa y funciona como se esperaba.
¡Suena como un caso de prueba y una solución está en las obras! Así que, espero que para cualquiera de ustedes que haya encontrado esto, ¡esto ayude!
TLDR FINAL
Tengo una acción de controlador que admite únicamente un archivo cargado que es un archivo CSV de "eventos". Detrás de escena, este CSV se analiza, se convierte en objetos de evento y los datos se sincronizan en la base de datos. Como resultado, se le pide al usuario que descargue una hoja de cálculo de Excel que contiene todos los errores en cada línea que ocurrió.
Todo esto funciona bien localmente en mi máquina de desarrollo. Sin embargo, una vez implementado en el entorno DEV, estoy obteniendo resultados diferentes. El primer intento de cargar un archivo hace que la secuencia sea, ¿cuál es la palabra que estoy buscando aquí, ilegible? Informa correctamente su longitud, pero los intentos de extraer la información no obtienen nada. Las lecturas posteriores tienen los datos y todo funciona como se espera.
Te daré los códigos pertinentes. Primero, la forma HTML gen''d simplificada:
<form action="/Events/ImportLocal" enctype="multipart/form-data" method="post">
<input id="uploadFile" name="uploadFile" type="file" />
<input type="submit" value="Upload Events" />
</form>
Muy claro:
Acción del controlador (perdona el desorden, he estado pirateando esto durante un par de horas):
[HttpPost]
public ActionResult ImportLocal(HttpPostedFileBase uploadFile)
{
if (uploadFile == null || uploadFile.ContentLength <= 0)
{
BaseLogger.Info("uploadFile is null or content length is zero...");
//Error content returned to user
}
BaseLogger.InfoFormat("Community Import File Information: Content Length: {0}, Content Type: {1}, File Name: {2}",
uploadFile.ContentLength, uploadFile.ContentType, uploadFile.FileName);
//This logger line is always reporting as correct. Even on the attempts where I can''t pull out the stream data, I''m seeing valid values here.
//EXAMPLE output on failed attempts:
//Import File Information: Content Length: 315293, Content Type: application/vnd.ms-excel, File Name: Export_4-30-2012.csv
BaseLogger.InfoFormat("Upload File Input Stream Length: {0}", uploadFile.InputStream.Length);
//This is reporting the correct length on failed attempts as well
//I know the below is overly complicated and convoluted but I''m at a loss for why the inputstream in HttpPostedFileBase is not pulling out as expected
//so I''ve been testing
var target = new MemoryStream();
uploadFile.InputStream.CopyTo(target);
byte[] data = target.ToArray();
BaseLogger.InfoFormat("File stream resulting length = {0}", data.Length);
//This reports correctly. So far so good.
StringReader stringOut;
var stream = new MemoryStream(data) {Position = 0};
using (var reader = new StreamReader(stream))
{
string output = reader.ReadToEnd();
BaseLogger.InfoFormat("Byte[] converted to string = {0}", output);
//No go...output is reported to be empty at this point so no data ever gets sent on to the service call below
stringOut = new StringReader(output);
}
//Build up a collection of CommunityEvent objects from the CSV file
ImportActionResult<Event> importActionResults = _eventImportServices.Import(stringOut);
El objetivo es pasar un lector de texto o un lector de cadena al método de servicio, ya que detrás de la escena, se trata de una implementación de procesamiento CSV que desea estos tipos.
¿Alguna idea de por qué la primera solicitud falla pero el trabajo posterior? Siento que necesito un nuevo par de ojos mientras me estoy quedando sin ideas.
El último punto, IIS 7.5 es el objetivo tanto localmente a través de IIS Express como en el servidor de destino.
Gracias
EDITAR para la recompensa:
Estoy copiando mi mensaje de recompensa aquí y la salida de Fiddler para cada solicitud
He añadido algunos comentarios a esta pregunta. El problema aparece relacionado con NTLM. Lo que veo en Fiddler es un 401 no autorizado a solicitud 1 con datos de formulario válidos (punto, entiendo que estas primeras 401 solicitudes no autorizadas son "normales" en escenarios donde solo está activada la autenticación de Windows; ¿verifique por favor?). La solicitud 2 que aparece en la lista es nuevamente un 401 con los mismos datos de formulario, excepto que los datos del archivo cargado ahora son solo un montón de cuadros, el mismo tamaño de datos, pero no los datos cargados. La solicitud 3 es un 200 OK que contiene los datos confusos y esto es lo que está obteniendo la acción de mi controlador. ¿Cómo consigo NTLM para jugar bien con las cargas de archivos?
Aquí está la salida de Fiddler para cada solicitud:
Solicitud 1)
Solicitud 2)
Y finalmente solicitar 3 que es el procesado HTTP 200 OK.
EDITAR 2 Después de un poco más de reflexión, parece ser un error en Chrome 19. Por favor, consulte aquí:
Nada como un error de última hora! :-)
Firefox-latest e IE8 / 9 funcionan como se espera. Los registros de Fiddler muestran el mismo comportamiento, con la gran diferencia de que la verificación de autorización del segundo 401 no envía la carga útil del formulario confusa y funciona como se esperaba.
¡Suena como un caso de prueba y una solución está en las obras! Así que, espero que para cualquiera de ustedes que haya encontrado esto, ¡esto ayude!
Gracias
Creo que necesita verificar los permisos en la carpeta IIS / sitio web virtual en el que se cargan los archivos y direccionarse si están en lugares distintos.
Esto es solo una idea para intentarlo. Tenga en cuenta que StreamReader tiene muchos constructores:
http://msdn.microsoft.com/en-us/library/system.io.streamreader.aspx
En algunos de los constructores intenta detectar automáticamente la codificación (si está especificada) y si no puede detectarla, entonces vuelve a la especificada. El constructor utilizado utiliza codificación UTF-8. Podría cambiar el constructor para que detecte automáticamente la codificación y, en caso contrario, utilice UTF-8.