Change https://golang.org/cl/152297 mentions this issue: encoding/json: created json.UnknownFieldsError

Per discussion with @golang/proposal-review, putting on hold until we can review JSON issues en masse.

Hello @andybons, do you have any idea of when you will be able to review these JSON issues en masse? Thanks.

Looks absolutely ugly in retrospect to golang 1.13 with new error handling (errors.Is).

@s3rj1k please be more objective, this was the best solution in the time when I face this problem, instead of judge, please provide an example using errors.Is, so I can update this PR

@jaswdr I was talking about golang core library mess. not your solution :)

@s3rj1k ack

Can we revisit this?
In my case, I am trying to detect if clients are sending JSON requests with unknown fields. I don't want to make the request fail, but I want to make it visible by printing some warnings.

Being able to handle the error properly would allow me to achieve that.

the only solution i could think about without writing lot of code is

                 var p *entity.Product
		dec := json.NewDecoder(r.Body)
		dec.DisallowUnknownFields() //WARNNING return only one unknown field

		err := dec.Decode(&p)

		switch {
		case err == io.EOF:
			w.WriteHeader(http.StatusBadRequest)
			w.Write([]byte("Provide valid Body"))
			return
		case err != nil && strings.Contains(err.Error(), "json: unknown field"): // if the error string changed within the package then the below case will work `Provide valid JSON`
			m := regexp.MustCompile(`\".+\"`)
			field := m.FindString(err.Error())
			w.WriteHeader(http.StatusBadRequest)
			w.Write([]byte(field + " : Not Allowed"))
			return
		case err != nil:
			w.WriteHeader(http.StatusBadRequest)
			w.Write([]byte("Provide valid JSON"))
			return
		}

It would be great to see this get added. As @markus-azer explained, the workaround for now would be to compare to the error message itself. Instead of using strings.Contains, I went with strings.HasPrefix.

if strings.HasPrefix(err.Error(), "json: unknown field") {
    // ...
}

This issue is similar to #30715, which was recently resolved by introducing an error, so message comparison is no longer needed.

Looking forward to this one being resolved too.

Also worth noting that it does not appear to be possible to return the full json path to the unexpected field, as is. In contrast, json.UnmarshalTypeError includes the full path to the offending field.

I never expected that this issue would be shelved for as long as six years. This is truly unbelievable. Meanwhile, the pull request to fix this issue was also shelved due to an error in the key data type.

Are there any plans on still making this an error? Would be useful!

json changes are mostly focused on the v2 package. See #63397. CC @dsnet @mvdan