Consistent error handling when streaming with servlet vs reactive stack [SPR-17440] #21972
Comments
Rossen Stoyanchev commented Indeed the asynchronous, streaming support in Spring MVC (e.g. SseEmitter, ResponseBodyEmitter) was created first and it's always behaved as it does now, i.e. flushing the status and headers before any items are emitted. The solution in WebFlux went further, and it had to, because async is the norm there and it's the only way for |
vrawat79 commented Actually, since we are returning a Flux, i.e. a series of events, wherein each event could have its own status, shouldn't we be returning a HTTP 207 as the overall response code. 400 as the overall status code will be mis-leading.
|
Rossen Stoyanchev commented The ResponseBodyEmitter (and SseEmitter) were designed for a stream of events (like SSE) and that's very different. The SSE spec has no reference to HTTP status 207 and I've never seen that status used for such purposes. We're only talking about the initial status before the stream actually begins emitting. From what I can see HTTP 207 is defined in WebDAV and that's a very specific thing for multiple operations or resources. |
Michal Domagala opened SPR-17440 and commented
Consider the following code:
In reactive stack initial exception has special treatment: class
ChannelSendOperator
has special state NEW: /** No emissions from the upstream source yet. */Due special treatment http response status for
/1
is 400 and for/2
is 200In servlet stack http response status for both endpoints is 200
Nice to have consistent implementation. Reactive stack way is correct one.
Affects: 5.0.10
Reference URL: https://stackoverflow.com/questions/53013088/how-to-peep-if-flux-has-exception
The text was updated successfully, but these errors were encountered: