Problème téléchargement via CGI avec IE

Le
Us
Bonjour à tous,

J'ai un problème de comportement de IE6 avec un script CGI de
téléchargement de fichier.

J'appelle (url fictif) :
http://www.monsite.fr/cgi-bin/download.cgi?id=test.zip

Ca marche avec Firefox, mais pas avec IE6 qui ouvre bien la boîte de
téléchargement, puis dit qu'il cherche les info fichier et fini par une
erreur disant qu'il ne peut pas télécharger "download.cgi?id=test.zip à
www", une seconde plus tard.

En cherchant via Google, il semble que ce type d'erreur soit répandu
avec IE, mais je ne vois pas de solution claire.

On m'a déjà dit que c'était un problème d'entête HTTP, mais ce que je
passe marche avec les autres navigateurs, est utilisé dans d'autre
script vus.

Voici l'entête reçu par IE :
(Status-Line) HTTP/1.0 200 OK
Connection close
Content-Disposition attachment; filename="test.zip"
Content-Encoding gzip
Content-Transfer-Encoding binary
Content-Type application/x-download
Date Sat, 17 Nov 2007 09:59:37 GMT
Expires 0
Pragma public
Server Apache/2.2.3
Vary Accept-Encoding
Via 1.0 GATEDSK:800 (squid/2.6.STABLE13)
X-Cache MISS from GATE-DESK

Mon script est écrit en Perl (déjà allé sur un newsgroup Perl qui me dit
que ce n'est pas un problème Perl). Le site est sous Apache/FreeBSD/Perl
5.8.

Bref, qué passa ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Us
Le #11105051
In article says...
J'ai un problème de comportement de IE6 avec un script CGI de
téléchargement de fichier.

J'appelle (url fictif) :
http://www.monsite.fr/cgi-bin/download.cgi?id=test.zip

Ca marche avec Firefox, mais pas avec IE6 qui ouvre bien la boîte de
téléchargement, puis dit qu'il cherche les info fichier et fini par une
erreur disant qu'il ne peut pas télécharger "download.cgi?id=test.zip à
www...", une seconde plus tard.




Apparemment, en décochant la cxase "ne pas enregistrer les pages
cryptées" dans la config IE6, ça marche.

Cette astuce seravant à contourner un bug IE6 récent tel que décrit ici
: http://support.microsoft.com/default.aspx?scid=kb;en-us;812935

Bon, deux choses :

1) le problème est que dans mon cas, ce n'est pas un accès HTTPS ni ne
concerne du PDF/DOC (mais le téléchargement de .zip ou .rar), almors je
ne sais pas pourquoi la "solution" de cet article MS fait que ça marche
finalement, mais bah.

2) Par contre, c'est très embêtant car que faire si mes visiteurs ont
justement cette case cochée ??? Modifier mon script Perl pour ne pas
tomber dans cette situation , Comment ? Là est tout mon problème !

Avez-vous des idées ?
William Marie
Le #11105031
"Us"

Bon, deux choses :

1) le problème est que dans mon cas, ce n'est pas un accès HTTPS ni ne
concerne du PDF/DOC (mais le téléchargement de .zip ou .rar), almors
je ne sais pas pourquoi la "solution" de cet article MS fait que ça
marche finalement, mais bah.

2) Par contre, c'est très embêtant car que faire si mes visiteurs ont
justement cette case cochée ??? Modifier mon script Perl pour ne pas
tomber dans cette situation , Comment ? Là est tout mon problème !

Avez-vous des idées ?



1. "ne pas enregistrer les pages cryptées" est l'option par défaut. Sinon
indiquer explicitement qu'ils doivent la décocher (s'ils savent la cocher il
sauront aussi la décocher)

2. Qu'est-ce que ça donne avec IE7 ? Parce que IE6 est passé, avec
soulagement, aux oubliettes.

3. Même question avec Opera (l'histoire d'avoir le comportement de tous les
navigateurs usuels sous Windows)
--
=================================== William Marie
Attention antiSpam remplacer trapellun.invalid
par free.fr
Web : http://wmarie.free.fr
http://www.pandemonium.dnsalias.org (site expérimental)
====================================
Us
Le #11104981
In article says...
1. "ne pas enregistrer les pages cryptées" est l'option par défaut. Sinon
indiquer explicitement qu'ils doivent la décocher (s'ils savent la cocher il
sauront aussi la décocher)




