Cherche piste de débugage pour un input / submit qui tourne mal

Auto-edit : le thread est à garder pour toutes les bonnes manips indiquées par Semantic;
en revanche, le bug est lié au navigateur, Chrome en l'occurrence, car Firefox fait tourner correctement à la fois le download chez l'hébergeur et le download sur le serveur androïd.

Bonjour,

J'ai une page qui permet de downloader un fichier de résultats de formulaire.

Chez un hébergeur, cela tourne bien, une fenêtre s'ouvre, me proposant de charger mon fichier (excel ou texte selon le choix).

Sur un serveur local (et même deux différents), le fichier, bien que toujours d'extension correcte, est en fait un fichier XHTLM qui est :
- même si le download se passe bien, le texte suivant apparait sur la page
"Export creation complete. Your download should begin now. If it does not start, download the file here."
- si on clique une fois que le download est fait, fort logiquement une page apparait, disant qu'il n'y a pas de fichier export prêt
- et c'est le code XHTML de cette page qui apparait dans le fichier au lieu des résultats

voici le code du bouton:

<div class="form-actions form-wrapper" id="edit-actions"><input type="submit" id="edit-submit" name="op" value="Download" class="form-submit" /></div>

je ne demande évidemment pas la solution, mais vers quoi creuser pour avancer dans la recherche : code, serveur, OS, ... ?
Modifié par corbintheone (21 Jun 2015 - 12:09)

Regarde du coté des en-têtes http

