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:sberyoz...@gmail.com] Sent: lundi 16 octobre 2017 11:50 To: users@cxf.apache.org 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:sberyoz...@gmail.com] > Sent: lundi 16 octobre 2017 11:15 > To: users@cxf.apache.org > 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:sberyoz...@gmail.com] >> Sent: lundi 16 octobre 2017 10:38 >> To: users@cxf.apache.org >> 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 >>>
