Text responses are not chunked

[fedinskiy]

Describe the bug

I have an app with two almost identical http endpoints. One of them returns a text string, another — the same string, but wrapped in ByteArrayInputStream. When I use options quarkus.http.limits.max-chunk-size
and quarkus.rest.output-buffer-size, the second endpoint returns chunked responses, but the first one does not.

Expected behavior

Both responses are chunked, since the application has compression disabled and neither the original RFC[1] nor Quarkus documentation[2][3] mention any exceptions for text data.

[1] https://datatracker.ietf.org/doc/html/rfc9112#section-7.1
[2] https://quarkus.io/guides/http-reference
[3] https://quarkus.io/guides/rest

Actual behavior

The application/octet-stream response is chunked, the text/plain is not

How to Reproduce?

1. git clone -b chunking git@github.com:fedinskiy/reproducer.git && cd reproducer
2. mvn clean quarkus:dev
3. Check the streamed endpoint:

$ curl -i localhost:8080/stream | head -n 5
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1178    0  1178    0     0  89262      0 --:--:-- --:--:-- --:--:-- 90615
HTTP/1.1 200 OK
Content-Type: application/octet-stream
transfer-encoding: chunked

Hello no.1

4. Check the text endpoint:

$ curl -i localhost:8080/text | head -n 5
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1178  100  1178    0     0   172k      0 --:--:-- --:--:-- --:--:--  191k
HTTP/1.1 200 OK
Content-Type: text/plain;charset=UTF-8
content-length: 1178

Hello no.1

Output of uname -a or ver

6.16.4-200.fc42.x86_64

Output of java -version

Java version: 21.0.8, vendor: Eclipse Adoptium

Quarkus version or git rev

b1bb7ad

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.6

Additional information

No response

[fedinskiy]

Given, that tests in #49894 also wrap text into streams, I expect this behavior to be more or less intentional, but it would be greate to have it documented somewhere

[tusharrrr1]

Thanks for the detailed report and reproducer, @fedinskiy 🙌 — very helpful.

You’re right: Quarkus currently sends text/plain responses with a fixed Content-Length when the full response size is already known, whereas wrapping it in a stream leads to chunked transfer encoding. That’s why you’re seeing the difference between the two endpoints.

It does look like this is intentional for efficiency, but I agree that it isn’t clearly documented — especially since RFC 9112 doesn’t call out any exception for text responses. At the very least, we should clarify in the HTTP reference docs when Quarkus will use Content-Length vs. Transfer-Encoding: chunked.

Marking this for further discussion to decide whether:

this should be documented as expected behavior, or

we should consider aligning text/plain behavior with streaming endpoints for consistency.

[fedinskiy]

@tusharrrr1 thank you, your advice almost helped me to pinpoint the underlying issue! Unfortunately, to fix the issue I need a recipe for quark-filled crepes, could you write one?

[tusharrrr1]

Haha, nice one @fedinskiy 😄 A recipe might fix just one taste, but together we can cook up something much more meaningful here 🍳✨. How about I take up this issue and we collaborate to make sure the solution is both consistent and well-documented?