Response with an invalid content type hangs when using WebFlux with Jetty

[wilkinsona]

Affects: 5.1.9

I discovered this while adding a test for spring-projects/spring-boot#18027 that covered all of Boot's reactive web servers. I've tried to reproduce it in a small standalone example but didn't manage to do so. Sorry. It can be reproduced by moving this test to the superclass and then running JettyReactiveWebServerFactoryTests. You should see the block time out after 30 seconds.

[rstoyanchev]

I see the following output:

2019-09-11 17:45:20.027 TRACE ${sys:PID} --- [tp2017797638-18] _.s.h.s.r.AbstractListenerReadPublisher  : [7543329c] onAllDataRead
2019-09-11 17:45:20.027 TRACE ${sys:PID} --- [tp2017797638-18] .s.r.AbstractListenerWriteFlushProcessor : [7543329c] Received request to cancel
2019-09-11 17:45:20.027 TRACE ${sys:PID} --- [tp2017797638-18] .s.r.AbstractListenerWriteFlushProcessor : [7543329c] Received onComplete
17:45:20.027 [qtp2017797638-18] WARN org.eclipse.jetty.server.HttpChannelState - java.lang.IllegalStateException: UNSUBSCRIBED while invoking onComplete liste
ner org.springframework.http.server.reactive.ServletServerHttpResponse$ResponseAsyncListener@9163a1
17:45:20.028 [qtp2017797638-18] DEBUG org.eclipse.jetty.server.HttpChannelState - 
java.lang.IllegalStateException: UNSUBSCRIBED
        at org.springframework.http.server.reactive.AbstractListenerWriteFlushProcessor$State.onComplete(AbstractListenerWriteFlushProcessor.java:378)
        at org.springframework.http.server.reactive.AbstractListenerWriteFlushProcessor.onComplete(AbstractListenerWriteFlushProcessor.java:127)
        at org.springframework.http.server.reactive.ServletServerHttpResponse$ResponseAsyncListener.onComplete(ServletServerHttpResponse.java:237)
        at org.eclipse.jetty.server.HttpChannelState$4.run(HttpChannelState.java:906)
        at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1392)
        at org.eclipse.jetty.server.HttpChannelState.runInContext(HttpChannelState.java:1134)
        at org.eclipse.jetty.server.HttpChannelState.onComplete(HttpChannelState.java:923)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:522)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
        at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918)
        at java.lang.Thread.run(Thread.java:748)

I think the issue is we're making an implicit assumption in the Servlet to Reactive Streams bridge that there won't be an onComplete signal before there is a subscriber which happens right after handling. However if handling happens immediately in the same thread and gets as far as writing which in turn causes an issue, we may get an error or completion notification from the Servlet AsyncListener even before the actual subscribe. So we need to anticipate that and not raise the above ISE.

[rstoyanchev]

The real reason turned out to be that when Content-Length is set, it is reflected right away since we delegate from HttpHeaders to the Jetty response headers through an adapter. However later in JettyServerHttpResponse#applyHeaders we run into an error when parsing the media type which leads to Jetty setting the response to 500 and completing , but the content-length is still set and so the client hangs.