Discussion :

[alain78]

Bonjour,

Avez vous déjà rencontré cette anomalie (bug?) de IE9.

Voici le problème.

J'ai un script (biblio.php) en charge d'une bibliothèque de fichiers.
L'utilisateur peut uploader des fichiers (formats pdf, xls, etc.) puis les consulter.
Lors de la consultation le fichier s'ouvre dans une nouvelle fenêtre avec le logiciel ad'hoc.

Sur le serveur, les fichiers sont enregistrés dans un dossier.
La liaison client-serveur est en mode SSL.

Par mesure de sécurité, pour éviter qu'un fichier ne puissent être lu à partir du web je procède comme suit:

Après l'upload du fichier, je change (via le script php) les propriétés du fichier
NB: $dest est le chemin complet du fichier.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
         move_uploaded_file($_FILES['fichier1']['tmp_name'],$dest);
	//mise en place des restrictions d'acces	
	chmod($dest, 0000);

J'ai vérifié via FTP sur le serveur, le fichier est correctement enregistré avec aucun droits (-----------) et le propriétaire du fichier est httpd.
Ainsi personne sauf le script via le web ne peut ouvrir ce fichier

Puis si l'utilisateur demande (via le script sous web) la consultation ou l'ouverture du fichier, je rétabli momentanément les droits.
NB: ouvre_pdf est un fonction personnelle qui ouvre les fichiers.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
		if (file_exists($file)) {
			$chemin_fichier=$dossier.$file;
			//levée temporaire des restrictions d'accès
			chmod($chemin_fichier, 0700);
			ouvre_pdf($chemin_fichier);
			//remise en place des autorisations d'acces	
			chmod($chemin_fichier, 0000);
		}

Voici ce qui se produit sur mes 2 ordinateurs différents:

PC n°1. Windows XP
Tout est OK. Le fichier (exemple. mon_fichier.pdf) est correctement ouvert avec
- IE8 8.0
- Firefox 12.0
- Chrome 18.0

PCn°2 (Windows 7 Edition familaile Premium)
Le fichier est correctement ouvert avec
- Firefox 11.0
- Chrome 18.0

Mais sous IE9 non seulement le fichier (mon_fichier.pdf) n'est pas ouvert MAIS incompréhension totale, IE9 me propose d'enregistrer le SCRIPT biblio.php.
Et si j'essaye d'enregistrer le script, IE9 ne fait rien. Il est bloqué (heureusement).

Avez vous rencontré ce problème ?

S'agit il d'un bug de IE9 ?

Merci à vous.

[RunCodePhp]

Salut

As tu indiqué le type de fichier qui est proposé dans l'entête ?
Ceci se faisant avec le fonction -> header()

Si tu pointes directement sur un fichier Pdf existant et valide (genre doc.pdf), est-ce que IE9 parvient à l'ouvrir ?

[Invité]

... bug de IE9 ? ...

C'est un pléonasme.
I.E. est un bug à lui tout seul.

Bref. Peut être une définition de header('...') ? type-mime ?

[alain78]

Voici ma fonction ouvre_pdf qui me semble correct

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
function ouvre_pdf($fichier) {
$date_temp=date("d-m-Y H:i");
 
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename='.basename($fichier));
    header('Content-Transfer-Encoding: binary');
    header('Expires: 0');
    // désactivation du cache
    header('Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0');
    header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date dans le passé
    header('Pragma: public');
    header('Content-Length: ' . filesize($fichier));
    ob_clean();
    flush();
    readfile($fichier);
    return;
}

Par contre, sur la même machine, toujours avec IE9 mais sur un site mirroir NON SSL, IE9 ouvre correctement le fichier.

Je ne comprend pas pourquoi cela fonctionne correctement en mode http et incorrectement en mode https avec strictement la même configuration et le même script.

Je poursuis mes investigations

[alain78]

J'ai trouvé le pourquoi du comportement de IE9.

Je donnes l'explication car elle pourra peut être servir ultérieurement à quelqu'un d'autre.

En fait il s'agissait d'un paramétrage (abusif ?) de IE9.
Dans les options internet, dans la rubrique avancé, il y a une toute petite case à cocher/décocher qui s'intitule :
Ne pas enregistrer les pages chiffrées sur le disque.
Par défaut cette case est cochée. Pourquoi ?
Après l'avoir décochée, tout est rentré dans l'ordre.

Voilà.

Merci à tous.

@lain

[Benjamin Delespierre]

