On August 10, 2021 8:00:45 AM UTC, Marcin Wisnicki <mwisni...@gmail.com> wrote:
>However I've noticed that in Tomcat the behaviour can only be achieved
>by throwing an exception before close.
>If I don't throw and simply return or call close before exception
>Tomcat will write terminal '0'.
>
>Is there a way to trigger immediate close without that write('0')
>without using exceptions?
No.
Return indicates the response is complete. Error conditions are indicated with
exceptions.
Mark
>
>On Tue, 10 Aug 2021 at 03:27, Marcin Wisnicki <mwisni...@gmail.com>
>wrote:
>>
>> Thanks, it seems like it must be one of Spring Boot's filters
>breaking
>> it. I should've tried without it first, mea culpa.
>> In a pure tomcat container it works as you described whereas with
>> Spring something inserts final 0 so the aborted connection looks like
>> a valid chunked response to clients.
>>
>> I'll move my question to a more appropriate forum.
>>
>> On Tue, 10 Aug 2021 at 02:45, Mark Thomas <ma...@apache.org> wrote:
>> >
>> > On 10/08/2021 02:25, Marcin Wisnicki wrote:
>> > > I have a servlet (it's really a SpringBoot controller but it
>shouldn't
>> > > matter?) in Tomcat 9.0.46 that streams responses of unknown size
>to
>> > > the browser.
>> > >
>> > > I've discovered that if the streaming process fails in the middle
>of
>> > > the write, the client will simply get an incomplete file and
>think it
>> > > was successful.
>> >
>> > Then you have a broken client.
>> >
>> > > Indeed there is no way to tell from the browser side there was an
>error.
>> >
>> > That statement is incorrect.
>> >
>> > > void doGet(HttpServletResponse resp) {
>> > > resp.setStatus(200);
>> > > resp.setHeader("Content-Disposition", "...");
>> > > resp.setContentType("application/octet-stream");
>> > > var out = resp.getOutputStream();
>> > > out.flush();
>> > > if (true) throw new RuntimeException("simulated error");
>> > > // status is already sent here, can't change it!
>> > > }
>> > >
>> > > As far as I can tell a web server should close connection with
>TCP RST
>> > > or write some garbage that's not a valid chunked response.
>> >
>> > You won't see a TCP RST. You will see invalid chunked encoding.
>> >
>> > > This is what some other servers do such as express.js.
>> > >
>> > > Unfortunately Tomcat does neither and also there seems to be no
>way to
>> > > trigger that using either Servlet or Tomcat api.
>> >
>> > Again, that statement is incorrect.
>> >
>> > > I've tested it by setting "Connection: close" then writing
>garbage and
>> > > it seems browser recognized download error.
>> > > But then I lose chunking in the output stream and can't actually
>write
>> > > a response.
>> > >
>> > > How do people solve it?
>> >
>> > Look at the following from a test using telnet to make a request to
>the
>> > sample servlet above:
>> >
>> > $ telnet localhost 8080
>> > Trying ::1...
>> > Connected to localhost.
>> > Escape character is '^]'.
>> > GET /tomcat-bugs/user004 HTTP/1.1
>> > Host: localhost
>> >
>> > HTTP/1.1 200
>> > Content-Type: text/plain
>> > Transfer-Encoding: chunked
>> > Date: Tue, 10 Aug 2021 06:38:06 GMT
>> >
>> > Connection closed by foreign host.
>> > $
>> >
>> > The headers are sent when the Servlet flushes the response. That is
>as
>> > required by the Servlet specification.
>> >
>> > What tells the client that the response is incomplete is that
>chunked
>> > encoding is being used but there is no final chunk.
>> >
>> > Mark
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
