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/05/29 18:08:15 UTC
How to cancel download on the server side
Hi
I am streaming a huge file from a servlet to the browser.
It can easily be multiple gigabytes.
Currently the data is prepared on the server, stored in a file and then sent to the client with a "Content-Disposition: attachment" header, so the browser handles it as a download. After the transfer the file is immediately deleted.
This kind of works but has two big disadvantages:
1. The client has to wait a long time until the first byte is transferred. I am afraid I could run into browser (or generic client) timeouts.
2. I need a lot of storage on the server.
The data I have could easily be streamed directly to the client without storing it on the server at all.
I would not know the precise size of the data In advance, but it could be transferred using "Transfer-Encoding: junked" so this would not be a problem.
My problem is that if anything goes wrong while creating the data I have no way to notify the client, as the response headers were already sent way before.
So I am looking for a way to cancel the download from the server side and letting the client know that something went wrong.
Simply stopping sending data is not enough, the client needs to know that the data is incomplete.
Probably the only way to do that would be to abruptly disconnect the http(s) connection without completing the download using a "0\r\n" end marker.
So my questions are:
1. How can I force tomcat to disconnect a client like that?
2. Does anyone here have tried anything like that before? What client side reactions did you notice?
Best 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
AW: How to cancel download on the server side
Posted by "Steffen Heil (Mailinglisten)" <li...@steffen-heil.de>.
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 Sebastian Trost <se...@dms-ag.ch>.
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.
Best Refards
Sebastian Trost
-----Original Message-----
From: Steffen Heil (Mailinglisten) [mailto:lists@steffen-heil.de]
Sent: Sunday, May 29, 2016 8:08 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: How to cancel download on the server side
Hi
I am streaming a huge file from a servlet to the browser.
It can easily be multiple gigabytes.
Currently the data is prepared on the server, stored in a file and then sent to the client with a "Content-Disposition: attachment" header, so the browser handles it as a download. After the transfer the file is immediately deleted.
This kind of works but has two big disadvantages:
1. The client has to wait a long time until the first byte is transferred. I am afraid I could run into browser (or generic client) timeouts.
2. I need a lot of storage on the server.
The data I have could easily be streamed directly to the client without storing it on the server at all.
I would not know the precise size of the data In advance, but it could be transferred using "Transfer-Encoding: junked" so this would not be a problem.
My problem is that if anything goes wrong while creating the data I have no way to notify the client, as the response headers were already sent way before.
So I am looking for a way to cancel the download from the server side and letting the client know that something went wrong.
Simply stopping sending data is not enough, the client needs to know that the data is incomplete.
Probably the only way to do that would be to abruptly disconnect the http(s) connection without completing the download using a "0\r\n" end marker.
So my questions are:
1. How can I force tomcat to disconnect a client like that?
2. Does anyone here have tried anything like that before? What client side reactions did you notice?
Best regards,
Steffen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: AW: AW: AW: How to cancel download on the server side
Posted by "Steffen Heil (Mailinglisten)" <li...@steffen-heil.de>.
Hi
> It is a dirty Tomcat specific trick that will only work as long as the code is the way it is but if you throw a ClientAbortException wrapped
> in a ServletException you shouldn't see that log message.
Thanks a lot, this was just what I was looking for.
Regards,
Steffen
Re: AW: AW: AW: How to cancel download on the server side
Posted by Mark Thomas <ma...@apache.org>.
On 03/06/2016 22:08, Steffen Heil (Mailinglisten) wrote:
> Hi
>
>
>> throw new ServletException();
>
> That was the difference. I threw a IllegalStateException(), so tomcat sent "0\r\n".
> I changed my code to throw a ServletException() and now it works.
> Thanks for that.
>
>
> One very little thing left: Is there a way to suppress the logged exception:
It is a dirty Tomcat specific trick that will only work as long as the
code is the way it is but if you throw a ClientAbortException wrapped in
a ServletException you shouldn't see that log message.
> Jun 03, 2016 11:00:18 PM org.apache.catalina.core.StandardWrapperValve invoke
> SCHWERWIEGEND: Servlet.service() for servlet [Stream] in context with path [] threw exception [null] with root cause
> javax.servlet.ServletException
<snip/>
> BTW: Why does it say "exception [null]"?
Because the exception was created with a null message.
> As I regard closing a connection a valid result of processing a request, I would have expected a way to cleanly terminate a connection without logging a severe exception.
The general expectation is that the connection is only closed if the
container code encounters an error and the typical cause for that
(ClientAbortException) doesn't generate the error. Anything else is
unexpected and triggers the logging.
The Servlet specification didn't anticipate an application being in a
position to decide to forcibly close the connection.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: AW: AW: How to cancel download on the server side
Posted by "Steffen Heil (Mailinglisten)" <li...@steffen-heil.de>.
Hi
> throw new ServletException();
That was the difference. I threw a IllegalStateException(), so tomcat sent "0\r\n".
I changed my code to throw a ServletException() and now it works.
Thanks for that.
One very little thing left: Is there a way to suppress the logged exception:
Jun 03, 2016 11:00:18 PM org.apache.catalina.core.StandardWrapperValve invoke
SCHWERWIEGEND: Servlet.service() for servlet [Stream] in context with path [] threw exception [null] with root cause
javax.servlet.ServletException
...
at com.osiris4.http.servlets.Stream.doRequest(Stream.java:36)
at com.osiris4.http.servlets.Base.service(Base.java:36)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1526)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1482)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
BTW: Why does it say "exception [null]"?
As I regard closing a connection a valid result of processing a request, I would have expected a way to cleanly terminate a connection without logging a severe exception.
Regards,
Steffen
Re: AW: AW: How to cancel download on the server side
Posted by Mark Thomas <ma...@apache.org>.
On 03/06/2016 15:14, Mark Thomas wrote:
> On 01/06/2016 23:08, Steffen Heil (Mailinglisten) wrote:
>>>> That's another story.
>>>> I tried that. And the internet explorer as well as curl report an error, if the download stops without the ending 0\r\n.
>>>>
>>>> But I had to set "Connection: close" and "Transfer-Encoding: chunked" myself and encode the chunk headers myself.
>>>> If I leave these two headers out, tomcat managed the transfer-encoding (as I set no Content-Length header) which I would prefer.
>>>> However then I find no way to close the connection. If I call "close()" on the OutputStream tomcat sends 0\r\n.
>>>> Even if I throw an exception, tomcat "correctly" closes the stream.
>>>> I did not find any way to close it without that.
>>>>
>>>> Is there any way to do so?
>>>
>>> Tomcat version?
>>
>> 8.0.26
>
> There was a change back in 8.0.9 that I thought addressed this. I need
> to do a little digging.
OK. I've confirmed that the fix back in 8.0.9 did what I thought it did
with a simple test.
The GET method of my test Servlet looks like this:
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/plain");
resp.setCharacterEncoding("UTF-8");
resp.getWriter().write("OK\n");
resp.flushBuffer();
resp.getWriter().write("OK\n");
resp.flushBuffer();
throw new ServletException();
}
The client receives a chunked response that looks like this:
HTTP/1.1 200
Content-Type: text/plain;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 03 Jun 2016 14:30:33 GMT
3
OK
<Connection closed here>
The client should be able to work out the response is incomplete because
there is no end chunk ("0\r\n\r\n"). There isn't much else Tomcat can
do. It can't change the headers because the response is committed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: AW: How to cancel download on the server side
Posted by Mark Thomas <ma...@apache.org>.
On 01/06/2016 23:08, Steffen Heil (Mailinglisten) wrote:
>>> That's another story.
>>> I tried that. And the internet explorer as well as curl report an error, if the download stops without the ending 0\r\n.
>>>
>>> But I had to set "Connection: close" and "Transfer-Encoding: chunked" myself and encode the chunk headers myself.
>>> If I leave these two headers out, tomcat managed the transfer-encoding (as I set no Content-Length header) which I would prefer.
>>> However then I find no way to close the connection. If I call "close()" on the OutputStream tomcat sends 0\r\n.
>>> Even if I throw an exception, tomcat "correctly" closes the stream.
>>> I did not find any way to close it without that.
>>>
>>> Is there any way to do so?
>>
>> Tomcat version?
>
> 8.0.26
There was a change back in 8.0.9 that I thought addressed this. I need
to do a little digging.
Mark
---------------------------------------------------------------------
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>.
> > That's another story.
> > I tried that. And the internet explorer as well as curl report an error, if the download stops without the ending 0\r\n.
> >
> > But I had to set "Connection: close" and "Transfer-Encoding: chunked" myself and encode the chunk headers myself.
> > If I leave these two headers out, tomcat managed the transfer-encoding (as I set no Content-Length header) which I would prefer.
> > However then I find no way to close the connection. If I call "close()" on the OutputStream tomcat sends 0\r\n.
> > Even if I throw an exception, tomcat "correctly" closes the stream.
> > I did not find any way to close it without that.
> >
> > Is there any way to do so?
>
> Tomcat version?
8.0.26
Steffen
Re: AW: How to cancel download on the server side
Posted by Mark Thomas <ma...@apache.org>.
On 01/06/2016 22:27, Steffen Heil (Mailinglisten) wrote:
> Hi
>
>
>> I believe that, while the HTTP specification supports what you want to do, neither servers nor clients support it. For example, you can
>> use "trailers" (headers end the end of the response) to tell the client what happened, but I suspect that no client will actually read
>> them or act on them.
>
> I did not even know such things exist.
> A quick google check seems to indicate that you are right: No real client supports them in a way usable for me.
>
>
>> You can always force a disconnect by simply closing the response stream. Usually, the client will either tell the user that the download
>> failed (connection closed before response - or chunk of response - completed), more likely just shows the user a blank page or saves
>> an incomplete file.
>
> That's another story.
> I tried that. And the internet explorer as well as curl report an error, if the download stops without the ending 0\r\n.
>
> But I had to set "Connection: close" and "Transfer-Encoding: chunked" myself and encode the chunk headers myself.
> If I leave these two headers out, tomcat managed the transfer-encoding (as I set no Content-Length header) which I would prefer.
> However then I find no way to close the connection. If I call "close()" on the OutputStream tomcat sends 0\r\n.
> Even if I throw an exception, tomcat "correctly" closes the stream.
> I did not find any way to close it without that.
>
> Is there any way to do so?
Tomcat version?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to cancel download on the server side
Posted by Bill Miller <mi...@gmail.com>.
Do you have the ability to have multiple client-server connections open? You could have a second channel to the server that can communicate the status to the client and when/if there is a problem indicate through that status channel that the download has been truncated. Not the greatest idea because it will require multiple connections to the server which could overload your server AND it may not be cluster friendly if that matters.
Bill
-----Original Message-----
From: Steffen Heil (Mailinglisten) [mailto:lists@steffen-heil.de]
Sent: Wednesday, June 01, 2016 5:28 PM
To: Tomcat Users List
Subject: AW: How to cancel download on the server side
Hi
> I believe that, while the HTTP specification supports what you want to do, neither servers nor clients support it. For example, you can
> use "trailers" (headers end the end of the response) to tell the client what happened, but I suspect that no client will actually read
> them or act on them.
I did not even know such things exist.
A quick google check seems to indicate that you are right: No real client supports them in a way usable for me.
> You can always force a disconnect by simply closing the response stream. Usually, the client will either tell the user that the download
> failed (connection closed before response - or chunk of response - completed), more likely just shows the user a blank page or saves
> an incomplete file.
That's another story.
I tried that. And the internet explorer as well as curl report an error, if the download stops without the ending 0\r\n.
But I had to set "Connection: close" and "Transfer-Encoding: chunked" myself and encode the chunk headers myself.
If I leave these two headers out, tomcat managed the transfer-encoding (as I set no Content-Length header) which I would prefer.
However then I find no way to close the connection. If I call "close()" on the OutputStream tomcat sends 0\r\n.
Even if I throw an exception, tomcat "correctly" closes the stream.
I did not find any way to close it without that.
Is there any way to do so?
Regards,
Steffen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: How to cancel download on the server side
Posted by "Steffen Heil (Mailinglisten)" <li...@steffen-heil.de>.
Hi
> I believe that, while the HTTP specification supports what you want to do, neither servers nor clients support it. For example, you can
> use "trailers" (headers end the end of the response) to tell the client what happened, but I suspect that no client will actually read
> them or act on them.
I did not even know such things exist.
A quick google check seems to indicate that you are right: No real client supports them in a way usable for me.
> You can always force a disconnect by simply closing the response stream. Usually, the client will either tell the user that the download
> failed (connection closed before response - or chunk of response - completed), more likely just shows the user a blank page or saves
> an incomplete file.
That's another story.
I tried that. And the internet explorer as well as curl report an error, if the download stops without the ending 0\r\n.
But I had to set "Connection: close" and "Transfer-Encoding: chunked" myself and encode the chunk headers myself.
If I leave these two headers out, tomcat managed the transfer-encoding (as I set no Content-Length header) which I would prefer.
However then I find no way to close the connection. If I call "close()" on the OutputStream tomcat sends 0\r\n.
Even if I throw an exception, tomcat "correctly" closes the stream.
I did not find any way to close it without that.
Is there any way to do so?
Regards,
Steffen
Re: How to cancel download on the server side
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Steffen,
On 5/29/16 2:08 PM, Steffen Heil (Mailinglisten) wrote:
> I am streaming a huge file from a servlet to the browser. It can
> easily be multiple gigabytes.
>
> Currently the data is prepared on the server, stored in a file and
> then sent to the client with a "Content-Disposition: attachment"
> header, so the browser handles it as a download. After the transfer
> the file is immediately deleted.
>
> This kind of works but has two big disadvantages: 1. The client has
> to wait a long time until the first byte is transferred. I am
> afraid I could run into browser (or generic client) timeouts. 2. I
> need a lot of storage on the server.
>
> The data I have could easily be streamed directly to the client
> without storing it on the server at all. I would not know the
> precise size of the data In advance, but it could be transferred
> using "Transfer-Encoding: junked" so this would not be a problem.
>
> My problem is that if anything goes wrong while creating the data I
> have no way to notify the client, as the response headers were
> already sent way before. So I am looking for a way to cancel the
> download from the server side and letting the client know that
> something went wrong. Simply stopping sending data is not enough,
> the client needs to know that the data is incomplete.
>
> Probably the only way to do that would be to abruptly disconnect
> the http(s) connection without completing the download using a
> "0\r\n" end marker.
>
> So my questions are: 1. How can I force tomcat to disconnect a
> client like that? 2. Does anyone here have tried anything like that
> before? What client side reactions did you notice?
I believe that, while the HTTP specification supports what you want to
do, neither servers nor clients support it. For example, you can use
"trailers" (headers end the end of the response) to tell the client
what happened, but I suspect that no client will actually read them or
act on them.
I don't think you really have an option, here, for transmitting a huge
file with graceful error-handling sometime in the middle of the
creation/transmission of the data.
You can always force a disconnect by simply closing the response
stream. Usually, the client will either tell the user that the
download failed (connection closed before response - or chunk of
response - completed), more likely just shows the user a blank page or
saves an incomplete file.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXSzkyAAoJEBzwKT+lPKRYapoP/i9pIzvWTCVrfvUrYErQagyC
QIshcEX/Sqw3AlLLMiSuhSjykdn2pyRwu1XlwnVS+pRP0g0C5orj8QiQNGHJKg6m
dBCUe5rwBnGSvILFJMM7Nbq9i8mHyDhU3hWctjFbCXwL/i+q9pRZr66DkS9F1Hya
7QiDnqIvckZ3iYNn2JySWPVYTwDP718o17ypX+zmPOjRkYr66h/Xvtv8I5bpChgM
96zt9oGXPt8WDaWfrFMuZZlDsW2E+E6LVHQNEBWNepOuw5aLn6TgyWReWNysaeBY
NV5t1bzLEC1iYKquOqOZcsRBRHx7ArKtAv1RUYvsqSUpqiysgiWfYOYCFEyBCrET
mG9T/88GIiqW6+lZwdzxB6r2VPEgpbhQV0Ufwp55YWbHUPJPICYAVyA3lAlEGcG/
1ES9TduGcOF0CHYLAKYQ0dYBaGCGW1YjTHZ/C0bGMG7T4l7w0N/nQ6RrYuoMWsOt
CnE8FuqyVzHX1qT4FSCqyRSUYC7cNu8YccMpjmTcyjmC5KeZYbUTIMP3iAOVD0Dl
rZ2HOBdlMSwqJtnr6h3MUqF7mBqkKjhmt19mpEeXibsGpXCjULRNFXw7FIS3ZLyV
NK7EXJIfitldyF5nsIuXRQamPkBTht82zORBwYyjPrLgeEYLHYpOW3ewK8wvcBNB
f7r/Gh1KuHucNJwDrirw
=SqNN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org