-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: net/http: add helper funcs for HTTP status codes #29652
Comments
I have a POC and test that I want to publish to review. |
Change https://golang.org/cl/157337 mentions this issue: |
Sorry, I think this is too many top-level functions to add to net/http. I do want to add this later (like I did in https://godoc.org/inet.af/http#Status) but I don't think we should add this to today's net/http. |
What if leave IsSuccess only? The real life problem is that there are several options:
2-5 introduce magic numbers that looks weird consider we have http constants. It forces dev to have local helper, covered with Unit Test. IsSuccess would be enough for real life tasks. |
As a random thought,
|
Well, as an option, we can put it into net/http/httputil/status.go or so. @bradfitz what do you think? |
Making it a part of Status interface almost the same as making it a part of http.Reponse. When I have "int" code, I don't want to allocate Status object first. This is an aexample when IsSuccess, Is... need to be external helpers that covers all cases. |
There's no allocation involved. It's also not an interface. |
Hmm, I mean case:
there will be always some case, when code is just int (read from file and etc) |
That still doesn't allocate. In any case, I don't want to discuss the v2 http packages in this bug. I say no to adding more helpers to net/http. I'm on the fence for net/http/httputil. I'm fine with it if others in the @golang/proposal-review group are. |
Updated review. Now helpers are part of net/http/httputil as @ainar-g suggested. Some unrelated question: C++ had/has BOOST library that had many libs that could not be a part of STL but were generic and useful. Many of them became a part of standard later. Anyway, many companies/developers used BOOST with all appropriate contracts/risks. If you know, what is Go's team/community vision on having Go's "boost" ? |
Your unrelated question is better suited to a mailing list probably. I'd rather not distract this issue. |
What version of Go are you using (
go version
)?go version go1.11.4 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?darwin, OS X
What did you do?
I needed functions to check if http StatusCode is in the following ranges https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
1xx: Informational - Request received, continuing process
2xx: Success - The action was successfully received, understood, and accepted
3xx: Redirection - Further action must be taken in order to complete the request
4xx: Client Error - The request contains bad syntax or cannot be fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid request
This is pretty common task when Server may return StatusOK, StatusCreated and other 2xx. Usually in this case developers has several options:
What did you expect to see?
I'd expect that http package provides appropriate interface/methods:
Such methods, regardless of the way they are implemented, provides a standard way to do such check and so developers don't need to spend time on implementation, review and discussion of better way. (I am talking now about my own experience)
I also considered having interface for http.Response but this is not flexible, because in some cases I would like to check status code without having Response object.
What did you see instead?
It has only 1 helper:
func StatusText(code int) string
The text was updated successfully, but these errors were encountered: