encoding/json: Encoder adds new line at the end of response which is different from how Marshal works

[jpninanjohn]

What version of Go are you using (go version)?

$ go version

 1.13.5

Issue:

Encoder and Marshal behaves differently. Refer

There is a newline added for encoder. Refer to this code.

Where does this break:

In cases where content length is asserted on. Eg. In gin, context.JSON uses Encoder that adds the new line to response thus making the content length of response one more than what was in the actual response. The convention is broken as many libraries dont read the newline. Hence read content length will be one lesser than content length sent in the response.
This fails in HTTP clients due to a difference in the actual content length and the Content-Length header

Refer this issue

What did you expect to see?

Encoder and Marshal should result in the exact same JSON string.

What did you see instead?

An additional line added in response when encoder is used to convert object to json.

---

cc @dineshba @KaushikNeelichetty @kishaningithub

[AlexRouSg]

This is working as documented.
https://golang.org/pkg/encoding/json/#Encoder.Encode

Encode writes the JSON encoding of v to the stream, followed by a newline character.

[jpninanjohn]

@AlexRouSg Yes, issue is not that its not documented, but rather that the difference breaks in the scenario mentioned. I dont mind the newline if nothing breaks but since it does, is it actually needed? (CMIIW, its only there for prettification.. right??)

@cagedmantis can I raise a PR for this?

[AlexRouSg]

Please see https://golang.org/doc/go1compat for why this cannot be changed. Because it is documented behaviour, someone somewhere is going to depend on it and changing it will break their code.

The most you can do is propose new API but the bar for that is very high, see https://golang.org/doc/faq#x_in_std
and https://github.com/golang/proposal

[AlexRouSg]

cc @rsc @dsnet @bradfitz @mvdan as per owners

[mvdan]

To give some context, the newline isn't there for pretty output. If that were the case, it would be coupled with Indent, but it isn't.

The reason is so that you can write a stream of JSON objects delimited by lines, instead of having to write an entire list of objects all at once. This is a well known way to stream objects in JSON. For example, go test -json uses this, so that it can show you test results as they happen, instead of dumping all the output at the end of the program.

Similarly, the decoder supports this kind of streaming of objects.

What is your suggestion here? Like @AlexRouSg said, we can't change the behavior, even if we wanted to - we would break too many existing programs.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)