J’hallucine, IE stocke les pages chiffrées sur disque

[RunCodePhp]

Ne pas enregistrer les pages chiffrées sur le disque.
Par défaut cette case est cochée. Pourquoi ?
Après l'avoir décochée, tout est rentré dans l'ordre.

Pas sûr que ce soit une bonne solution.

Si tu est le seul à utiliser cette fonctionnalité pour le téléchargement, pourquoi pas.
Mais tes utilisateurs/internautes eux risques fort de ne pas cocher cette case là.
Du coup ce problème persistera pour les autres sans même que tu sois au courant (à moins qu'ils t'avertissent).


Il serait mieux de trouver le vrai problème, et corriger.
Maintenant, quel est le problème ???


Ce code ci-dessous est il indispensable ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ob_clean();
flush();

Théoriquement il ne le devrait pas.
Supprime le pour voir si ton code fonctionne sans.

Ton document est il vraiment valide/conforme pour le SSL ?
J'en ai pas l'impression.
- Peut être aurait il une partie des éléments du document en SSL et une autre sans SSL et du coup IE9 trouverait ça douteux.
- Ou alors il y aurait 2 parties distinct en SLL avec 2 signatures différentes.
Tout cela à cause de ces 2 lignes.
Pure hypothèse.

[alain78]

En fait :

1 ==> si j'enlève les 2 instructions ob_clean(); flush(); avec l'option d' enregistrer les pages chiffrées sur le disque alors IE propose d'ouvrir le fichier. Puis quand on clike sur OK il affiche très furtivement une massage 'Examen de l'analyse de sécurité' puis ADOBE READER (c'est un pdf) envoie un message d'erreur disant qu'il ne peut pas prendre en charge ce type de fichier. Pourtant il le fait sous FF.

2 ==> si je n'enlève que l'instruction ob_clean() avec l'option d' enregistrer les pages chiffrées sur le disque alors le fichier est ouvert correctement par Adobe Reader.

3 ==> si je n'enlève que l'instruction flush() avec l'option d' enregistrer les pages chiffrées sur le disque j'obtiens le même résultat qu'au n°1

4==> je refais le cas 1 avec l'option de ne pas enregistrer les pages chiffrées
alors IE me propose :
- soit d'ouvrir le fichier en me précisant qu'il ne sera pas enregistré automatiquement
- soit de l'enregistrer
- soit de l'enregistrer sous
Mais le fichier qu'IE propose est le script php !!!

5==> Idem que 2 avec l'option de ne pas enregistrer les pages chiffrées
alors IE me propose d'enregistrer le script php !!!

6==> idem que 3 avec l'option de ne pas enregistrer les pages chiffrées
alors IE me propose d'enregistrer le script php !!!

Conclusion: il est nécessaire en mode SSL d'autoriser IE9 à enregistrer les pages chiffrées sur le disque.
Je dois également conserver les 2 instructions comme cela est préconnisé dans le manuel.

http://fr.php.net/manual/fr/function.flush.php

Il est vrai que sous IE9, l'utilisateur devra vérifier ce paramétrage (en sera t il capable ?) ou bien ...utiliser un autre navigateur.

@lain.

[RunCodePhp]

5==> Idem que 2 avec l'option de ne pas enregistrer les pages chiffrées
alors IE me propose d'enregistrer le script php !!!

6==> idem que 3 avec l'option de ne pas enregistrer les pages chiffrées
alors IE me propose d'enregistrer le script php !!!

Ok, mais quoi d'autre qui diffère entre ces 2 là et des 4 premier ?
J'ai pas compris.


Je n'ai pas IE9 sous le coude, uniquement IE8 sur XP, du coup je ne pourrais dire.

Sur IE8 par défaut cette case est décochée, du moins je suppose car j'ai absolument pas souvenir de toucher à ça (et je suis le seul à l'utiliser).
Donc en option -> Enregistrer les pages chiffrées sur le disque.

Donc sur IE8 ce serait l'inverse par défaut que IE9.
Je dirais que ce serait étonnant.


Faudrait peut être confirmer l'état (coché/non coché) sur IE9.
Selon cas soit ça causera problème pour tes utilisateur ou pas.



Je persiste à dire que faire un ob_clean() juste après avoir défini tes entêtes pourrait causer des problèmes sur le fonction de ce téléchargement.
La doc dit ceci :

Cette fonction vide le tampon de sortie sans l'envoyer au navigateur.

