There are various compromises that you can make instead, including
checking to
see if the whole file at least made it out of your catalyst app (by
having
your filehandle monitor that for you). You can also give the user a good
amount of time to download the file as many times as he
Jonathan Rockway wrote:
On Sunday 11 March 2007 21:18, Jeff Chimene wrote:
Jonathan Rockway wrote:
On Sunday 11 March 2007 20:59, Jeff Chimene wrote:
How does that differ from something that compares bytes sent to bytes
received? Assuming that the OP defines success when bytes
Since we haven't heard from the OP. I have two questions:
o Did you investigate sendfile?
Sendfile() buys you nothing relevant to the OP's question.
o Have you considered implementing a download progress indicator? One of
the reasons users give up on downloads is that they don't know
On Mon, 12 Mar 2007, [EMAIL PROTECTED] wrote:
2, where download app continues download even if you leave the page/site
that started it
This is normal behavior. In Firefox, at least, once you start downloading
the file, that's a separate request, unrelated to the page where I started
the
Hi Thomas,
Check out the code associated with the 2006 advent calendar entry
entitled 'streaming mp3s with Catalyst'
http://www.catalystframework.org/calendar/2006/15
It's a little more involved, in that it handles 'range' requests -
but the main portion of the mp3 sending should work for you,
Hi!
On Mon, Mar 12, 2007 at 01:21:45PM -0500, [EMAIL PROTECTED] wrote:
your webapp does not get you past this problem. A simple, smart and quite
frankly the industry standard solution is to allow the user to try again on
failure.
So I need to figure out if there was I failure. Which I did
[EMAIL PROTECTED] wrote:
Since we haven't heard from the OP. I have two questions:
o Did you investigate sendfile?
Sendfile() buys you nothing relevant to the OP's question.
Really? The OP was merely detecting whether or not the session aborted,
not whether or not the
Here's a worst-case scenario you send it to IE and somewhere along the
line it picks up a Vary header.
IE won't store anything in it's cache with a Vary header - not even
downloaded files. So it downloads the file then deletes it.
You can't save it elsewhere or retrieve it!
On Sunday 11 March 2007 09:26, Thomas Klausner wrote:
But how do I figure out if the download was successfull? I didn't find
anything in the docs (but a RTFM-answer is appreciated, if I missed the
right piece of codocumentation).
You probably want a subclass of IO::File that will callback into
Jonathan Rockway wrote:
On Sunday 11 March 2007 09:26, Thomas Klausner wrote:
But how do I figure out if the download was successfull? I didn't find
anything in the docs (but a RTFM-answer is appreciated, if I missed the
right piece of codocumentation).
You probably want a subclass of
On Sunday 11 March 2007 20:59, Jeff Chimene wrote:
How does that differ from something that compares bytes sent to bytes
received? Assuming that the OP defines success when bytes received =
bytes sent
How do you determine how many bytes were received and successfully written to
disk?
--
Jonathan Rockway wrote:
On Sunday 11 March 2007 20:59, Jeff Chimene wrote:
How does that differ from something that compares bytes sent to bytes
received? Assuming that the OP defines success when bytes received =
bytes sent
How do you determine how many bytes were received and
Jonathan Rockway wrote:
On Sunday 11 March 2007 20:59, Jeff Chimene wrote:
How does that differ from something that compares bytes sent to bytes
received? Assuming that the OP defines success when bytes received =
bytes sent
How do you determine how many bytes were received and
On Sunday 11 March 2007 21:18, Jeff Chimene wrote:
Jonathan Rockway wrote:
On Sunday 11 March 2007 20:59, Jeff Chimene wrote:
How does that differ from something that compares bytes sent to bytes
received? Assuming that the OP defines success when bytes received =
bytes sent
How do
14 matches
Mail list logo
