We know that Len is the right choice for those three types.
There's no widespread "Len-er" interface in Go, though, so I am skeptical of calling it always.
Maybe on some types Len might be a number of records?

We know that Len is the right choice for those three types.
There's no widespread "Len-er" interface in Go, though, so I am skeptical of calling it always.
Maybe on some types Len might be a number of records?

How about check ContentLength is zero?
If ContentLength is zero and body implement interfae{Len()int},then assign Len() to ContentLength.

@jingyugao I certainly agree that if the caller has explicitly set ContentLength then it should not be replaced.

But that doesn't really address my objection. Content-Length is not a hint. It is a promise, and the code should not make a promise unless it is sure it can be kept. The code is sure for the three special-case types (which are very common). The code cannot be anywhere near as sure about any type that happens to have a Len() int method. Len is measured in elements, which does not always mean bytes. (For example, suppose io.MultiReader returned a concrete implementation with a Len method that returned the number of underlying readers.)

Is there some widespread body implementation you are concerned about handling?

Adding to the proposal minutes. Len() int still seems like not enough signal for me.

In #16474 (comment), @ianlancetaylor observed:

It seems that the best way to use this technique effectively is for each magic method to mean exactly one thing. … If multiple functions support the same magic method, we wind up with an N-x-N crossbar: trying to use the magic method for multiple different purposes, when we have to know which purpose is intended to know whether it makes sense.

For this case I would share Russ's concern about Len indicating the length of some container in units other than bytes — perhaps runes, number of entries, or similar.

Based on the discussion above, this seems like a likely decline.

No change in consensus, so declined.