Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty entity should set Content-Length header #4213

Closed
bursauxa opened this issue Jan 12, 2023 · 0 comments · Fixed by #4214
Closed

Empty entity should set Content-Length header #4213

bursauxa opened this issue Jan 12, 2023 · 0 comments · Fixed by #4214
Labels

Comments

@bursauxa
Copy link
Contributor

When a Play application running on akka-http returns status 205 Reset Content, some clients hang with this response and just wait for it to complete, even though the server considers it is complete and will never send any further data. I have encountered the issue with the following clients: play-ws-standalone (with underlying Netty-based AHC), Apache Commons http-client, and curl in command line. Some clients do not hang and immediately consider the request complete, such as Chrome or Firefox browsers.

It has to do with the fact that the response has no body (which is correct, as mandated by RFC for status 205), and no indication of content length to explicitly say that there is no body. That last part is incorrect behavior according to RFC 7231 section 6.3.6:

Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate a payload in a 205 response. In other words, a server MUST do one of the following for a 205 response: a) indicate a zero-length body for the response by including a Content-Length header field with a value of 0; b) indicate a zero-length payload for the response by including a Transfer-Encoding header field with a value of chunked and a message body consisting of a single chunk of zero-length; or, c) close the connection immediately after sending the blank line terminating the header section.

It seems the HTTP clients I've identified, do rely on this requirement stated by RFC. Testing with servers that add the Content-Length: 0 header, they work as expected. Also, they may eventually work if the server reaches its connection timeout before the client does, and thus closes the connection (which is a valid way to complete the response as seen from the client).

I found an earlier mention of this issue in 2021 on Gitter but it seems to not have been followed through.

Credit to Ben Fradet for identifying the same issue with Tomcat in 2017; I shamelessly copy-pasted half of his issue on the Apache tracker over here.

bursauxa pushed a commit to bursauxa/akka-http that referenced this issue Jan 12, 2023
bursauxa added a commit to bursauxa/akka-http that referenced this issue Jan 12, 2023
bursauxa added a commit to bursauxa/akka-http that referenced this issue Jan 12, 2023
bursauxa added a commit to bursauxa/akka-http that referenced this issue Jan 13, 2023
bursauxa added a commit to bursauxa/akka-http that referenced this issue Jan 13, 2023
bursauxa added a commit to bursauxa/akka-http that referenced this issue Jan 13, 2023
bursauxa added a commit to bursauxa/akka-http that referenced this issue Jan 13, 2023
bursauxa added a commit to bursauxa/akka-http that referenced this issue Jan 13, 2023
bursauxa added a commit to bursauxa/akka-http that referenced this issue Jan 13, 2023
@johanandren johanandren added the bug label Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants