ASP.NET Web API, inaspettata fine di MIME multi-part flusso durante il caricamento da Flex FileReference

Question

Seguendo il tutorial trovato su ASP.NET, implementato un metodo di controllo Web API per fare upload di file asincrone che assomiglia a questo:

public Task<HttpResponseMessage> PostFormData() 
{ 
    // Check if the request contains multipart/form-data. 
    if (!Request.Content.IsMimeMultipartContent()) 
    { 
     throw new HttpResponseException(HttpStatusCode.UnsupportedMediaType); 
    } 

    string root = HttpContext.Current.Server.MapPath("~/App_Data"); 
    var provider = new MultipartFormDataStreamProvider(root); 

    // Read the form data and return an async task. 
    var task = Request.Content.ReadAsMultipartAsync(provider). 
     ContinueWith<HttpResponseMessage>(t => 
     { 
      if (t.IsFaulted || t.IsCanceled) 
      { 
       Request.CreateErrorResponse(HttpStatusCode.InternalServerError, t.Exception); 
      } 

      return Request.CreateResponse(HttpStatusCode.OK); 
     }); 

    return task; 
} 

Il caricamento di un file tramite un modulo HTML multipart standard funziona perfettamente. Tuttavia, quando un altro sviluppatore tenta di caricare un file con il modulo multipart costruito dalla classe FileReference di Flex, viene generato un errore:

imprevisto fine del flusso multipart MIME. Il messaggio multipart MIME non è completo.

Non ho idea se il problema si trova in Web API o Flex. Ho trovato una sorta di correzioni correlate che non hanno avuto alcun effetto (Multipart form POST using ASP.Net Web API) e più recentemente questa ("MIME multipart stream. MIME multipart message is not complete" error on webapi upload). Se il secondo link è vero, qualcuno sa se è disponibile nella versione corrente dell'API Web disponibile tramite Nuget? La discussione era a maggio, la versione più recente di Nuget era agosto, quindi presumo che questa soluzione sia già stata implementata, e non è la causa principale del mio problema.

Answer 1

Leggendo la ricerca esistente e seguendo il problema del codeplex segnalato, sembra che qualcun altro abbia confermato che questo problema esiste ancora a settembre.

Credono che MVC 4 non riesca a analizzare i caricamenti senza terminare "\ r \ n".

Il problema è molto semplice ma estremamente difficile da risolvere. Il problema è che Uploadify non> non aggiunge un "\ r \ n" alla fine del messaggio MultiPartForm

http://aspnetwebstack.codeplex.com/discussions/354215

E 'opportuno verificare che il caricamento Flex aggiunge il "\ r \ n "

Answer 2

Ho avuto lo stesso problema con il flex. E sotto c'è il codice che lo ha risolto. Fondamentalmente ho usato un flusso personalizzato per aggiungere la nuova riga che asp.net web api si aspetta.

 Stream reqStream = Request.Content.ReadAsStreamAsync().Result; 
     MemoryStream tempStream = new MemoryStream(); 
     reqStream.CopyTo(tempStream); 



     tempStream.Seek(0, SeekOrigin.End); 
     StreamWriter writer = new StreamWriter(tempStream); 
     writer.WriteLine(); 
     writer.Flush(); 
     tempStream.Position = 0; 


     StreamContent streamContent = new StreamContent(tempStream); 
     foreach(var header in Request.Content.Headers) 
     { 
      streamContent.Headers.Add(header.Key, header.Value); 
     } 

     // Read the form data and return an async task. 
     await streamContent.ReadAsMultipartAsync(provider); 

Spero che questo aiuti.

Answer 3

Ho avuto lo stesso problema con MVC4, ma Will è corretto, aggiungere un nome al vostro ingresso .....

<input type="file" id="fileInput" name="fileInput"/> 

e tutta la magia è tornato e funzionante!

Answer 4

Per coloro atterraggio qui googling:

imprevisto fine del flusso multipart MIME. Il messaggio multipart MIME non è completo.

La lettura del flusso di richiesta più di una volta causa anche questa eccezione. Ho lottato con esso per ore fino a quando ho trovato una fonte che spiegava che il flusso della richiesta poteva essere letto solo una volta.

Nel mio caso, ho combinato il tentativo di leggere lo stream della richiesta utilizzando un MultipartMemoryStreamProvider e allo stesso tempo lasciare che ASP.NET mi faccia un po 'di magia specificando i parametri (provenienti dal corpo della richiesta) per il mio metodo API.

Answer 5

Assicurarsi che la directory virtuale (directory "~/App_Data" come nell'esempio seguente) in cui i file di immagine vengono caricati per la prima volta siano fisicamente esistenti. Quando pubblichi il progetto, potrebbe non essere nei file di output.

string root = HttpContext.Current.Server.MapPath("~/App_Data"); 
var provider = new MultipartFormDataStreamProvider(root);