Content-Disposition: attachment; filename=NOMDUFICHIER
Content-Type: application/force-download (celui-ci n'est pas standard mais parfois utilisé)

Regarde aussi si ton fichier n'est pas compressé à la volée par ton serveur

Sur php pour afficher les headers :

var_dump(headers_list());

Pour vérifier que zlib est activé ou pas :

var_dump(ini_get("zlib.output_compression"));

Modifié par semantic (18 Jun 2015 - 14:57)

je dis tout de suite merci, car comme cela risque de me prendre du temps pour mettre en oeuvre, je ne voudrais pas paraître impoli

auto-edit : je me suis sous-estimé :
header --> string(12) "headers_list"
zlib --> string(0) ""
Modifié par corbintheone (18 Jun 2015 - 18:46)

Donc la compression est désactivé.
Tu peux comparer les entêtes entre les deux sites et ajouter celles qui manquent sur le site en local pour tester.
Ah oui un truc à vérifier aussi...Que le site ne place pas le fichier en cache.
Si ça marche pas ajoute les lignes suivantes, au début de ta page, pour tester :

$filename = 'MONDUFICHIER';

//désactive la mise en cache

header('Pragma: no-cache');
header('Expires: 0');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-cache, must-revalidate');
header('Cache-Control: post-check=0,pre-check=0');


// Tu peux ensuite forcer le téléchargement 

header('Content-Type: application/force-download');
header('Content-Disposition: attachment; filename="' . $filename . '"');
header('Content-Length: ' . filesize ($filename));

J'espère que ça t'aide.
Modifié par semantic (18 Jun 2015 - 20:44)

Ca y est, je suis arrivé à trouver les headers (j'ai allégé pour ne mettre que ce qui me semblait signifiant)

site qui ne fonctionne pas :

Transfer-Encoding: chunked
X-Generator: Drupal 7 (http://drupal.org)
Content-Language: fr
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0

site qui fonctionne :

Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Content-Language: en
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Accept-Ranges: bytes
Vary: Accept-Encoding
Date: Fri, 19 Jun 2015 07:57:36 GMT
Connection: keep-alive
Content-Length: 10387

A part la langue (mais, ça on s'en fiche ), ce serait le :

Content-Encoding: gzip
Accept-Ranges: bytes
Vary: Accept-Encoding

dans le second qui feraient la différence ?

Parce que si je comprends bien, le

Transfer-Encoding: chunked

du premier est lié à la persistance de la connexion, traduite dans le second par le keep-alive et le content-length.

Si je fais le lien entre ta suggestion et ce lien pour la modification des en-têtes HTTP (http://www.alsacreations.com/astuce/lire/1152-en-tetes-http.html), j'insère ton code dans un .htaccess pour le forcer à charger mon fichier ?

Tu utilises Transfer-Encoding: chunked lorsque tu ne connais pas à l'avance la taille des données que tu dois transférer.
Personnellement, je précise toujours la taille avec un Content-Length mais les deux fonctionnent.

Connection: keep-alive est normalement fixée sur le serveur. Tu peux la placer à "On" afin que ton serveur permette les session HTTP de longue durée.

T'as essayé de remplacer les entêtes pour qu'elles soient identique?
Plus tu donnes d'indications à ton serveur sur la façon dont il doit se comporter, moins t'as de risque que ça plante.
Le lien vers ton fichier sur le site en local est bon? Il pointe bien sur le fichier?
Modifié par semantic (19 Jun 2015 - 12:13)

Oui tu peux ajouter les entêtes dans un fichier htaccess.
Penses à faire un FilesMatch afin que ton serveur sache comment traiter les fichier excel ou texte par rapport aux autres.
Modifié par semantic (19 Jun 2015 - 12:12)

Pour (tenter de) faire toutes ces manips de façon plus simple, je connecte :
- mon PC sur le net
- mon serveur situé sur un android au net
(- et même mon androïd au pc pour faciliter le transfert de fichiers sur mon PC par explorer de windows, mais ça n'intervient pas)

Mon serveur a en l'occurrence une adresse ip accessible par le browser de mon PC.

quand je clique sur le download de ma page résultats à partir de :

- mon androïd, j'ai le fichier pourri à l'origine du thread,
- mon PC, j'obtiens mon fichier xlsx correct !?!?!?

Je pataugeais déjà gaillardement, mais là, c'est la totale !



je parie que demain, après avoir tout éteint, puis tout rallumé -->

Je pense que tu te compliques la vie
Pourquoi tu ne fais pas une simple page de test?

download.php

<?php

$filename = 'MONDUFICHIER'; //Place ici le chemin du fichier : exemple "dossier1/dossier2/fichier1.text"


// quelques lignes qui peuvent être utile si le php.ini n'est pas bien configuré 
set_time_limit(0);// je coupe la limite de temps de php pour le test...elle est de 30s habituellement
ini_set('output_buffering', 0);// je stop le buffer de sortie
ini_set('zlib.output_compression', 0); // je stop la compression zlib

if(!is_file($filename)) {
    header ('HTTP/1.0 404 Not Found');
    echo 'Le fichier n\'existe pas!!';
}else{
    header('Content-Description: File Transfer');
    //header('Content-Type: application/force-download');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename='.$filename);
    header('Pragma: no-cache');
    header('Expires: 0');
    header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
    header('Cache-Control: no-cache, must-revalidate');
    header('Cache-Control: post-check=0,pre-check=0');
    header('Content-Length: ' . filesize($filename));
    readfile($filename);
    exit();
}
?>

Bon c'est qu'une page de test mais ça te donne une base. Tu peux ajouter, supprimer des choses et voir si ça passe ou pas
Modifié par semantic (19 Jun 2015 - 17:44)

Pour être franc des souvenirs anciens et manifestement incomplets font que je ne m'y retrouve pas autant que je l'aurais souhaité !

Bref, j'ai collé ton fichier dans un sous-sous répertoire au hasard, avec mon fichier .xlsx correct;
je vais à l'adresse du download.php sur mon androïd, il m'annonce le chargement et je retrouve bien le fichier .xlsx correctement exploitable dans mon répertoire download.

Cela pourrait-il aussi être au moment du passage de la BDD au fichier .xlsx (ou .tsv, même combat), que le module floppe sur ce serveur ?

Je vais faire une petite prière pour qu'un elfe me nettoie les neurones et les pièces du puzzle pedant la nuit

C'est une bonne nouvelle. Au moins, tu sais que ton serveur fonctionne bien et qu'il télécharge. Maintenant t'as juste à ajouter les bonnes entêtes dans ton fichier, pour que ta page fonctionne.

Ton fichier est généré par php via une base de données?

Normalement, la base de données ne devrait pas poser de problème si tu n'affiches rien avant les headers. D'une manière générale, tu ne dois rien afficher avant d'envoyer les headers.
Donc pas d'echo, print, var_dump etc...sinon ça plante direct
Modifié par semantic (20 Jun 2015 - 13:12)

Une idée que j'aurais dû avoir depuis bien longtemps :

Mon CMS Drupal + son module Webform étant installé chez un hébergeur, je peux faire tourner le download des résultats du formulaire sous :
- PC : et j'obtiens un fichier correct de mes résultats dans les deux formats possibles,
- Androïd : et j'obtiens ce fichier "pourri" d'extension .xlsx, mais de contenu XHTML.

Ni les programmes Drupal, ni la configuration serveur ne sont donc en cause, puisque je ne me sers que de Chrome sur l'androïd ...

Et bien justement, rédigeant ce mot, je me dis que pour être certain que c'est au niveau de l'Androïd que ça se passe, je teste Firefox ...

ET LÀ !!!
avec Firefox sur androïd, no problem, ni avec le download chez l'hébergeur, ni avec celui du serveur androïd !
Donc, cela vient de Chrome; et je suis allé jeter un coup d'oeil dans les réglages, rien qui me permette d'en espérer quelque chose.

Semantic, je te remercie d'autant plus que la montagne accouche d'une souris !
Et même ... toutes mes excuses.

Je mets donc résolu, et vais auto-éditer le premier post pour indiquer l'origine du bug.
Modifié par corbintheone (21 Jun 2015 - 12:10)

Si ça passe pas sous chrome, c'est qu'il y a un problème dans tes entêtes. Chrome par lui même n'a aucun problème. Je download et upload sans problème avec lui (et ça depuis des lustres)
C'est juste que tu ne donnes pas les bonnes indications pour que le téléchargement se déroule correctement
En changeant de navigateur, tu masques juste le problème.
Chrome est depuis un moment le leader du marché donc autant faire quelque chose de bien.

Tout d'abord Chrome sous PC ne me pose aucun problème, c'est Chrome sous Androïd.
Pour l'utilisation que j'en ai, à savoir que c'est moi qui décide du navigateur des utilisateurs, c'est absolument sans importance que cela ne fonctionne pas sous Chrome (et même j'en tire un avantage ! )
Alors, c'est sûr qu'intellectuellement, ce n'est pas satisfaisant, mais entre la complexité de Drupal et donc de ses entêtes, la spécificité du problème lié à (mon ?) androïd (rooté en plus), le bénéfice que j'arrive à en tirer et le temps gagné, tu comprends mon choix