OVH Community, votre nouvel espace communautaire.

Input fichier image : type non reconnu !!!


fred036
14/01/2007, 18h07
non sorry, c mon habitude d'etre sur dédié...

euh pour un mutualisé, je sais pas ou sont les logs

les droits sont dans ton ftp.. n'importe quel ordi tombera donc sur un dossier ayant les memes droits, ca ne change pas d'un ordi à un autre...

Paul Sellis
14/01/2007, 18h05
ca ne sert à rien de vérifier que tu as le droit d'écrire puisque ca marche parfois, tu l'as
Oui c'est vrai, mais c'est comme si certains navigateurs n'avaient pas le droit…

il faut chmoder en 777 au cas ou
OK mais quoi (je ne vois pas de répertoire tmp…) ?

/var/log/
Tu veux dire :
http://www.mon_domaine.com/var/log/
Je ne vois rien de tout ça chez moi

fred036
14/01/2007, 17h48
ca ne sert à rien de vérifier que tu as le droit d'écrire puisque ca marche parfois, tu l'as

il faut chmoder en 777 au cas ou




/var/log/

Homer Jay
14/01/2007, 17h48
Citation Envoyé par Paul Sellis
Alors là je je sais pas comment faire pour vérifier tout ça.
- quel est ce code utilisateur ayant le droit d'écrire dans tmp ?
- répertoire tmp que je n'ai pas su voir par FTP…*Où est-il ?
- où sont les logs du serveur ?
Comme l'upload marche avec certains clients, ce n'est probablement pas un problème de droits d'écriture.

Par contre les logs pourraient avoir un intérêt... peut-être. Ils sont dans http://logs.ovh.net/domaine/osl/ (remplace avec ton nom de domaine) avec un retard de quelques minutes en général.

Paul Sellis
14/01/2007, 17h41
Sur un Newsgroup où j'ai posé la question j'ai eu une réponse pas mal de P'tit Marcel
Ce qui est significatif n'est pas le type du fichier mais sa taille annoncée de 0. Cela signifie que le serveur Web n'a pas su télécharger le fichier. Le type Octet/Stream doit être la valeur par défaut qui n'a pas été changée puisque le fichier est vide.
Ça me semble une très bonne déduction ça. effectivement le point important c'est que le serveur Web n'a pas su télécharger le fichier…

Vérifie que le code utilisateur avec lequel tourne le serveur web a le droit d'écrire dans le répertoire tmp et que celui-ci existe. Regarde ce qui se trouve dans la log du serveur Web.
Alors là je je sais pas comment faire pour vérifier tout ça.
- quel est ce code utilisateur ayant le droit d'écrire dans tmp ?
- répertoire tmp que je n'ai pas su voir par FTP…*Où est-il ?
- où sont les logs du serveur ?

Merci pour votre aide

Paul Sellis
14/01/2007, 13h52
Oui j'ai bien les dernières versions de Mac OS, de Safari, de FireFox et peut-être même de Camino.
Et en tous cas avec la dernière version de l'OS et de FireFox : j'ai le problème…
C'est bien pour ça que je me demande ce qui provoque cette erreur…

fred036
14/01/2007, 10h46
t'en X.4.8 ?

quels versions de softs ? tu mets à jour ? (perso, oui et ca marche comme déj dit)

Paul Sellis
13/01/2007, 22h20
Citation Envoyé par Homer Jay
un moyen de contourner le problème serait sans doute de demander à tes utilisateurs de ne pas utiliser de fichier dont le nom contient des caractères non-ASCII, mais ça ne t'est peut-être pas possible
Effectivement j'aimerais éviter au maximum

Mais qu'est-ce qui peut faire que MA config donne une image uploadée vide avec Camino et Firefox ?

Homer Jay
13/01/2007, 22h05
Citation Envoyé par Paul Sellis
Au final, il semble donc que ça soit MES Camino et FireFox qui fassent échouer l'upload du fichier C'est ce que j'essaie de comprendre…

Mais je n'ai peut-être pas compris ta réponse, non ?…
Ha oui tu as raison... je n'avais pas remarqué que l'image uploadée se retrouvait vide avec Camino et Firefox. Une fois arrivé là, ça risque d'être difficile de récupérer quoi que ce soit d'utile. Du coup, je manque d'idées pour résoudre ce problème (un moyen de contourner le problème serait sans doute de demander à tes utilisateurs de ne pas utiliser de fichier dont le nom contient des caractères non-ASCII, mais ça ne t'est peut-être pas possible).

