There is a similar issue in the parsePostForm function: https://golang.org/src/net/http/request.go#L1158.

@rsc At a very least set those string as constants, current code looks ugly and stands against all the things that we love in golang.

const http.StatusRequestEntityTooLargeMessage = "http: request body too large"

@rsc, I think this issue fell off the tracker because it's from before the "Proposal" tag. Can this be tagged? If the proposal is accepted, I'm happy to file the CL.

CC @neild

FWIW, #41493 is a dupe with all positive feedback. I propose that MaxByteReader should return errors of the type ErrorMaxBytesExceeded struct { MaxSize int64 } that can be checked with errors.As.

A http.MaxBytesReader is defined as "similar to io.LimitReader", but "returns a non-EOF error for a Read beyond the limit".

Wrapping the incoming request body in a MaxBytesReader is the recommended way to set a limit on the size of an incoming request body. It interacts with other elements of HTTP request processing in some non-obvious ways: For example, (*Request).ParseForm sets a 10MiB limit on the size of parsed form data, except when the request Body is a MaxBytesReader.

This proposal, as I understand it, is to return a defined error when a MaxBytesReader hits the read limit.

This seems reasonable to me.

The net/http package defines only one exported error type, http.ProtocolError, which is deprecated. It defines a number of sentinel error values. Since the creator of a MaxBytesReader knows what maximum size they provided it, I think that providing this information in the error response is unnecessary, and this should be a sentinel error. Perhaps:

// ErrRequestBodyTooLarge is returned after a ReadCloser created by MaxBytesReader reads
// past its limit.
var ErrRequestBodyTooLarge = errors.New("http: request body too large")

A couple questions, and my proposed answers:

• Does Close return ErrRequestBodyTooLarge if the limit is exceeded? Currently Close does not return an error in this case, but I think it should.
• Does Read return ErrRequestBodyTooLarge, or an error wrapping this one? I don't have a strong opinion here. If this was a new package, I'd argue for wrapping, but given the extensive use of bare sentinels in net/http I think consistency argues for returning an unwrapped ErrRequestBodyTooLarge.

Since the creator of a MaxBytesReader knows what maximum size they provided it, I think that providing this information in the error response is unnecessary, and this should be a sentinel error.

Not necessarily. I want to wrap different handlers in different middleware, so that the processImage handler has a 25MB limit, but the processUser handler has a 1MB limit, for example. I want to be able to write generic error response middleware that can prompt the user with different messages for different overages.

What if instead of defining an error type, we add http.IsMaxBytesError(err error) (size int)? If the error isn’t from MaxBytesReader, it returns 0, otherwise it returns a positive number. It’s easier to use than a defined type and lets us hide the implementation details.

If it is going to be generated by MaxBytesReader, perhaps it should be a MaxBytesError?
@neild are you satisfied by the justification above for including the number of bytes?
Or should we just do ErrMaxBytes / ErrRequestBodyTooLarge?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I would be happy with either of

type MaxBytesError int64

type MaxBytesError struct {
    Limit int64
}

The struct version is more extensible, but I don't foresee it needing extension, so int64 version is fine too.

A side-effect of this change is the secret requestTooLarger interface could be retired. I think it would probably stick around.

ping @neild re #30715 (comment)

I'm not really enthusiastic about increasing net/http's API surface with another type, but MaxBytesError seems reasonable. (I'd say that you can just wrap the io.ReadCloser returned by MaxBytesReader with your own type that adds whatever error you want--but there's a type assertion for the case when a Request.Body is a *maxBytesReader, so you can't actually do that).

type MaxBytesError struct {
  Limit int64
}

I don't think we should add http.IsMaxBytesError; error predicates are a perfectly fine pattern, but we don't have any in net/http now. A type fits the existing API better.

A struct is better than an int64. Better to always plan for extension rather than guess when you might need it.

We should maybe define that MaxBytesError{} is equivalent to any MaxBytesError, so you can write this if you don't care about the size:

if errors.Is(err, &http.MaxBytesError{}) { ... }

tl;dr, I'm reluctantly in favor of adding http.MaxBytesError.

We probably don't need the special definition at the end.
You can use

if errors.As(err, new(*http.MaxBytesError)) { ... }

Change https://golang.org/cl/361397 mentions this issue: net/http: add MaxBytesError

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Issue title should be changed to "net/http: add MaxBytesError".