2 ==> si je n'enlève que l'instruction ob_clean() avec l'option d' enregistrer les pages chiffrées sur le disque alors le fichier est ouvert correctement par Adobe Reader.

C'est théoriquement le fonctionnement par défaut sur IE8.
Donc en supprimant cette fonction ob_clean() tu obtiendrais un fonctionnement normal.

Il faudrait supprimer ces 2 fonctions de toute manière, surtout ob_flush() car il ne faut rien renvoyer avant.
La seule chose à renvoyer ce sont les entêtes et le flux du document (le pdf).

[alain78]

Ok, mais quoi d'autre qui diffère entre ces 2 là et des 4 premier ?

Voici en résumé
1 => ob_clean() + flush() + enregistrer les pages chiffrées = ouverture du fichier demandé

2 => flush() + enregistrer les pages chiffrées = ouverture du fichier demandé

3 => ob_clean() + enregistrer les pages chiffrées = ouverture du fichier demandé

4 => ob_clean() + flush() + NE PAS enregistrer les pages chiffrées = proposition d'ouvrir le fichier script PHP

5 => flush() + NE PAS enregistrer les pages chiffrées = proposition d'ouvrir le fichier script PHP

6 => ob_clean() + NE PAS enregistrer les pages chiffrées = proposition d'ouvrir le fichier script PHP

Sur IE8 par défaut cette case est décochée, du moins je suppose car j'ai absolument pas souvenir de toucher à ça (et je suis le seul à l'utiliser).
Donc en option -> Enregistrer les pages chiffrées sur le disque.
Donc sur IE8 ce serait l'inverse par défaut que IE9.

Sur ma machine n°1 équipe de IE8 la case "ne pas enregistrer les pages" est bien décochée et les fichiers demandés sont bien ouverts correctement.

Faudrait peut être confirmer l'état (coché/non coché) sur IE9.

Sur IE9 je n'ai jamais changé cette case que j'ai découverte hier. Donc c'est le même état d'origine IE8 et IE9 = case décochée ce qui signifie que par défaut à l'origine IE enregistre les pages chiffrées sur le disque.

Je persiste à dire que faire un ob_clean() juste après avoir défini tes entêtes pourrait causer des problèmes sur le fonction de ce téléchargement.

Je ne le pense pas car
1° j'ai fais les 2 tests (cas 3 et 6) qui ont mis hors de cause cette fonction.

2° j'ai fais un test à partir d'un autre site HTTPS (celui de ma banque en ligne). J'ai essayé de télécharger mon relevé de compte. J'ai obtenu les mêmes résultats : lorsqu'on autorise l'enregistrement sur disque des pages chiffrées le fichier (relevé de compte) est bien ouvert correctement à l'écran. Dans le cas contraire c'est le fichier html qui est proposé à l'enregistrement mais on ne peut l'enregistrer car la fenêtre d'enregistrement reste bloquée.

3° j'ai fais le test en supprimant les 2 fonctions et j'obtiens les mêmes résultats: ouverture correcte des fichiers si l'enregistrement des pages chiffrées est permis, et proposition d'ouverture du script dans le cas contraire.

DERNIER TEST
Sur IE8 j'ai coché la case "ne pas enregistrer les pages chiffrées". Et bien, IE8 ouvre très correctement le fichier demandé et non le script.

Donc l'erreur doit venir d'un autre paramètre de sécurité de IE9 sur l'autre machine.
Je vais donc investiguer dans cela.

Bonne journée.

@lain

[alain78]

Sur IE8 et IE9 le paramètre d'origine est d'enregistrer les pages chiffrées sur le disque.

J'ai découvert cela en restaurant (bouton : rétablir les paramètres avancées)
les paramètres d'origine.

Donc tout est OK pour mes utilisateurs sauf pour ceux qui auront modifié ce paramètre.

@lain

[RunCodePhp]

Ok, concernant ce paramètre sur IE tu est revenu à la normal/par défaut, donc c'est bon.

Mais de mon coté j'évoquais surtout l'usage des ces 2 fonctions ob_clean() ob_flush() (indépendamment de ce problème sur IE) qui théoriquement n'est pas à faire.

Par ailleurs, sauf erreur, aucun des test n'effectue ça, c'est à dire :
- enregistrer les pages chiffrées (par défaut)
- pas de ob_clean()
- pas de ob_flush()

Si en faisant ainsi tu rencontres un problème, c'est qu'il y a quelque chose qui ne va pas dans la manière de faire (déroulement du code, renvoie de contenu avant de (re)définir les entêtes, etc ...).


