You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kapilan A <ka...@triviumsys.com> on 2016/06/17 04:18:18 UTC

RE: mailto:users-unsubscribe@tomcat.apache.org

I would like to un-subscribe this.

Thanks for good support.

Regards
Kapilan A

-----Original Message-----
From: users-return-258027-kapilana=triviumsys.com@tomcat.apache.org [mailto:users-return-258027-kapilana=triviumsys.com@tomcat.apache.org] On Behalf Of Bill Miller
Sent: Wednesday, June 15, 2016 07:36 PM
To: 'Tomcat Users List' <us...@tomcat.apache.org>
Subject: RE: How to cancel download on the server side

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org