La plupart des gens cliquent et ne lisent pas... Je continue à chercher
: il faut que je trouve un truc automatique, car laisser un bug comme ça
ds IE6, c'est tout de même énorme.

2. Qu'est-ce que ça donne avec IE7 ? Parce que IE6 est passé, avec
soulagement, aux oubliettes.



Il faut que tu saches que dans l'industrie, Windows 200 est encore le
plus répandu, car le plus stable et le plus rapide (car pas d'interface
surchargée de gadgets). Aussi, MS a eu la stypîde idée d'interdire
l'install d'IE7 sous Win2K => IE6 reste d'intense actualité !

Par ailleurs, quasiment personne de notre public (pro) n'utilise XP :
Linux (Fedora, Ubuntu, Debian surtout), Win2003 et 2000, oui, mais pas
XP.

Sinon, pas encore essayé sous IE7, car les seuls postes ici sous XP sont
au service commercial : il faudra que j'y aille ou installe un XP rapide
sous VMWare.

3. Même question avec Opera (l'histoire d'avoir le comportement de tous les
navigateurs usuels sous Windows)




C'est OK sous Opera, Mozilla, Firefox, Netscape, mais pas IE6 avec cette
case "ne pas enregistrée les pages cryptées" cochée.

Tout de même étrange, sachant qu'il ne s'agit pas de page cryptée ! Quel
temps on peut perdre avec des conneries : un pb comme ça devrait être
réglé côté MS, m....

[en colère, car je perd du temps sur mes délais - je ne m'amuse pas,
mais travaille]
Sergio
Le #11104961
Us a écrit :

Par ailleurs, quasiment personne de notre public (pro) n'utilise XP :
Linux (Fedora, Ubuntu, Debian surtout), Win2003 et 2000, oui, mais pas
XP.



Win 2003 étant un Windows XP serveur, donc pas de problèmes... IE7
fonctionne.

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Us
Le #11104951
In article says...
C'est OK sous Opera, Mozilla, Firefox, Netscape, mais pas IE6 avec cette
case "ne pas enregistrée les pages cryptées" cochée.




Pas sûr que ce soit la solution qui tue, mais j'ai trouvé un entête HTTP
qui semble fonctionner malgré l'option "ne pas enregistrer les pages
cryptées" cochée dans IE6.

Content-Type: application/octet-stream
Content-Length: $size
Content-Disposition: attachment; filename=$file
Cache-Control: public
Pragma: public
Expires: 0


[peut-être résolu donc]
Pierre Goiffon
Le #11104861
Us wrote:
J'ai un problème de comportement de IE6 avec un script CGI de
téléchargement de fichier.

J'appelle (url fictif) :
http://www.monsite.fr/cgi-bin/download.cgi?id=test.zip

Ca marche avec Firefox, mais pas avec IE6 qui ouvre bien la boîte de
téléchargement, puis dit qu'il cherche les info fichier et fini par une
erreur disant qu'il ne peut pas télécharger "download.cgi?id=test.zip à
www...", une seconde plus tard.



Il est quasiment impossible de vous répondre avec si peu de
renseignements : on ne sait pas ce qu'envoie votre script ! Indiquez le
de manière précise, mettez en ligne un exemple permettant de reproduire
le prb, etc etc...
Us
Le #11104841
In article says...
Us wrote:
> J'ai un problème de comportement de IE6 avec un script CGI de
> téléchargement de fichier.
>
> J'appelle (url fictif) :
> http://www.monsite.fr/cgi-bin/download.cgi?id=test.zip
>
> Ca marche avec Firefox, mais pas avec IE6 qui ouvre bien la boîte de
> téléchargement, puis dit qu'il cherche les info fichier et fini par une
> erreur disant qu'il ne peut pas télécharger "download.cgi?id=test.zip à
> www...", une seconde plus tard.

Il est quasiment impossible de vous répondre avec si peu de
renseignements : on ne sait pas ce qu'envoie votre script ! Indiquez le
de manière précise, mettez en ligne un exemple permettant de reproduire
le prb, etc etc...




Bon, un moment, j'ai cru que c'était bon, mais non. Maintenant, ça
marche sous Apache/Windows via LAN, mais pas avec Apache/FreeBSD
distant.

Voici le code minimum pour test (oui, c'est non sécurisé, non filtré,
etc, je le sais, c'est un simple test pour tenter de le faire passer
avec IE6) :

