Salut
 
Voila je voudrais télécharger un fichier de mon serveur vers le client, ça c'est facile, et surtout savoir d'une façon ou d'une autre QUAND le fichier a fini de se télécharger...
 
Comment faire ?
 
Merci  

AMHA impossible.

Beh je vois quelques sites le faire... et quelques gens dire qu'il l'ont déja vu faire, sans savoir comment...
Il doit bien y avoir un moyen...

Tu peux pê vérifier regulièrement le connection_aborted() dans un script php qui lit le fichier à envoyer et envoie le flux vers le client. Ca peut peut-être te dire si le client a annulé avant la fin.

impossible je pense

Y'a des applets Java qui font ce genre de choses...Je te laisse chercher et y jeter un coup d'oeil pour voir si ça te plait...

J'imagine qu'en slalomant entre les standard, y'a moyen de faire un truc bien crade en JS :
-> lorsque tu cliques sur le lien de téléchargement, ça lance un JS
-> Ce JS change le href d'un iframe invisible
-> Puis dans une boucle il check le ReadyState (à vérifier si tous les navigateurs supporte cette propriété)
-> Si ça ne tombe jamais à COMPLETE, alors c'est que le dwl a foiré
 
C'est juste une idée qui me vient comme ça, je ne suis absolument pas sûr que ça marche.

Mon truc partait d'un bon sentiment, mais sous IE7 RC1 tout du moins, c'est pas conculant
 
http://magicsite.manga-torii.com/tests/dwl.htm
 
Et Moz connait pas du tout .readyState, c'est plus simple

bin le readyState c'est sur les objets xmlHttpRequest, je crois pas que tu puisses les mettre sur une iframe

Ca me parait intéressant ça, mais comment faire ce script php "qui lit le fichier à envoyer et envoie le flux vers le client" ? Pour l'instant je fais ça avec des headers...

Pourquoi pas mais du coup c'est moins portable, si le mec a pas java etc, pour un truc aussi con en plus... Mais je vais voir  

euh admettons que le connection_aborted() te retourne true, ça veut donc dire que la connection HTTP a été abandonnée...  
Comment fais-tu à ce moment là pour renvoyer quelque chose au client?

 
L'idée c'était de mettre dans le header le type du fichier et le nom du fichier. Ensuite tu lis le fichier avec des file_get_contents et t'escris dans le flux avec des file_put_contents. Juste avant la fin tu test si la connection n'est toujours pas terminé. Maintenant ça ne doit pas marcher si y'a un buffer de sortie, ou alors en flushant et je ne sais pas si arreter un download envoit bien un message vers le serveur.

ie l'accepte, mais ça n'a de toute façon pas le bon comportement (c'est complete alors que le fichier n'est pas fini de dwl, et si c'est une 404, c'est complete quand même...)

Chtite question : pourquoi tu veux absolument savoir quand le téléchargement est fini ?

c'est un projet commercial de téléchargement de musique (je ne suis que simple stagiaire !). On ne peut pas télécharger 2 fois le mm mp3 (a moins de le racheter), donc si l'user fait "annuler", qu'il a une déconnexion, une coupure de courant, c'est DSC. On doit donc controler si le fichier a bien été reçu.
   
 

Aie à tester mais je ne suis déja pas trop habitué aux file_get_contents etc... jva voir ça

C'est légal d'interdire l'accès à quelquechose qu'on a acheté ?
 
Non, pas du tout, et ce, en vertu du droit de l'auteur de refuser la copie privée. Par conséquent, l'éditeur s'engage à fournir une copie de sauvegarde A VIE si le client en fait la demande. Donc si vous obligez le client à repayer pour récupérer une copie de sauvegarde, c'est direct prison pour vous Si vous estimez alors que c'est ensuite à l'éditeur de traîter avec le client, sans licence émise de votre part, c'est vous-même qui devez remplir ce rôle réservé à l'éditeur en temps normal (un CD original est assimilé à une licence par exemple). Faites le test, achetez un CD à la FNAC, prendez explosez-le dans un mur, mettez tous les petits éclats dans une enveloppe, et envoyez le tout à Sony Music par exemple, en demandant une copie de sauvegarde pour remplacer votre CD dégradé. Vous recevrez gratuitement un CD sous quelques semaines. C'est la loi. En l'absence d'une preuve de ce genre émise par vos soins (pas de ticket de caisse, pas de support matériel, etc.) c'est donc à vous de garantir ce service après-vente.
 
