You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Steffen Heil (Mailinglisten)" <li...@steffen-heil.de> on 2016/06/01 21:14:59 UTC
AW: How to cancel download on the server side
Hi
> We had a similar problem. We just added a "preparation" step before the actual download.
>
> 1. User clicks on "request download" link 2. jQuery sends a request to servlet and instructs it to prepare the download 3. Meanwhile
> the request download link has been changed with Javascript to "preparing download..."
> 4. jQuery periodically asks the servlet if the download is ready or if the preparation has failed 5. If it is ready, the "preparing
> download..." is replaced by "download file" - if it has failed, an error message would be displayed
>
> This of course will only work if the client supports Javascript. But even if it doesn't you can work with HTTP reloads and/or redirects
> and using unique IDs to identify your client and their download.
Yes, we thought about that. However it still leaves the problem of a lot of storage on the server that is used for no reason and increasing the time to download the backup..
Regards,
Steffen
Re: How to cancel download on the server side
Posted by Olaf Kock <to...@olafkock.de>.
Am 03.06.2016 um 15:51 schrieb Steffen Heil (Mailinglisten):
> NO. We want to stream the results to the client... It usually is
> several times bigger than the memory at hand.
I can think of three options right now:
* Know the content-length upfront (which you don't) - with that clients
could detect incomplete downloads.
* If you're in control of the application that processes the download,
tag some bytes to the end that clearly mark the file as valid (or
invalid) and check for these marker's presence or nonpresence before
processing the file
* Process a hash or signature during transmission (server side) and
store it - this way the file can be validated later and you only need to
store a small hash value on the server once the download has completed.
However, when you don't store the file temporarily, you also can't
continue the download after a network failure (e.g. after partial
download) - if that's not an issue for you: fine. If you're sending it
through a public network that might fail, you might want to be prepared
for such an event and be able to recover. I'd expect disk space (esp.
temporarily) to not be too prohibitive (you can start streaming while
you store the file to disk on the server)
Hope it helps,
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: AW: How to cancel download on the server side
Posted by "Steffen Heil (Mailinglisten)" <li...@steffen-heil.de>.
Hi
> > Yes, we thought about that. However it still leaves the problem of a
> > lot of storage on the server that is used for no reason and increasing
> > the time to download the backup..
> So it's better to buffer the huge download in memory instead of on the disk? Maybe I don't understand the use case.
NO.
We want to stream the results to the client...
It usually is several times bigger than the memory at hand.
> It sounds like Mark may have a solution for you in another branch of this thread, anyway.
Did I miss a message on the list? So far I only got his question about the tomcat version...
Regards,
Steffen
Re: AW: How to cancel download on the server side
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Steffen,
On 6/1/16 5:14 PM, Steffen Heil (Mailinglisten) wrote:
> Hi
>
>
>> We had a similar problem. We just added a "preparation" step
>> before the actual download.
>>
>> 1. User clicks on "request download" link 2. jQuery sends a
>> request to servlet and instructs it to prepare the download 3.
>> Meanwhile the request download link has been changed with
>> Javascript to "preparing download..." 4. jQuery periodically asks
>> the servlet if the download is ready or if the preparation has
>> failed 5. If it is ready, the "preparing download..." is replaced
>> by "download file" - if it has failed, an error message would be
>> displayed
>>
>> This of course will only work if the client supports Javascript.
>> But even if it doesn't you can work with HTTP reloads and/or
>> redirects and using unique IDs to identify your client and their
>> download.
>
> Yes, we thought about that. However it still leaves the problem of
> a lot of storage on the server that is used for no reason and
> increasing the time to download the backup..
So it's better to buffer the huge download in memory instead of on the
disk? Maybe I don't understand the use case. It sounds like Mark may
have a solution for you in another branch of this thread, anyway.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXUKKIAAoJEBzwKT+lPKRYOrQQALxoXRHWrb52PUU8tbrPdb2B
H6lyk/6NN3m8hF0bKSyBq7RJhP6gTpQhavG9QtUSUUmAr6pOJsQBBzS3L0+LkH0W
K2Zxu93U93SZtPszn3odu7mRighu0IYZ4HB3T+SXC6ThZSM7MzNoW+6FXpT6hdCh
+S7aGV5LyqryVfOzYETLXbyqEbpBlIe/Ejt0IAOaJ5ylUa/nZ++aIEDJmV0IXyGP
EIHir248L7Lh7YTLuS1hXs5MxgLxwCX2+MwN/TPGKyb+Z0kF1gfJIBbpSa0mC8rt
zi0V/9nPKjaPGGBxk8IYgnfpRnFRbU1LeSltN+WKG312IcFsAQVum0lBhbe7WFRj
Jc9OrMXU4QTuJW+9Bdm+i4lBTAsu5o2SbCjWo8mec07HGQ1bafXKCTwP0hXjuW1K
uGpbOO3/At/8ZaS1K8wPGOSh+QhcBJA0k2FYdpLiKt77k/PtzAoEOXRn/x30d0WZ
MzXarFuQZZvytU6bl67Brcq19Krz+XRpsWdJ1euTZtFWjCiY21aVdyyoWQ5+E+6f
1s3KYmdu0zyLpfwVJKD1fC8B5bx8mUTdzU8UEBILJkxC8JQ+DUc79eMSzBZP5s/G
aT0tYrGmeNPbrAgzHW0JMeTUbsRgWOrl9bFfpMP1NahxA0ofZVI+Qk3PQSrDwtc1
JKKpkTspXNsaH0TdWUvs
=uvUg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org