I don't see this is a Go project's issue.
Could you provide a more concise example in https://go.dev/play?

I don't see this is a Go project's issue. Could you provide a more concise example in https://go.dev/play?

Hi. Well, the issue only happens in browser clients. So data sent by the Go server is somehow corrupted along the way. I wouldn't be able to reproduce in a play env.

I'm not certain if this is a browser bug or something in the reverse proxy or net lib. But I can reproduce in different browsers, which led me to believe that the issue must be on the server side.

Is there something wrong with the details I've shared in that repo? Are you not able to reproduce?

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

https://github.com/transcelestial/echo-streaming-bug/blob/74b734755472389d5dac7d00aab1cc4da75f3c9f/cmd/client/main.go#L57-L61

	for {
		line, err := reader.ReadBytes('\n')
		if err != nil {
			log.Fatal(err)
		}

It appears that your client can't split messages correctly when your data/content contains \n.

@mengzhuo there may be an actual bug within one of the net libs. I would assume someone would help look into it. I'm not asking a question as to how to stream responses or read them as that's already done and working.

I'm experiencing an actual issue where the browser based clients do not receive the full data. I can look into it myself, I just need some guidance so that I know what to look for or where I should be looking.

I've already made some effort in trying to explain as best as I could how to reproduce. I would at least expect the same effort on your end to check it out and tell me with certainty that the issue is probably on the client side. I'm definitely aware this is an open source project and you or other contributors have no obligation to help, but if this is a bug, I'm sure you'd like to fix it at some point.

I would appreciate it if you didn't close this issue as I think it's relevant. For context, it's very similar to #27816.

The referenced client actually works just fine. I was unable to replicate the issue with it. So the issue seems to happen strictly when using a browser. So I wanted to verify that there's no issue on the server side and then report the bug in the appropriate channels for each browser where it happens.

Sure, This triage is based on my understanding of your code.
I will reopen it if you think it's a bug.

cc @neild net/http owner

Sure, This triage is based on my understanding of your code. I will reopen it if you think it's a bug.

cc @neild net/http owner

I appreciate that! Thank you! As mentioned, I'm more than happy to look into it if someone points me in the right direction.

我也遇到类似的情况。使用 rust 反向代理测试正常，但是使用 httputil 就会出错〜，模拟发送http请求也不行。像是go的 http 实现有问题或有默认的参数设置问题，目前找不到原因。

I've reported the issue at https://bugs.chromium.org/p/chromium/issues/detail?id=1305928 as well. I've also ran more tests just using net/http and net/http/httputil to see if the issue could be in echo, but I could still get failures.

So that leaves either the browsers or net/http (since I can get failures from net/http w/o using a proxy).

Given that this doesn't need a reverse proxy to reproduce, it doesn't look like an issue with net/http/httputil
Adding some extra logging, Go sends the output within a single write.
On the browser/js side, it's a data stream, and a single json message can be spread over 2 reads, eg I got:

{"pong":true,"reason":"the bug does not seem to be here :( where is it then? who knows? at this point, i have no clue! i'm lost 

and

now. i have no clue what to do. i need help. i don't know what i'm doing. where should i look for help? where could the bug be? is there even a bug? right now, i'm questioning everything!","date":"2022-03-14T15:20:09Z","quote":"dumbass! (that 70's show)"}

spread over 2 reads

Closing as this doesn't appear to be a bug with Go (or Chrome for that matter, just improper use of streaming APIs)

@seankhliao ok, got it. I was under the impression that the browser would read line by line at every occurrence of a \n char.

But I guess you're right since I found a handling text line by line example which illustrates how to handle chunks not ending on line boundaries. It was just not very clear from the docs that the readable stream doesn't necessarily split chunks at line endings.

Thanks for taking the time to check the code I shared and giving more insight into the issue!