Donc à la base, tu t'emmerdes pour rien.

C'est intéressant, mais il m'étonnerait que sur I-Tunes par ex, on puisse télécharger les fichiers qu'on achète un nombre indéfini de fois (à moins d'en faire la demande)... Je sais que ce n'est pas le cas sur Traxsource par ex.
 
En admettant qu'on accepte tout à fait de fournir une copie de sauvegarde si l'utilisateur en fait la demande, c'est quand mêle beaucoup plus pratique de considérer que le fichier n'a pas été téléchargé si le téléchargement s'est mal terminé, et qu'il puisse le retélécharger sans avoir à faire la demande, non ?
 
Donc non je m'emmerde pas pour rien.

Non, là où tu t'emmerdes pour rien, c'est que le gars, tu peux lui laisser accès à ses fichiers une fois qu'il les a téléchargé. Y'a aucune raison qui vous en empêche, et c'est très facile de détecter ceux qui abusent.

Parcequ'à ce compte-là, moi je vais prendre un malin plaisir dans quelques mois à envoyer un superbe hoax demandant à tous les clients de itunes, vous et autres de faire la demande d'envoi de tous leurs fichiers téléchargés. rien de tel pour foutre une merde noire, et profiter du peu de droits que le client a encore

T'as pas tort mais laisser tous les fichiers achetés en libre téléchargement pose quelques pbs :
 
- ça suppose de mettre une liste des téléchargement non effectués et une autre pour ceux déja effectués, ça pas de pb. Mais :
 
