Jetty 12 should not use close-delimited message on HTTP/1.1 connections anymore (should be isolated to HTTP/1.0 connections only). about jetty.project HOT 8 OPEN

I believe Jetty does follow that. We make every effort to not use close delimitation. But in this case the client is asking for it and we are bound to follow that.

from jetty.project.

Checking the updated RFCs ...

in RFC9110 ...

https://datatracker.ietf.org/doc/html/rfc9110#section-6.1

A message is considered "complete" when all of the octets indicated
by its framing are available. Note that, when no explicit framing is 
used, a response message that is ended by the underlying connection's 
close is considered complete even though it might be 
indistinguishable from an incomplete response, unless a transport-
level error indicates that it is not complete.

And in RFC9112 ...

https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length

Since there is no way to distinguish a successfully completed, 
close-delimited response message from a partially received message interrupted
by network failure, a server SHOULD generate encoding or 
length-delimited messages whenever possible. The close-delimiting 
feature exists primarily for backwards compatibility with HTTP/1.0.

from jetty.project.

See https://datatracker.ietf.org/doc/html/rfc9112#name-tear-down, that shows that HTTP/1.1 still supports the connection:close semantic.
Now potentially we could also set a content-length as well as closing.

from jetty.project.

@gregw there's a reported demo project that can replicate this in Jetty 12 - https://github.com/techsup69/jetty-cont-len-12

from jetty.project.

See stackoverflow question for curl command line to trigger it - https://stackoverflow.com/questions/77822470/jetty-12-spring-6-missing-content-length-in-response

from jetty.project.

Hmmmm we do put the content length in even in the case of an EOF message... I'll respond in stackoverflow with some questions

from jetty.project.

Perhaps in the case of a forced Connection:close for HTTP/1.1 where the content-length is not known, then we could use chunking and connection:close. Feels like optimizing the slow/bad case.

from jetty.project.

Perhaps in the case of a forced Connection:close for HTTP/1.1 where the content-length is not known, then we could use chunking and connection:close. Feels like optimizing the slow/bad case.

I see the point of view of the users and the spec here. That the close-delimited response message IS the bad to horrible case for HTTP/1.1 use.

As the current HTTP/1.1 specs point out this close-delimited response message behavior is only for backward compatibility with HTTP/1.0, and its use in HTTP/1.1 discouraged in use as it is indistinguishable from a partially received response message that is interrupted by a network failure. The current specs use "SHOULD generate encoding or length-delimited messages whenever possible" as guidance.

from jetty.project.