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.
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 ?
In article <MPG.21a8e601346a1d51989977@news.tiscali.fr>, us@invalid.org
says...
J'ai un problème de comportement de IE6 avec un script CGI de
téléchargement de fichier.
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 !
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
"Us" a écrit dans le message de news:
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" <us@invalid.org> a écrit dans le message de news:
MPG.21a9a5ec6c0e5b1298997a@news.tiscali.fr
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)
====================================
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
In article <473fedce$0$20125$, 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]
In article <473fedce$0$20125$426a74cc@news.free.fr>,
wmarie@trapellun.invalid 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]
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
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 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
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
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]
In article <MPG.21aa4f161a106ce098997b@news.tiscali.fr>, us@invalid.org
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
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
Us wrote:
J'ai un problème de comportement de IE6 avec un script CGI de téléchargement de fichier.
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 wrote:
J'ai un problème de comportement de IE6 avec un script CGI de
téléchargement de fichier.
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...
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
In article <474157f9$0$9203$, 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;
In article <474157f9$0$9203$426a34cc@news.free.fr>,
pgoiffon@free.fr.invalid 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;
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
Us wrote:
J'ai un problème de comportement de IE6 avec un script CGI de téléchargement de fichier.
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 wrote:
J'ai un problème de comportement de IE6 avec un script CGI de
téléchargement de fichier.
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 ?
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
In article <4743ee1d$0$31115$, 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".
In article <4743ee1d$0$31115$426a74cc@news.free.fr>,
pgoiffon@free.fr.invalid 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".
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
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 !
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 !
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 !