- le mec file son Login/MDP a ses potes, ou même carrément fait un compte collectif, et tous pourront télécharger ce que le mec a acheté...
- le mec a foiré son téléchargement, il doit aller dans sa grosse liste pour le retrouver (mais si c'est trié par date, pas de pb) et c'est quand même moins sympa que de le garder dans la liste des "téléchargements non effectués".
- comment faire la différence entre le/les mecs qui "abusent" du téléchargement et le mec qu'a pas de bol ou une mauvaise connexion et qui essaye 30 fois de télécharger en vain ?

Mais les DRM servent pas à vérouiller tout ça ? On peut pas permettre de télécharger autant de fois qu'on veux un fichier DRMisé qui serait virtuellement le même et qui ne pourrait marcher qu'un certain nombre de fois et pour 1 seul utilisateur ?  
 
Enfin le pblm n'est pas la défense du pauv' chti consommateur Faut laisser la selection naturelle opérer, si le système est trop contraignant ils iront à la concurence ou sur le pi-toupie

Pas de DRM sur not site
 

Je suis pas tout à fait d'accord mais tu admettras que c'est autre débat

 
c'est simple, tu logues le nombre de téléchargement de chaque fichier avec un historique sur 1 mois.
si t'as plus de 5 téléchargements et qu'ils proviennent de différentes IP, alors tu peux être sur que le gars à filé son compte.
 
faut une tolérance de 2 ou 3 téléchargement pour des IP différentes, genre je dwl chez moi, mais je me dis qu'au boulot j'ai un casque et je veux écouter aussi au boulot par exemple. au delà de 5, surtout si les 5 tentatives ne se font pas dans la même heure (là c'est le gars qui n'a pas de pot du tout avec sa connexion) tu envoies un mail direct au client en lui expliquant la situation, et qu'une enquête de votre côté est ouverte afin de vérifier ce qu'il fait, et surtout, tu lui bloques le téléchargement pendant plusieurs minutes avec un bon gros message des familles.
même si vous ne faites rien derrière, ça va vite calmer le gars.
 
et tout ça, c'est vraiment finger in the nose à coder.

Comme dit précédemment, il te faut un script qui va envoyer les headers qui vont bien pour envoyer le fichier au client.  
 
Après ces headers, tu places les requêtes pour la base de données (tel fichier téléchargé par untel, etc).
Si le téléchargement est annulé, le script ne se poursuit pas, et les requêtes ne seront donc pas exécutées. Tu peux donc facilement savoir si le téléchargement a été complété ou non.

Qu'est-ce que tu appelles "après les headers" ?
Si je fais :

Dans tous les cas, le echo ne sera jamais interprété, si ?
 
A moins que tu parles du corps de la requete    (ne me tuez pas, je m'instruit depuis ce matin sur les req HTTP   )

 
Un CRC joint avec ton mp3  

Ca normalement ça te creer un fichier local $nomFichier et qui contient "you win" si tu l'ouvre avec le notepad

 
 
Le echo tu ne le verras pas s'afficher à l'écran bien sur, puisque tu as envoyé des headers spécifiant au navigateur qu'il fallait téléchargé ce qu'on lui envoyait, mais il est effectivement exécuté comme dit dans le post d'au-dessus.
 
Si à la place de ton echo "you win"; tu fais une requête SQL, elle sera exécutée à la fin du téléchargement. Si le téléchargement est annulé, le code placé après les headers ne sera pas exécuté. Ca résoud donc ton problème

t'es gentil j'ai pas la science infuse  

Djebel1 > un truc que je ne comprend pas, c'est quoi qui fait que l'anulation d'un téléchargement commencé empéche le script d'exécuter le code situé aprés les instructions d'envoie du fichier? Par ce que c'est bien ce genre de cas que theredled aimerait pouvoir gérer.
Si c'est la limite des 30 secondes qui empéche ça, alors ca n'est pas forcément une méthode trés fiable vu que rien n'empéche de changer les réglages du php.ini (un timeout de plusieurs minutes, ca c'est déjà vu même si c'est rare) et alors le serveur http risque de détecter la perte de liaison ce qui risque de conduire à l'exécution du reste du code php alors que le fichier n'a pas été reçu en entier.

j'en ai aucune idée, je l'ai constaté lors du développement d'une application gérant une file d'attente pour le téléchargement :  
 
je faisais une requête sql avant de balancer les headers (insertion dans la file d'attente), et je virais la personne de la file d'attente à la fin de son téléchargement, avec une requête placée après les headers. J'ai constaté que si tu annulais le téléchargement, la requête placée après les headers n'était jamais exécutée.  
J'ai donc du rajouter une requête nettoyant les téléchargements considérés actifs depuis plus d'une heure.
 
Ce n'était pas du tout lié à un timeout, mais bien à l'éxécution du script, qui est stoppé si l'utilisateur annule le téléchargement.  
 
Alors là je pense à un truc : pour lire le fichier balancé à l'utilisateur, j'utilisais une fonction "homemade" (mais à partir d'un truc trouvé sur php.net), qui permettait de lire le fichier pti bout par pti bout, plutot que de lire 300 Go direct en un seul coup. C'est peut-être grâce à cette fonction qu'il y avait ce comportement : tant que le fichier n'est pas fini d'être téléchargé, c'est cette fonction qui a la main. Mais ça n'explique pas pourquoi annuler le téléchargement bloque l'exécution du reste du script. Je pense donc que c'est un comportement normal de PHP, mais c'est peut-être lié à cette fonction. Dans les deux cas son problème a une solution ^^

Yo, après tests, mauvaise piste je pense désolé (edit : ou presque)
 
J'ai pondu ce code :
 
index.php

 
telech.php

La variable de session 'bou' devrait ne contenir 'boum' que lorsque le fichier est téléchargé. Hors :
- elle le contient même si j'ai cliqué sur "annuler" de la fenetre me proposant le téléchargement
- elle le contient dès que cette fenetre s'affiche en fait...
 
edit : par contre ton dernier post est cool, tu te souviens ou tu as trouvé ce code ?

Si tu test en local c'est normal, le fichier est considéré instantanément téléchargé.
 
De plus là tu ne fais pas télécharger de fichier ... il est où le readfile ? Tu balances juste une série de headers, qui sont donc instantanément envoyé au client. Donc normal que ça marche pas. Avec ton code, que ce soit en ligne ou en local, ça sera comme si le fichier était instantanément envoyé au client.
 
Et enfin, si tu me dis que tu as fait un test en ligne, en faisait réellement télécharger un fichier, et que ça marche pas, alors c'est simple, ça veut dire que c'est ma fonction "homemade" qui permet ce comportement. Dans ce cas je la posterai et pis voilà
Mais fais déjà un vrai test avant
 
edit : ha oui si tu as fait cancel ça aurait ptet du marcher malgré tout. Bon bah je posterai mon code ce soir (là je l'ai pas, suis pas sur le bon pc)

Sinon, une idée très simple...
 
Pourquoi ne pas simplement permettre à l'utilisateur de télécharger le fichier autant de fois qu'il veut, pendant un certain temps (1h, 2h ou 4h par exemple).
Ca te garanti qu'il pourra le télécharger même si ça plante la première fois.
 
Dans tous les cas, les éventuels abus (prêt de compte, etc.), suffit d'un site web perso, d'un logiciel de messagerie, un CD ou une clé usb pour que le gars ensuite fasse tout ce qu'il veut avec le fichier téléchargé. Donc avoir la parano de voir des gens partager leur compte, et prendre le risque d'être repérés (une simple analyse des logs permet de détecter rapidement les gens qui font une utilisation "étrange" du site), c'est pas vraiment bloquante, puisqu'ils préféront de toute façon les autres systèmes qui ne laissent pas autant de traces, et surtout, bien moins évidentes.

On avait pensé à une limite de 2 jours (on peut acheter un fichier je sais pas ou et vouloir le telecharger chez soi par ex.). C'est surement ce qu'on va faire si aucune solution viable n'est trouvée...
 

Tous les moyens que tu cites nécéssitent quand même beaucoup plus d'efforts que de laisser son login/mdp... et non je ne pense pas qu'une "simple" analyse des logs permette fiablement de détecter les abus, et surtout cette analyse quoique t'en dise c'est du code, de la traduction, et de la prise de tête, des stats, et le site est sur la fin...
 
Bref dans tous les cas c'est super intéressant de pouvoir détecter si le téléchargement s'est bien déroulé, et ça me servira surement dans d'autres projets et peut-etre à toi aussi  

 
l'analyse des logs, y'a des softs tous fait qui existent depuis au moins 10 ans, et c'est d'une simplicité à mourrir.
d'autant que maintenant la plupart des serveurs d'application permettent de gérer leurs logs dans une base de données. c'est quand même pas compliqué de retrouver quelle ip à lancé quelle page à quelle heure et avec quels paramètres.
 
moyennant un effort minime, tu peux donc savoir qui fait quoi dans tel compte à tout moment.

J'ai tout testé en ligne. Sinon effectivement c'est mieux avec readfile    mais ça marche pas plus (ca évite juste d'avoir un fichier de 0 octets). Les instructions après les headers et le readfile sont toujours interprétées dès qu'on me propose le téléchargement, sans meme attendre un ok ou annuler.
Sinon ce serait très cool de ta part que tu postes ton code  

Oui c'est vrai que le header c'est logique, vu qu'il le lit pour avoir le nom du fichier. Ensuite, c'est vrai que les navigateur commencent à télécharger le fichier avant même qu'on clique sur ok pour gagner du temps ... Donc si on attend 1 heure avant de cliquer sur annuler, t'aura de toute manière l'impression qu'on l'a téléchargé puisque c'est ce qui c'est passé :-\
 
Pê que dans le cas d'un transfert assez long on peut savoir si le gars a annulé pendant le d/l ... mais finalement je ne sais plus trop si ça permet de savoir si le gars s'est fait deconnecté pendant le d/l

Voilà le code que j'utilise. Et donc en ligne et avec des fichiers qui sont pas téléchargés instantanément, si tu cliques sur annuler la suite du code ne s'execute pas.

et la fonction _readfile_chunked