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!
http://support.
> [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,
> no
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
Hi!
On Mon, Mar 12, 2007 at 10:11:18AM -0500, [EMAIL PROTECTED] wrote:
> I agree with the above advice, you may also note that if you are charging
> for the downloads there may be legal/accounting reasons for this method
> (that almost all electronic delivery systems use). Technically, if you
Hi!
On Mon, Mar 12, 2007 at 02:56:51PM -0500, Jay K wrote:
> Check out the code associated with the 2006 advent calendar entry
> entitled 'streaming mp3s with Catalyst'
>
> http://www.catalystframework.org/calendar/2006/15
Thanks, I'll take a look at this.
> As an aside - I don't know what you
[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 file succes
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,
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 down
> 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
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
> 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
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"
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 succe
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 succe
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 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 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 in
Thomas Klausner wrote:
Hi!
On Sun, Mar 11, 2007 at 03:26:13PM +0100, Thomas Klausner wrote:
Now, using Catalyst (on mod_perl 2.x), I'm doing this to send the file:
$c->res->body( $fh );
This was maybe a bit to short:
my $fh = IO::File->new( $full_path, 'r' );
if ( define
Hi!
On Sun, Mar 11, 2007 at 03:26:13PM +0100, Thomas Klausner wrote:
> Now, using Catalyst (on mod_perl 2.x), I'm doing this to send the file:
>
> $c->res->body( $fh );
This was maybe a bit to short:
my $fh = IO::File->new( $full_path, 'r' );
if ( defined $fh ) {
binmode $fh;
Hi!
I need to figure out if a user aborted a longish download. (some background:
Users can download a limited amount of mp3s. If the download doens't work for
some reason, they must not be "charged")
In our old plain mod_perl 1.x handlers, I had something like:
$r->send_fd($fh);
i
20 matches
Mail list logo