Paul Sellis
13/01/2007, 21h24
Merci pour ta réponse. Même si je ne suis pas sûr de bien la comprendre.

En fait j'essaie de remonter la piste pour trouver l'origine du problème…
Dans mon script j'utilise simplement ImageMagick pour le resize avec convert :
Code PHP:
$output = `/usr/bin/convert -geometry $newLargeWidth x $newLargeHeight -quality 85 $tmpfile $Large_pict_file`; 
Mais avant, de redimensionner, je cherche si la photo est horizontale ou verticale.
Code PHP:
list($width$height) = getimagesize($tmpfile);
$imgratio=$width/$height
Et c'est là que je me rends compte de l'erreur :
Warning: getimagesize() [function.getimagesize]: Read error! in /home.2/…/www/upload.php on line 27
Warning: Division by zero in /home.2/…/www/upload.php on line 28
En remontant le fil avec un print_r() je me rens compte qu'avec ma config (Mac+Camino ou FireFox) l'upload de ce fichier ne se passe pas bien. Alors qu'avec d'autres PC ou Mac il ne semble pas y avoir de problème :
-- Sur Safari :
Array ( [name] => éàç.gif [type] => image/gif [tmp_name] => /tmp/phpS6Adra [error] => 0 [size] => 1351 )
-- Sur Camino :
Array ( [name] => éàç.gif [type] => application/octet-stream [tmp_name] => /tmp/phpMdH7iN [error] => 0 [size] => 0 )

Sur Camino en renommant le fichier différemment ça passe…
Au final, il semble donc que ça soit MES Camino et FireFox qui fassent échouer l'upload du fichier C'est ce que j'essaie de comprendre…

Mais je n'ai peut-être pas compris ta réponse, non ?…

Homer Jay
13/01/2007, 19h34
Citation Envoyé par Paul Sellis
- Sur Mac avec Camino (même chose sur Mac avec FireFox) :
Array ( [name] => éàç.jpg [type] => application/octet-stream [tmp_name] => /tmp/phpWmCUls [error] => 0 [size] => 0 )
Est-ce que tu ne pourrais pas simplement utiliser ImageMagick ou la commande «file» ou autre pour trouver le bon type MIME de l'image, plutôt que de te fier à ce que le client envoie?

Paul Sellis
13/01/2007, 19h09
Bon, ça se resserre autour de ma config :
j'ai eu un autre Mac entre les mains aujourd'hui et j'ai réussi à uploader mon fichier éàç.jpg avec Camino (pas la même version que la mienne) et aussi avec FireFox (même version que la mienne)…

Qu'est-ce qui peut provoquer ça ?

Merci
Paul

Paul Sellis
13/01/2007, 00h17
Bonjour,

cet après-midi fred036 m'a bien aidé à affiner mon problème "HELP - Warning: getimagesize()"
Merci à lui

Et comme le sujet s'est un peu décalé, je poste un nouveau sujet pour éviter toute l'enfilade de déductions.


Il en ressort que j'ai un problème d'input de fichier image avec certains navigateurs et certains noms de fichiers :
le type du fichier temporaire n'est pas reconnu…


Un print_r($submitfiles); me donne :

- Sur Mac avec Camino (même chose sur Mac avec FireFox) :
Array ( [name] => éàç.jpg [type] => application/octet-stream [tmp_name] => /tmp/phpWmCUls [error] => 0 [size] => 0 )

- Sur Mac avec Safari ou IE (même chose sur PC avec IE):
Array ( [name] => éàç.jpg [type] => image/jpeg [tmp_name] => /tmp/phpBP4F4C [error] => 0 [size] => 455905 )



Donc un même fichier image portant comme nom éàç.jpg plante sur 1 ordinateur (un Mac) avec les navigateurs Camino et FireFox (MAIS aucun souci avec Safari et la vieille version de IE !!!). Sur PC avec la dernière version de IE : c'est OK.
- un autre fichier image valide renommé éàç.jpg plante dans exactement les mêmes conditions.

C'est donc indépendant du contenu du fichier et directement lié au nom du fichier.
C'est le fichier temporaire créé qui pose problème, pas le nom du fichier (dont les accents et espaces sont par ailleurs enlevés après).

Le problème n'est pas dans le code d'upload du fichier (je viens d'essayer avec un autre code) ni dans celui du traitement de l'image (les données du fichier temporaire ne sont déjà pas reçues avant qu'il intervienne).
A priori cela ne proviendrait pas non plus du serveur (je viens de l'essayer sur un autre hébergement OVH mutualisé).



Comment s'en sortir ?
C'est un bug connu ?