#!/usr/bin/perl -w
# this code is an unsecure mini one only for internal test with IE6
use strict;
use CGI::Carp qw/fatalsToBrowser/;
my $loc = "../../../htdocs/repository/";
my $file = "test.zip";
my $size = -s $loc.$file;
print "Content-Disposition: attachment; filename=$filen";
print "Content-Type: application/octet-streamn";
print "Content-Length: $sizenn";
open FILE, "<$loc$file";
binmode FILE;
binmode STDOUT;
print while read FILE, $_, 1024;
close FILE;
exit 0;
Pierre Goiffon
Le #11104801
Us wrote:
J'ai un problème de comportement de IE6 avec un script CGI de
téléchargement de fichier.

J'appelle (url fictif) :
http://www.monsite.fr/cgi-bin/download.cgi?id=test.zip

Ca marche avec Firefox, mais pas avec IE6 qui ouvre bien la boîte de
téléchargement, puis dit qu'il cherche les info fichier et fini par une
erreur disant qu'il ne peut pas télécharger "download.cgi?id=test.zip à
www...", une seconde plus tard.





#!/usr/bin/perl -w
# this code is an unsecure mini one only for internal test with IE6
use strict;
use CGI::Carp qw/fatalsToBrowser/;
my $loc = "../../../htdocs/repository/";
my $file = "test.zip";
my $size = -s $loc.$file;
print "Content-Disposition: attachment; filename=$filen";
print "Content-Type: application/octet-streamn";
print "Content-Length: $sizenn";
open FILE, "<$loc$file";
binmode FILE;
binmode STDOUT;
print while read FILE, $_, 1024;
close FILE;
exit 0;



Ca semble assez correct (on omettra le content-type qui devrait être
correctement fixé)... Comment dirigez-vous vers ce script ? Par un
simple lien href ? Par une redirection ?
Us
Le #11104791
In article says...

Ca semble assez correct (on omettra le content-type qui devrait être
correctement fixé)... Comment dirigez-vous vers ce script ? Par un
simple lien href ? Par une redirection ?





Je fournis un lien href de type "http://www.mondomain.net/cgi-
bin/download.cgi?file=test.zip"

Enfin, je n'ai pas abouti, alors j'ai finalement fait autrement : Je
teste le HTTP_USER_AGENT et utilise un "Location:" si la chaine contient
"MSIE 6" ; j'ai moins de contrôle dans ce cas, mais ça marche (ce serait
plus dur par contre pour forcer le téléchargement d'une image plutôt que
son affichage)

Par contre, il me reste un problème mineur (car non bloquant) : parmi
les beta testeurs, une machine équipée d'IE7 me donne une chaine
HTTP_USER_AGENT avec "MSIE 6" plutôt que "MSIE 7". Comment est-ce
possible ? Je pensais qu'IE7 donnait tjrs "MSIE 7".
Pierre Goiffon
Le #11104781
Us wrote:
Ca semble assez correct (on omettra le content-type qui devrait être
correctement fixé)... Comment dirigez-vous vers ce script ? Par un
simple lien href ? Par une redirection ?



Je fournis un lien href de type "http://www.mondomain.net/cgi-
bin/download.cgi?file=test.zip"

Enfin, je n'ai pas abouti, alors j'ai finalement fait autrement : Je
teste le HTTP_USER_AGENT et utilise un "Location:" si la chaine contient
"MSIE 6"



Location ? Cad que votre script effectue une redirection vers le fichier
ciblé ? Ces fichiers sont donc accessibles ? Quel est donc l'intérêt du
script ?!??

Par contre, il me reste un problème mineur (car non bloquant) : parmi
les beta testeurs, une machine équipée d'IE7 me donne une chaine
HTTP_USER_AGENT avec "MSIE 6" plutôt que "MSIE 7". Comment est-ce
possible ? Je pensais qu'IE7 donnait tjrs "MSIE 7".



La chaine User_Agent est envoyée par le client, et peut donc contenir
absolument n'importe quoi ! L'usage est bien que la chaine contienne un
moyen d'identifier le navigateur, mais rien n'empêche d'envoyer "toto
est le plus beau" si on le souhaite.
Bref, ne pas se fier à user_agent, jamais au grand jamais !
Publicité
Poster une réponse
Anonyme