2008-10-27 6 views
0

J'essaye de télécharger des fichiers en utilisant la classe FileReference. Les fichiers> 2MB fonctionnent tous correctement mais les fichiers < 2MB provoquent cette erreur: "java.io.IOException: Données de formulaire corrompues: fin prématurée"Données de formulaire corrompues: fin prématurée (Résolu)

Sur le serveur j'utilise le package com.oreilly.servlet pour gérer la demande.

J'ai utilisé ce paquet plusieurs fois pour gérer avec succès les téléchargements de fichiers de flex, mais pour une raison quelconque, maintenant j'ai ce problème.

Des idées?

Voici la trace de la pile pour un peu plus d'informations:

java.io.IOException: Corrupt form data: premature ending 
    at com.oreilly.servlet.multipart.MultipartParser.<init>(MultipartParser.java:205) 
    at com.oreilly.servlet.MultipartRequest.<init>(MultipartRequest.java:222) 
    at com.oreilly.servlet.MultipartRequest.<init>(MultipartRequest.java:173) 
    at com.mydomain.FileUploadServlet.doPost(FileUploadServlet.java:46) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) 
    at org.apache.struts2.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:99) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) 
    at org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:414) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) 

Mise à jour:

Il semble qu'il y ait un bug qui existe lors de l'utilisation com.orielly.servlet.MultipartRequest class et le filtre org.apache.struts2.dispatcher.ActionContextCleanUp ensemble. C'est ce qui provoquait l'échec des petits téléchargements de fichiers.

+3

Si vous avez trouvé une réponse à votre propre question, vous devriez poster la réponse comme une réponse et l'accepter, plutôt que de changer le titre. – SingleNegationElimination

Répondre

0

Il semble qu'il existe un bogue lors de l'utilisation conjointe de la classe com.orielly.servlet.MultipartRequest et du filtre org.apache.struts2.dispatcher.ActionContextCleanUp. C'est ce qui provoquait l'échec des petits téléchargements de fichiers.

+0

Comment avez-vous résolu le problème? – user2930137

0

http://www.servlets.com/cos/faq.html

Pourquoi lors de l'utilisation com.oreilly.servlet.MultipartRequest ou MultipartParser ne gros téléchargements échouent? Les classes elles-mêmes ont été spécialement conçues pour ne pas avoir de limite de taille maximale (contrairement à la plupart des autres utilitaires de téléchargement de fichiers), mais pour la protection de votre serveur, le constructeur vous permet de définir une taille maximale. Tout téléchargement supérieur à la limite est arrêté. Le maximum par défaut est 1 Meg. Pour une discussion des difficultés qu'un serveur a notifier un client de l'erreur, voir la discussion dans Java Servlet Programming, 2ème édition, page 119.

Alors, avez-vous spécifié la taille maximale du POST à ​​accepter?

P.S. Ok, maintenant je vois que c'est de petits téléchargements qui causent le problème. Sur le lien FAQ ci-dessus, il y a une section dédiée au dépannage des téléchargements, y compris quelques méthodes utiles pour isoler la cause (client, navigateur, serveur web, bibliothèques). Essayez les.

Installez un plugin Firefox (Tamper Data ou Firebug) qui affiche la requête envoyée au serveur. Peut vous aider à comprendre si quelque chose est différent entre < 2M et> 2M téléchargements.

P.P.S. Les fichiers de la même structure sont-ils? Se pourrait-il que les plus petits aient des données différentes (par exemple des symboles spéciaux) qui cassent la bibliothèque de Flash? Essayez de télécharger de petits fichiers d'espaces uniquement, par exemple.

0

@Vladimir:

J'ai utilisé un sniffer http pour vérifier la demande de poste et il envoie le fichier entier et le format de demande de poste est correcte. J'ai essayé beaucoup de différents dossiers (.jpg, .mp3 etc.) qui sont < 2MB et aucun ne fonctionnent.

La taille de la taille maximale est de 1,5 Go.

Voici ce que la demande de poste est:

------------cH2ae0ei4ae0cH2ae0Ef1KM7gL6GI3 
Content-Disposition: form-data; name="Filename" 

IMG0001.jpg 
------------cH2ae0ei4ae0cH2ae0Ef1KM7gL6GI3 
Content-Disposition: form-data; name="Filedata"; filename="IMG0001.jpg" 
Content-Type: application/octet-stream 

<file data here> 
------------cH2ae0ei4ae0cH2ae0Ef1KM7gL6GI3 
Content-Disposition: form-data; name="Upload" 

Submit Query 
------------cH2ae0ei4ae0cH2ae0Ef1KM7gL6GI3-- 

Je confirme que cela est un problème côté serveur comme je l'ai testé le servlet avec un formulaire HTML régulier et j'obtenir les mêmes résultats.

D'autres idées?

0

La raison en est que la demande a été envoyée avec un en-tête "Encodage de transfert: en bloc" au lieu d'un en-tête Content-length. Beaucoup de serveurs ne comprennent pas le contenu fragmenté, et ni O'Reilly. Vérifiez avec un renifleur si votre demande a été envoyée avec l'en-tête de codage de transfert. Je ne connais aucune solution pour cela.

Questions connexes