update 2 strong>: je suis convaincu que ceci est une ColdFusion CFHTTP punaise. Ceci est basé sur la réponse de Leigh et le fait que j'ai utilisé le code ci-dessous pour soumettre un formulaire avec seul em> l'élément de fichier à l'aide de JavaScript, et cela fonctionne bien: P> <cfset MyDir = "C:\test" />
<cfset MyFile = "test.zip" />
<cfif IsDefined("Form.TheFile")>
<cffile action="upload" fileField="theFile" destination="#MyDir#" nameConflict="MakeUnique" />
<cfelse>
<cfhttp url="http://#CGI.SERVER_NAME##CGI.SCRIPT_NAME#" method="POST" throwOnError="Yes">
<cfhttpparam type="file" name="theFile" file="#MyDir#\#MyFile#" />
</cfhttp>
</cfif>
<html><body>
<h2>Manual upload</h2>
<form enctype="multipart/form-data" action="<cfoutput>#CGI.PATH_INFO#</cfoutput>" method="POST">
<input name="theFile" type="file" /><br/>
<input type="submit" value="Submit" />
</form>
</body></html>
3 Réponses :
Peut-être que Railo 3.1.2 et Coldfusion 9 manipulent cela un peu différemment, mais votre code semble un peu incorrect pour moi.
Votre Lorsque le navigateur est suffisamment intelligent pour utiliser le chemin sans nom d'hôte, CFHTTP se sent mieux avec le nom de l'hôte complet + Nom de script +. Remarque: C'est pourquoi c'est pourquoi Une version bit modifiée du code fonctionne bien pour moi. Le fichier zip est téléchargé et publié sans être corrompu. P> formulaire: p> CFHTTP: p> cgi.path_info code> n'est pas applicable ici. p> cgi.script_name code> travaillé dans cf9, Railo requis cgi.server_name code> à être préparé, bien que je sente cela plus correct en général. P> <cfhttp url="#cgi.SERVER_NAME##cgi.SCRIPT_NAME#" method="POST" throwOnError="Yes">
<cfhttpparam type="file" name="theFile" file="#MyDir#/#MyFile#" />
</cfhttp>
Je vais l'essayer avec Railo. Mais lorsque j'ai testé le code d'origine, j'ai utilisé des chemins codés durs et des URL complètes et ont toujours les mêmes résultats corrompus. Selon Fiddler, la teneur brude de ACF CFHTTP contient un supplément de 2 octets (nouvelle ligne). Dès que vous ajoutez un champ factice après le fichier, les octets supplémentaires dans le contenu brut disparaissent.
Désolé, c'était une erreur de ma part pendant l'anonymisation. Dans mon script local, j'ai juste l'URL codé dur.
Toujours échoue avec # cgi.server_name ## cgi.script_name # . J'ai également essayé d'utiliser JavaScript pour soumettre un formulaire contenant uniquement l'élément de fichier et cela fonctionne simplement bien (voir mon édition). Donc je suis sûr que c'est un bug dans cfhttp.
ou y a-t-il quelque chose dans la spécification HTTP qui dit que les formulaires doivent contenir au moins un champ de formulaire non-fichier? P>
Je ne sais pas pour certains. Mais selon Ces définitions semble être Un post contenant uniquement une entrée de fichier doit être valide. Je soupçonne donc que le problème peut être CFHTP dans ACF. p>
selon Fiddler Le contenu brut de l'appel CFHTTP dans ACF contient un Nouvelle ligne supplémentaire juste avant la limite de fin (0D 0A en vue hexagonale). Mais sous Railo, ça ne le fait pas. Donc, je pense que le CFHTTP d'ACF pourrait être le coupable. P>
code d'échantillon: strong> p>
xxx pré> Résultats Railo 3.1.2 strong> p>
POST /cfusion/receive.cfm HTTP/1.1 Host: 127.0.0.1:8888 ... other headers removed for brevity .... Content-type: multipart/form-data; boundary=-----------------------------7d0d117230764 Content-length: 350 -------------------------------7d0d117230764 Content-Disposition: form-data; name="JobFile"; filename="c:\test\testFile.zip" Content-Type: application/octet-stream PK &�1=�cN'testFile.txtTestingPK &�1=�cN' testFile.txtPK:1 -------------------------------7d0d117230764--
@Kip - D'accord, bon. J'allais poser des questions à ce sujet. Je me souviens de voir cette question il y a environ 2 ans et je suis arrivé aussi loin que des 2 octets supplémentaires sont ajoutés à tous les fichiers. Mais ne s'est jamais levé pour comprendre pourquoi. Donc, merci de m'avoir poussé à résoudre le mystère nagging;)
@Kip - BTW: Quel est le numéro de bogue? Je n'ai rien vu dans la bogue public dB.
@Leigh où est le bogue public dB? J'ai trouvé cette page: Adobe.com/cfusion/mmform/index.cfm ? Nom = WishForm et je viens de recevoir un message qui disait quelque chose à l'effet de "Merci d'avoir soumis votre bogue. Nous apprécions vos commentaires, mais nous ne pouvons pas répondre à chaque demande envoyée."
@Kip - La base de données de bugs publics est ici CFBUGS.ADOBE.COM/CFBUGREPORT/FLEXBUNI /cfbugtracker/main.htm l . Vous voudrez peut-être l'énumérer sous CF9.0, car c'est toujours un problème dans cette version.
@LEigh: merci, je l'ai informé là aussi: Cfbugs .Adobe.com / CFBUGReport / Flexbugui / CFBUNTRACTER / ...
FYI, je viens de courir dans un autre bug similaire. Si vous utilisez la solution de contournement (incluez un champ de formulaire factice) et que le fichier est vide (0 octets), vous obtenez une exception de 500 serveur interne. Mais sans le champ factice, cela fonctionne (mais ajoute encore une nouvelle ligne supplémentaire).
Semble travailler pour moi avec CF9. Peut-être que celui-ci est spécifique CF8?
Pouvez-vous s'il vous plaît poster un exemple plus spécifique de votre travail autour? Cela m'a coupé!
Je ne me souviens pas des détails. L'ancien rapport de bogue a probablement eu un exemple, mais malheureusement, Adobe a cassé les anciens liens de bogues lors de la mise à niveau de la base de données de bogues. Cependant, je pense que l'OP vient d'ajouter un faux champ de formulaire, c'est-à-dire
Je reçois la ligne supplémentaire de la ligne et le retour de chariot sur le fichier ajoute également. Le problème pour moi est / était la combinaison de CFHTPTP et de la CFLOOOOP. Une fois que j'ai cassé la création de fichier en 3 parties: Créez, CFLoop Endrow-1, puis Ajout en dernier enregistrement.
semble être une façon kilomique de le faire, mais pas d'alimentation en ligne supplémentaire.
Je me souviens de ce problème. Je ne suis pas sûr des spécifications, mais mon devinez à l'époque était la question de la CFHTPTP. Espérons que quelqu'un d'autre a une réponse plus définitive ..
Je suppose que ceci est un navigateur ou un problème http, pas un problème avec cf. Il y avait un problème similaire dans IE sur Mac Classic (oui, cela a été un moment) qui appendraient des lignes neuves à une forme multipart / mime. Je suppose que c'est un problème similaire et moins intrusif. L'action de téléchargement n'est qu'une copie de fichier de la poignée de fichier fournie par le serveur Web (IIS, Apache, etc.).
Votre suggestion aurait plus de sens. Mais je me penche toujours vers la question de CFHTPTP. Je viens de l'essayer avec la version du développeur (serveur Web intégré) et obtenu les mêmes résultats de fichiers corrompus avec IE et FF.
Oui, je suis plutôt sûr que c'est un bogue CFHTPTP. En pensant à cela, CFHTP est ce qui construit le contenu de la demande. Donc, CFHTTP est responsable de l'ajout de nouvelles lignes entre les marqueurs de frontières. Dans ce cas, un trop nombreux ..
Ce problème de base se produit dans ACF au dernier champ de formulaire de l'appel de la CFHTPP, quel que soit son champ de formulaire. Le champ de texte final aura un nouveau caractère de ligne ajouté. Cela ne se produit pas s'il n'y a pas de champ de fichier.