web-dev-qa-db-fra.com

API Web ASP.NET, fin inattendue du flux en plusieurs parties MIME lors du téléchargement depuis Flex FileReference

En suivant le didacticiel trouvé sur ASP.NET, implémenté une méthode de contrôleur d'API Web pour effectuer des téléchargements de fichiers asynchrones qui ressemble à ceci:

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;
}

Le téléchargement d'un fichier via un formulaire HTML standard en plusieurs parties fonctionne parfaitement. Cependant, lorsqu'un autre développeur tente de télécharger un fichier via un formulaire en plusieurs parties construit par la classe FileReference de Flex, une erreur est générée:

Fin inattendue du flux multipartie MIME. Le message multipartie MIME n'est pas terminé.

Je n'ai aucune idée si le problème réside dans l'API Web ou Flex. J'ai trouvé une sorte de correctifs connexes qui n'avaient aucun effet ( Formulaire en plusieurs parties POST utilisant l'API Web ASP.Net ), et plus récemment celui-ci ( Erreur "Flux MIME en plusieurs parties. Le message MIME en plusieurs parties n'est pas terminé" lors du téléchargement sur webapi ). Si le deuxième lien est vrai, quelqu'un sait-il s'il est disponible dans la version actuelle de l'API Web disponible via Nuget? La discussion était en Mai, la version la plus récente de Nuget était août, donc je suppose que ce correctif a déjà été déployé et n'est pas la cause première de mon problème.

asp.net-mvcapache-flexasp.net-web-api
25
heyseuss

En lisant vos recherches existantes et en suivant le problème du codeplex, vous avez l'impression que quelqu'un d'autre a confirmé que ce problème existait toujours en septembre.

Ils croient que MVC 4 ne parvient pas à analyser les téléchargements sans terminer "\ r\n".

Le problème est vraiment simple mais extrêmement difficile à résoudre. Le problème est que Uploadify n'ajoute pas de "\ r\n" à la fin du message MultiPartForm

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

Il peut être utile de vérifier que le téléchargement Flex ajoute le "\ r\n"

7
Mark Jones

J'ai eu le même problème avec le flex. Et ci-dessous est le code qui l'a résolu. Fondamentalement, j'ai utilisé un flux personnalisé pour ajouter la nouvelle ligne attendue par l'api web asp.net.

        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);

J'espère que cela t'aides.

35
Landuber Kassa

J'ai eu le même problème avec MVC4, mais Will est correct, ajoutez un nom à votre entrée .....

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

et toute la magie est de retour et fonctionne!

33
Greg Sipes

Pour ceux qui atterrissent ici sur Google:

Fin inattendue du flux multipartie MIME. Le message multipartie MIME n'est pas terminé.

La lecture du flux de demandes plusieurs fois entraînera également cette exception. Je me suis débattu avec pendant des heures jusqu'à ce que je trouve une source expliquant que le flux de demande ne pouvait être lu qu'une seule fois.

Dans mon cas, j'ai combiné essayer de lire le flux de demande en utilisant un MultipartMemoryStreamProvider et en même temps laisser ASP.NET faire de la magie pour moi en spécifiant les paramètres (provenant du corps de la demande) pour ma méthode api.

8
Niklas Källander

Assurez-vous que le répertoire virtuel (répertoire "~/App_Data" comme dans l'exemple ci-dessous) où les fichiers image sont téléchargés pour la première fois existe physiquement. Lorsque vous publiez le projet, il peut ne pas figurer dans les fichiers de sortie.

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

Je viens de supprimer mes en-têtes que je définissais sur ma méthode de publication, ce qui a fini par résoudre ce problème.

1
dk_french032

Le problème est cette ligne:

string root = HttpContext.Current.Server.MapPath("~/App_Data");

Cela ne fonctionnera que dans localhost, vous pouvez utiliser HostingEnvironment.MapPath à la place dans n'importe quel contexte où les objets System.Web comme HttpContext.Current ne sont pas disponibles (par exemple également à partir d'une méthode statique).

var mappedPath = System.Web.Hosting.HostingEnvironment.MapPath("~/SomePath");

Voir aussi Quelle est la différence entre Server.MapPath et HostingEnvironment.MapPath?

Référence à cette réponse Comment faire un chemin de mappage de serveur.

0
Luis Pardo