this is off the topic of caching, but is related and could have an
impact on the issue: using a .php instead of a .mp3 would seem like a
good idea, but this ties into a problem i'm having right now with
streaming mp3s using, in my case, the flash player plugin to stream and
play the file. it would seem that there is a *distinct difference*
between making a direct file request and making a request for a php file
that sends the same data. this perhaps has something to do with the way
apache/php handles the request? I can't come up with any other
explanation, and i'm not an expert on the behind-the-scenes end the
server-side applications. heres the unexplained difference: when
directly requesting an .mp3 file, the app (flash plugin) works fine.
when requesting a .php file that reads and sends the data from a file,
things still work but the plugin/browser cannot interrupt the operation
until the full file is downloaded - i.e., you can't click a link in the
page and go somewhere else until the stream is completely downloaded and
the php script is complete. the browser just sits there with its icon
spinning until all is finished, no links work until then. its very
weird. i am doing this just by using a fread() to a file handle and
echoing the result. any explanations, or enlightened thoughts on 1) why
this happens, and 2) how it could impact the differece between a direct
.mp3 embed and a .php embed?
josh whiting
Ivo Fokkema wrote:
Hi Tony,
Chris explained a lot about this... I'm not an expert on this, but you might
want to give a try to embed something like :
"<embed src='mp3.php?mp3=filename' autostart=true>";
And then let mp3.php send all of the no-cache headers together with the
contents of the filename.mp3.
It might work, I would give it a try...
HTH,
--
Ivo
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
