I've reproduced it with the Java client as well,
I guess in your case you can try to make sure ZIP has already been
generated by the time it's requested.
Not sure how to fix that, may be close the connection somehow at the
server side, if the exception is reported after the write started, Dan,
what do you think ?
Sergey
On 16/10/17 14:43, MULLER, Anthony wrote:
Right, this exception is not seen at all by web browsers... The client received
a corrupted ZIP archive. No error is pop-up :-/
That's why I'm wondering if there is any ways to indicate this case, though
protocols.
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: lundi 16 octobre 2017 11:50
To: [email protected]
Subject: Re: JAX-RS Interrupt StreamingOutput
Hi Anthony
And in the browser case this exception is not recognized/seen at all ?
What I'm trying to say, is that if, in the Java client case, it is
recognized then then browser should also be well capable of reporting
the error, and thus preventing the user downloading a corrupted Zip file
without having no notification something went wrong.
Sergey
On 16/10/17 10:41, MULLER, Anthony wrote:
Hi Sergey,
The server throws an exception when there is an issue during the ZIP generation.
Anthony
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: lundi 16 octobre 2017 11:15
To: [email protected]
Subject: Re: JAX-RS Interrupt StreamingOutput
Hi,
How does the JAX-RS server code react when it sees some issue, does it
throw some exception ?
Sergey
On 16/10/17 10:05, MULLER, Anthony wrote:
Hi Sergey,
Thank you very much for your reply!
The point here is that the client isn't a Java application, but a Web browser
for instance (like Chrome).
Best regards,
Anthony
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: lundi 16 octobre 2017 10:38
To: [email protected]
Subject: Re: JAX-RS Interrupt StreamingOutput
Hi Anthony
AFAIK the status goes first with the 1st write, so there's really no way
to replace it with something else if there was an error later on while
writing the stream.
I don't think so the fact a client gets 200 and then, presumably,
IOException, is inconsistent, the client code reading the data directly
from the input stream always has a catch for IOException, it can be
thrown even if there were no errors on the server side when writing it...
Sergey
On 13/10/17 12:30, MULLER, Anthony wrote:
Hello,
I have a REST call which returns a generated ZIP output. But during generation,
an issue may occurred... However, the client seems to receive a HTTP code 200
with a corrupted ZIP.
Is it possible to do better? Is this case managed by HTTP protocol? By CXF?
Best regards,
Anthony
