Json object streaming slow through tunnel

I have been developing a Spring Boot application using reactor which returns a stream of json objects with content-type application/x-ndjson. The font-end is also served by the spring boot application and is just a html page with json (fetch) that calls the endpoint and populate a table with the json objects.

This works fine when hitting the application directly. The application returns about 20 objects over 15 seconds, with the first one being displayed very soon after the endpoint have been called, with more objects coming right after.

But when I have the service behind a Cloudflare tunnel, then it acts very differently. The first batch of objects won’t “arrive” (inspecting in chrome with F12 also confirm this) until after all 20 objects are ready or almost all of them. So what should have been a “continuously” updating table of objects over 15 seconds, updates just once after 15 seconds.

Another difference which I am not sure about has something to do with tunnels is that the json can be split over in the middle of an object. Using the service directly I would also get atleast a full/correct json object like {“foo”:1, “bar”:2}. But using the tunnel it might be split in two like:
part 1: {“foo”:1, “b
part 2: ar”:2

I just worked around this issue in the javascript client.
My application returns something looking like this:

@GetMapping(path = "/messages", produces = MediaType.APPLICATION_NDJSON_VALUE)
public ƒlux<Message> messages() { //I can't spell the object since it's an illegal word when posting to cloudflare community
    return messageService.getMessages();

I have been looking at ingress rules to see if there was anything I was missing from my Cloudflare configuration, but couldnt find anything that seems to indicate it could solve my problem https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/local-management/ingress/
my tunnel config:

    image: cloudflare/cloudflared:2022.5.1
    container_name: cloudfare_tunnel
    restart: always
      - ~/Documents/cloudflare/config:/home/nonroot/.cloudflared/
    command: tunnel run

#config file
url: http://host.docker.internal:8090
tunnel: UUID
credentials-file: /home/nonroot/.cloudflared/UUID.json

I was inspecting the request and response headers with F12 in Chrome.
I noticed that connecting directly to the application it have the following:
Request headers
Connection: keep-alive
Response headers:
Connection: keep-alive
Transfer-encoding: chunked
Keep-alive: timeout=60

But when inspect network through the tunnel then those headers are not there.
I have been testing with two domains, one of them is https://www.throwaway-awdjgyju2.tk

Any help is appreciated and thanks in advance.

I have had a change to investigate a bit further:
I activated debug log in the tunnel and the log prints this out:

Response Headers map[Connection:[keep-alive] Content-Type:[application/x-ndjson] Date:[Wed, 01 Jun 2022 18:04:57 GMT] Keep-Alive:[timeout=60]]

“Connection” and “Keep-Alive: timeout” is not in the response once I use the network tab in chrome.

Just to clarify my original post. The issue which I am looking to solve is the “slow” delivery of the first batch of the json. The fact that it sometimes get split up is not really a problem, since it have been solved in the javascript frontend.

I tried switching to a nginx as reverse proxy stilling using Cloudflare with proxying and Cloudflare certificates.

The issue was completely identical. In nginx I disabled buffering with

proxy_buffering off;

That solved the issue completely.
I would still prefer to use Cloudflare tunnel, and I suspect the issue is the same. But I can’t find any way ti disable buffering.
Anyone know how to disasble buffering with Cloudflare tunnel?

This might be something to bring on the Cloudflared repo

I look thru the issues and found one from 2020 with the same problem as me that seems to be unsolved:

Might open a new issue regarding the problem.
Thanks for the idea!

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.