À mon avis il faudrait comparer les données envoyées dans les deux cas (passe par le script php - passe pas par le script php)
Excuse-moi mais pourrais-tu m'indiquer comment faire une telle comparaison, stp ?
Si tu utilises Mozilla ou Firefox, il y a l'extension liveHttpHeaders qui te permet de voir les en-têtes échangés entre le navigateur et le serveur.
-- Bobe (Aurélien Maille) http://webnaute.net
"la vie d'un geek est un combat perpétuel contre l'imperfection"
julien.gautier
Bobe wrote:
Julien Gautier nous a dit le 08/06/2004 23:23: > >>À mon avis il faudrait comparer les données envoyées dans les deux cas >>(passe par le script php - passe pas par le script php) > > > Excuse-moi mais pourrais-tu m'indiquer comment faire une telle > comparaison, stp ?
Si tu utilises Mozilla ou Firefox, il y a l'extension liveHttpHeaders qui te permet de voir les en-têtes échangés entre le navigateur et le serveur.
Génial, merci !!
Mais les 2 techniques renvoient :
HTTP/1.x 200 OK
Date: Tue, 08 Jun 2004 21:51:17 GMT
Server: Apache/1.3.29 (Darwin) PHP/4.3.2
X-Powered-By: PHP/4.3.2
Content-Length: 25993
Keep-Alive: timeout, max
Connection: Keep-Alive
Content-Type: audio/mp3
Par contre, je viens de me rendre compte que, sous MacOSX, IE 5, FireFox et Mozilla respectent l'autoplay à false, alors que Safari non.... :-(
Safari le respecte si la ressource est donnée par une url, mais pas lorsqu'elle provient d'un readfile de php....
Julien Gautier nous a dit le 08/06/2004 23:23:
>
>>À mon avis il faudrait comparer les données envoyées dans les deux cas
>>(passe par le script php - passe pas par le script php)
>
>
> Excuse-moi mais pourrais-tu m'indiquer comment faire une telle
> comparaison, stp ?
Si tu utilises Mozilla ou Firefox, il y a l'extension liveHttpHeaders qui te
permet de voir les en-têtes échangés entre le navigateur et le serveur.
Génial, merci !!
Mais les 2 techniques renvoient :
HTTP/1.x 200 OK
Date: Tue, 08 Jun 2004 21:51:17 GMT
Server: Apache/1.3.29 (Darwin) PHP/4.3.2
X-Powered-By: PHP/4.3.2
Content-Length: 25993
Keep-Alive: timeout, max
Connection: Keep-Alive
Content-Type: audio/mp3
Par contre, je viens de me rendre compte que, sous MacOSX, IE 5,
FireFox et Mozilla respectent l'autoplay à false, alors que Safari
non.... :-(
Safari le respecte si la ressource est donnée par une url, mais pas
lorsqu'elle provient d'un readfile de php....
Julien Gautier nous a dit le 08/06/2004 23:23: > >>À mon avis il faudrait comparer les données envoyées dans les deux cas >>(passe par le script php - passe pas par le script php) > > > Excuse-moi mais pourrais-tu m'indiquer comment faire une telle > comparaison, stp ?
Si tu utilises Mozilla ou Firefox, il y a l'extension liveHttpHeaders qui te permet de voir les en-têtes échangés entre le navigateur et le serveur.
Génial, merci !!
Mais les 2 techniques renvoient :
HTTP/1.x 200 OK
Date: Tue, 08 Jun 2004 21:51:17 GMT
Server: Apache/1.3.29 (Darwin) PHP/4.3.2
X-Powered-By: PHP/4.3.2
Content-Length: 25993
Keep-Alive: timeout, max
Connection: Keep-Alive
Content-Type: audio/mp3
Par contre, je viens de me rendre compte que, sous MacOSX, IE 5, FireFox et Mozilla respectent l'autoplay à false, alors que Safari non.... :-(
Safari le respecte si la ressource est donnée par une url, mais pas lorsqu'elle provient d'un readfile de php....
pour moi c'est un mystère....
julien.gautier
Julien Gautier wrote:
Safari le respecte si la ressource est donnée par une url, mais pas lorsqu'elle provient d'un readfile de php....
ça y est, j'ai trouvé : il faut entourer le <embed> par le <object> de QT.
Julien Gautier <julien.gautier@wanadoo.fr> wrote:
Safari le respecte si la ressource est donnée par une url, mais pas
lorsqu'elle provient d'un readfile de php....
ça y est, j'ai trouvé : il faut entourer le <embed> par le <object> de
QT.
> ça y est, j'ai trouvé : il faut entourer le <embed> par le <object> de > QT. De toutes façons, l'idéal ce serait d'utiliser que le <object>
Mais puis-je faire ma manip dans ce cas (charger un fichier non accessible à Apache) ?
Julien Gautier a ecrit :
@SM wrote:
> Heu, j'y comprends rien en histoires d'en tête et de trucs
je ne veux rien cacher, mais je dois pouvoir envoyer ces sons vers le navigateur alors qu'ils se trouvent dans un dossier qu'Apache ne peut/doit pas atteindre.
J'y comprends pas plus ... mais c'est pô grave.
Je suis obligé donc d'utiliser un "readfile" par PHP pour envoyer les données au navigateur, d'où l'usage des "header".
M'enfin ? en php y a pas moyen de reader les fichiers dans une instruction php au milieu de l'embed ? au lieu de header à tous vas ?
> Heu, j'y comprends rien en histoires d'en tête et de trucs
je ne veux rien cacher, mais je dois pouvoir envoyer ces sons vers le
navigateur alors qu'ils se trouvent dans un dossier qu'Apache ne
peut/doit pas atteindre.
J'y comprends pas plus ... mais c'est pô grave.
Je suis obligé donc d'utiliser un "readfile" par PHP pour envoyer les
données au navigateur, d'où l'usage des "header".
M'enfin ?
en php y a pas moyen de reader les fichiers dans une instruction php
au milieu de l'embed ? au lieu de header à tous vas ?
> Heu, j'y comprends rien en histoires d'en tête et de trucs
je ne veux rien cacher, mais je dois pouvoir envoyer ces sons vers le navigateur alors qu'ils se trouvent dans un dossier qu'Apache ne peut/doit pas atteindre.
J'y comprends pas plus ... mais c'est pô grave.
Je suis obligé donc d'utiliser un "readfile" par PHP pour envoyer les données au navigateur, d'où l'usage des "header".
M'enfin ? en php y a pas moyen de reader les fichiers dans une instruction php au milieu de l'embed ? au lieu de header à tous vas ?
> Safari le respecte si la ressource est donnée par une url, mais pas > lorsqu'elle provient d'un readfile de php....
ça y est, j'ai trouvé : il faut entourer le <embed> par le <object> de QT.
Ah ? c'est donc ça ton Pb ? Oui, il me semble bien que pour les QT récents et sur PC l'object soit indispensable. (encore que ... pour du aif ???)
Sinon, voir aussi l'option *qtsrc* qui forcerait vers un autre lien : <embed src="uneZick.aif" controller=true height width0 qtsrc="http://www.url.non.connue/apache/sample2.mov" autoplayúlse>
Théoriquement, et à ce que j'ai compris, uneZick.aif ne serait alors pas joué, au profit de ce qu'indiqué par le qtsrc. et si toutefois ton php sait écrire une url ?
Un peu de doc ? (en US of course!) 645 ko : http://developer.apple.com/documentation/QuickTime/PDF/QuickTime41.pdf 1,2 Mo : http://developer.apple.com/documentation/QuickTime/QT6WhatsNew/qt6_new6.pdf
> Safari le respecte si la ressource est donnée par une url, mais pas
> lorsqu'elle provient d'un readfile de php....
ça y est, j'ai trouvé : il faut entourer le <embed> par le <object> de
QT.
Ah ? c'est donc ça ton Pb ?
Oui, il me semble bien que pour les QT récents et sur PC l'object soit indispensable.
(encore que ... pour du aif ???)
Sinon, voir aussi l'option *qtsrc* qui forcerait vers un autre lien :
<embed src="uneZick.aif" controller=true height width0
qtsrc="http://www.url.non.connue/apache/sample2.mov" autoplayúlse>
Théoriquement, et à ce que j'ai compris, uneZick.aif ne serait alors
pas joué, au profit de ce qu'indiqué par le qtsrc.
et si toutefois ton php sait écrire une url ?
Un peu de doc ? (en US of course!)
645 ko :
http://developer.apple.com/documentation/QuickTime/PDF/QuickTime41.pdf
1,2 Mo :
http://developer.apple.com/documentation/QuickTime/QT6WhatsNew/qt6_new6.pdf
> Safari le respecte si la ressource est donnée par une url, mais pas > lorsqu'elle provient d'un readfile de php....
ça y est, j'ai trouvé : il faut entourer le <embed> par le <object> de QT.
Ah ? c'est donc ça ton Pb ? Oui, il me semble bien que pour les QT récents et sur PC l'object soit indispensable. (encore que ... pour du aif ???)
Sinon, voir aussi l'option *qtsrc* qui forcerait vers un autre lien : <embed src="uneZick.aif" controller=true height width0 qtsrc="http://www.url.non.connue/apache/sample2.mov" autoplayúlse>
Théoriquement, et à ce que j'ai compris, uneZick.aif ne serait alors pas joué, au profit de ce qu'indiqué par le qtsrc. et si toutefois ton php sait écrire une url ?
Un peu de doc ? (en US of course!) 645 ko : http://developer.apple.com/documentation/QuickTime/PDF/QuickTime41.pdf 1,2 Mo : http://developer.apple.com/documentation/QuickTime/QT6WhatsNew/qt6_new6.pdf
quelle différence y a-t-il entre utiliser les Alias de Apache et utiliser les ln symb. unix pour faire cela (car les 2 fonctionnent) ?
Fonctionnellement il n'y en a pas. Après, tout dépend de tes impératifs de sécurité et de production.
Par exemple, si tu configures ton Apache pour qu'il ne suive pas les liens symboliques pour des raisons de sécurité, alors la méthode par lien symbolique de fonctionne plus.
Inversement, si tu veux pouvoir bouger tes fichiers de répertoire sans avoir à relancer ton demon (risque d'interruption de service, nécessité d'être root, etc.), alors les liens symboliques sont plus souples.
Voilà
Laurent
Julien Gautier wrote:
(...)
Petite question complémentaire, si tu veux bien :
quelle différence y a-t-il entre utiliser les Alias de Apache et
utiliser les ln symb. unix pour faire cela (car les 2 fonctionnent) ?
Fonctionnellement il n'y en a pas.
Après, tout dépend de tes impératifs de sécurité et de production.
Par exemple, si tu configures ton Apache pour qu'il ne suive pas les
liens symboliques pour des raisons de sécurité, alors la méthode par
lien symbolique de fonctionne plus.
Inversement, si tu veux pouvoir bouger tes fichiers de répertoire sans
avoir à relancer ton demon (risque d'interruption de service, nécessité
d'être root, etc.), alors les liens symboliques sont plus souples.
quelle différence y a-t-il entre utiliser les Alias de Apache et utiliser les ln symb. unix pour faire cela (car les 2 fonctionnent) ?
Fonctionnellement il n'y en a pas. Après, tout dépend de tes impératifs de sécurité et de production.
Par exemple, si tu configures ton Apache pour qu'il ne suive pas les liens symboliques pour des raisons de sécurité, alors la méthode par lien symbolique de fonctionne plus.
Inversement, si tu veux pouvoir bouger tes fichiers de répertoire sans avoir à relancer ton demon (risque d'interruption de service, nécessité d'être root, etc.), alors les liens symboliques sont plus souples.
