proposal: net/http: toHTTPError should be public

[purpleidea]

The toHTTPError method in net/http is useful! Any reason it isn't public? Can we make it public? I'd have written the patch if it wasn't for the CLA.

Thanks!

[purpleidea]

And as an aside, I would have expected the function to look like this instead:

func toHTTPError(err error) (msg string, httpStatus int) {
	if os.IsNotExist(err) {
		return http.StatusText(http.StatusNotFound), http.StatusNotFound
	}
	if os.IsPermission(err) {
		return http.StatusText(http.StatusForbidden), http.StatusForbidden
	}
	return http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError
}

Any reason it has an extra copy of the status text instead of re-using the useful helper that we already have?

[rsc]

This doesn't seem important enough to expose in the standard library.
Maybe it should go into x/net/http/httpguts?
(If it did go into httpguts it should probably use errors.Is.)

[rsc]

Another problem with putting this in httpguts is that different servers are likely to want different customizations. The current situation, where people write the code they need, even if they start by copying those few lines, may be preferable to having a function in httpguts that will itself be the subject of more proposals for extensions.

There doesn't seem to be much enthusiasm for adding this or not. Perhaps we should leave things as is.

[purpleidea]

On Wed, Apr 22, 2020 at 1:41 PM Russ Cox ***@***.***> wrote: Another problem with putting this in httpguts is that different servers are likely to want different customizations. The current situation, where people write the code they need, even if they start by copying those few lines, may be preferable to having a function in httpguts that will itself be the subject of more proposals for extensions. There doesn't seem to be much enthusiasm for adding this or not. Perhaps we should leave things as is.

It's a useful helper for people like me who just want something along these lines, and would rather use a vaguely common behaviour rather than re-writing their own version constantly. I'd recommend putting it somewhere...

[rsc]

It's a useful helper for people like me who just want something along
these lines, and would rather use a vaguely common behaviour rather
than re-writing their own version constantly.

If you find yourself writing the same code over and over again, it's always a good idea to put it in your own library, published or not. On balance it doesn't seem like it should be published in the Go libraries, though. (Not all useful code has to be in the Go libraries.)

[rsc]

Based on the discussion above, especially how easy it is to put in a third-party package, this seems like a likely decline.

[rsc]

No change in consensus, so declined.