C'est plus de cette ordre là.
Maintenant, si en l'état actuel ça te suffit, l'affaire est réglée.

[alain78]

Lorsque j'effectue le test

- enregistrer les pages chiffrées (par défaut)
- pas de ob_clean()
- pas de ob_flush()

Adobe Reader (c'est un fichier pdf) s'ouvre mais indique qu'il ne peut ouvrir le fichier qui est corrompu....etc.

Je ne vois pas où se situe mon erreur :


Après sélection du fichier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
		if (file_exists($file)) {
			$chemin_fichier=$dossier.$file;
			//levée temporaire des restrictions d'accès
			chmod($chemin_fichier, 0700);
			ouvre_pdf($chemin_fichier);
			//remise en place des autorisations d'acces	
			chmod($chemin_fichier, 0000);
		}

Puis ouverture du fichier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
function ouvre_pdf($fichier) {
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename='.basename($fichier));
    header('Content-Transfer-Encoding: binary');
    header('Expires: 0');
    // désactivation du cache
    header('Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0');
    header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date dans le passé
    header('Pragma: public');
    header('Content-Length: ' . filesize($fichier));
    ob_clean();
    flush();
    readfile($fichier);
    return;
}

Saura t on jamais un jour ????

@lain




Il n'y a pourtant pas des milliers de lignes de code et je ne vois pas pourquoi le fait de supprimer ces 2 fonctions en maintenant l'autorisation d'enregistrer les pages empêche une ouverture du fichier normal.

[wako057]

as-tu essayé:
header('Content-type: application/pdf');
?

[stealth35]

Y'a beaucoup trop d'header, et de plus des doublons, faut laisser le serveur faire son travail

[alain78]

Y'a beaucoup trop d'header, et de plus des doublons, faut laisser le serveur faire son travail

Quels doublons ?

as-tu essayé:
header('Content-type: application/pdf');
?
l

Pourquoi se limiter à l'ouverture exclusive des fichiers pdf ??

mon header

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
header('Content-Type: application/octet-stream');

permet de lire tous les types de fichiers et pas seulement les pdf.

[stealth35]

Quels doublons ?

Expires, de plus pourquoi le mettre à 26 Jul 1997 ?
Le serveur fait très bien son travail tout seul, pas besoin de bidouiller le MIME non plus

[RunCodePhp]

Si, pour que ton code fonction tu est contrains d'utiliser ob_clean(), donc de vider le tampon de sortie, ça sous entend qu'avant ça il y a eu du contenu de renvoyé.
Comme du HTML, voire un espace (par un echo ou autre).
Faudrait voir qu'est-ce qui est fait avant appel à cette fonction ouvre_pdf().

Ceci est expliqué dans la doc pour la fonction : header()

N'oubliez jamais que header() doit être appelée avant que le moindre contenu ne soit envoyé, soit par des lignes HTML habituelles dans le fichier, soit par des affichages PHP. Une erreur très classique est de lire un fichier avec include ou require, et de laisser des espaces ou des lignes vides, qui produiront un affichage avant que la fonction header() ne soit appelée. Le même problème existe avec les fichiers PHP/HTML standards.

A mon sens il est fort probable que ça soit le cas.
Reste maintenant à le confirmer.
Ceci dit, même si c'est le cas, peut être que remanier tout cela risque d'être un compliqué.
Donc faut voir.

A la limite, j'aurais plutôt fait comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
function ouvre_pdf($fichier) {
    // On vide le tampon
    ob_clean();
 
    // Les entêtes
    header('...');
 
    // Le flux du fichier
    readfile($fichier);
    return;
}

C'est à dire de vider en 1er, histoire de ne plus rien avoir dans le tampon, puis après redéfinir certaines entêtes.
Et pour ob_flush(), il ne faudrait pas le faire, surtout pas je dirais même.
C'est presque contradictoire avec le ob_clean().
(On vide le tampon, puis juste après on le renvoie. Faut savoir ...)

[alain78]

Effectivement, je n'avais pas vu le doublon expires !!!
Je ne sais pas pourquoi il y avait le 2ème.

Je ne conserve donc que le 1er.

Je me suis penché sur la bufferisation de sortie que je connaissais mal.
Effectivement mon code était inadapté.
Je sais qu'il me reste à optimiser les headers ce que je vais faire ce jour.

Dans l'attente, je retiens la solution de RunCodePhp que j'ai comprise.

Merci à vous deux.

Bonne journée.