4.x: Return 500 when 204 with entity is sent from routing.

[tomas-langer]

Resolves #8348

Description

Fixed a problem when user returned 204 with an entity in JAX-RS.
With the default connector, the next (!) request would fail with Status code -1 (caused by the client ignoring the entity according to the specification, but then the connection was broken, and the next response started reading the previous entity).

The client could handle this more gracefully (i.e. close the connection, report the problem), but it is the default one in Java...

Updated solution:

• if an attempt is done to write entity with 204 status, the status is changed to 500, and everything else carries out as usual (as entity is allowed with 500). The server logs an error explaining the problem.

[tomas-langer]

I have validated the implementation in HttpUrlConnection - it expects that there is NOT an entity (it does some side check with Content-Length header, which is not used in our case, we just use chunked encoding).
So we must resolve this in Helidon.

[jbescos]

I have validated the implementation in HttpUrlConnection - it expects that there is NOT an entity (it does some side check with Content-Length header, which is not used in our case, we just use chunked encoding). So we must resolve this in Helidon.

Find here my findings about this: jakartaee/rest#1199 (comment)

You would need to read the whole inputstream when you receive 204, 205 or 304 and ignore the entity if exists. This is in the ideal case that the stream is flushed with headers and entity together.

[jbescos]

I am reviewing this further and I am having questions. Lets try to clarify that.

Is Http1ServerResponse#nonEntityBytes always invoked?. I think it is. When there is 204, 205 or 304 with an entity we should log a warning and don't write the entity rather than failing with 500 error in my opinion.

Also the helidon client will not be able to handle chunked 204, 205 or 304 with entity. This is the comment wrote here: #8357 (comment)