Issue 7678043: code review 7678043: net/http: add additional status codes defined in RFC 6585 (Closed)
Descriptionnet/http: add additional status codes defined in RFC 6585
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
511 Network Authentication Required
Patch Set 1 #Patch Set 2 : diff -r 16e0e01c2e9b https://code.google.com/p/go/ #Patch Set 3 : diff -r 16e0e01c2e9b https://code.google.com/p/go/ #Patch Set 4 : diff -r ec3c88fc8445 https://code.google.com/p/go/ #Patch Set 5 : diff -r ec3c88fc8445 https://code.google.com/p/go/ #Patch Set 6 : diff -r ec3c88fc8445 https://code.google.com/p/go/ #MessagesTotal messages: 10
Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com), I'd like you to review this change to https://code.google.com/p/go/
Sign in to reply to this message.
Is this all done going through standardization? I see it's still a proposed standard, not a "draft standard" like 2616. Once we add this, we can't remove it, so it'd be a pity if this proposal is still in flux. I see lots of patches online for other web frameworks and languages, suggestion perhaps that this is a done deal, but maybe they don't have as strict of API guarantees. I don't know. On Sat, Mar 9, 2013 at 7:09 PM, <jonathan@titanous.com> wrote: > Reviewers: golang-dev1, > > Message: > Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com), > > I'd like you to review this change to > https://code.google.com/p/go/ > > > Description: > net/http: Add additional status codes defined in RFC 6585 > > 428 Precondition Required > 429 Too Many Requests > 431 Request Header Fields Too Large > 511 Network Authentication Required > > Please review this at https://codereview.appspot.**com/7678043/<https://codereview.appspot.com/7678... > > Affected files: > M src/pkg/net/http/status.go > > > Index: src/pkg/net/http/status.go > ==============================**==============================**======= > --- a/src/pkg/net/http/status.go > +++ b/src/pkg/net/http/status.go > @@ -44,13 +44,17 @@ > StatusRequestedRangeNotSatisfi**able = 416 > StatusExpectationFailed = 417 > StatusTeapot = 418 > + StatusPreconditionRequired = 428 > + StatusTooManyRequests = 429 > + StatusRequestHeaderFieldsTooLa**rge = 431 > > - StatusInternalServerError = 500 > - StatusNotImplemented = 501 > - StatusBadGateway = 502 > - StatusServiceUnavailable = 503 > - StatusGatewayTimeout = 504 > - StatusHTTPVersionNotSupported = 505 > + StatusInternalServerError = 500 > + StatusNotImplemented = 501 > + StatusBadGateway = 502 > + StatusServiceUnavailable = 503 > + StatusGatewayTimeout = 504 > + StatusHTTPVersionNotSupported = 505 > + StatusNetworkAuthenticationReq**uired = 511 > ) > > var statusText = map[int]string{ > @@ -92,13 +96,17 @@ > StatusRequestedRangeNotSatisfi**able: "Requested Range Not > Satisfiable", > StatusExpectationFailed: "Expectation Failed", > StatusTeapot: "I'm a teapot", > + StatusPreconditionRequired: "Precondition Required", > + StatusTooManyRequests: "Too Many Requests", > + StatusRequestHeaderFieldsTooLa**rge: "Request Header Fields Too > Large", > > - StatusInternalServerError: "Internal Server Error", > - StatusNotImplemented: "Not Implemented", > - StatusBadGateway: "Bad Gateway", > - StatusServiceUnavailable: "Service Unavailable", > - StatusGatewayTimeout: "Gateway Timeout", > - StatusHTTPVersionNotSupported: "HTTP Version Not Supported", > + StatusInternalServerError: "Internal Server Error", > + StatusNotImplemented: "Not Implemented", > + StatusBadGateway: "Bad Gateway", > + StatusServiceUnavailable: "Service Unavailable", > + StatusGatewayTimeout: "Gateway Timeout", > + StatusHTTPVersionNotSupported: "HTTP Version Not Supported", > + StatusNetworkAuthenticationReq**uired: "Network Authentication > Required", > } > > // StatusText returns a text for the HTTP status code. It returns the > empty > > > -- > > ---You received this message because you are subscribed to the Google > Groups "golang-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-dev+unsubscribe@**googlegroups.com<golang-dev%2Bunsubscribe@googlegrou... > . > For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/o... > . > > >
Sign in to reply to this message.
On 2013/03/10 15:35:50, bradfitz wrote: > Is this all done going through standardization? I see it's still a > proposed standard, not a "draft standard" like 2616. > > Once we add this, we can't remove it, so it'd be a pity if this proposal is > still in flux. > > I see lots of patches online for other web frameworks and languages, > suggestion perhaps that this is a done deal, but maybe they don't have as > strict of API guarantees. I don't know. The RFC has been untouched for about a year, no errata exist, and I can't find any recent IETF mailing list comments about it. It does seem like a done deal to me. That in mind, here's what RFC 2026 has to say about this: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. but it does warn: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended.
Sign in to reply to this message.
One might consider the Go 1 API promise as a "disruption-sensitive environment". Considering that these are just integers and people can just type the three digits in their client applications, I'm inclined to say no for now, moreso due to golang.org/s/go11freeze (not that this is prone to breaking anything, but because we're trying to reduce noise and focus on the finish line) On Sun, Mar 10, 2013 at 8:55 AM, <jonathan@titanous.com> wrote: > On 2013/03/10 15:35:50, bradfitz wrote: > >> Is this all done going through standardization? I see it's still a >> proposed standard, not a "draft standard" like 2616. >> > > Once we add this, we can't remove it, so it'd be a pity if this >> > proposal is > >> still in flux. >> > > I see lots of patches online for other web frameworks and languages, >> suggestion perhaps that this is a done deal, but maybe they don't have >> > as > >> strict of API guarantees. I don't know. >> > > The RFC has been untouched for about a year, no errata exist, and I > can't find any recent IETF mailing list comments about it. It does seem > like a done deal to me. > > That in mind, here's what RFC 2026 has to say about this: > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > but it does warn: > > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. > > https://codereview.appspot.**com/7678043/<https://codereview.appspot.com/7678... >
Sign in to reply to this message.
On 2013/03/10 15:59:48, bradfitz wrote:
> One might consider the Go 1 API promise as a "disruption-sensitive
> environment".
>
> Considering that these are just integers and people can just type the three
> digits in their client applications, I'm inclined to say no for now, moreso
> due to golang.org/s/go11freeze (not that this is prone to breaking
> anything, but because we're trying to reduce noise and focus on the finish
> line)
Totally understandable. I'm currently using a few of these codes in my
applications. The name of the code isn't showing up, and there's no way to
specify it currently. Should I file an issue about this?
HTTP/1.1 429 status code 429
Sign in to reply to this message.
On Sun, Mar 10, 2013 at 9:12 AM, <jonathan@titanous.com> wrote: > On 2013/03/10 15:59:48, bradfitz wrote: > >> One might consider the Go 1 API promise as a "disruption-sensitive >> environment". >> > > Considering that these are just integers and people can just type the >> > three > >> digits in their client applications, I'm inclined to say no for now, >> > moreso > >> due to golang.org/s/go11freeze (not that this is prone to breaking >> anything, but because we're trying to reduce noise and focus on the >> > finish > >> line) >> > > Totally understandable. I'm currently using a few of these codes in my > applications. The name of the code isn't showing up, and there's no way > to specify it currently. Should I file an issue about this? > > HTTP/1.1 429 status code 429 > How about this: update this CL and put all the new status codes grouped together with a comment above like, // New HTTP status codes from RFC 6585. Not being exported yet in Go 1.1. // See discussion at https://codereview.appspot.**com/7678043/<https://codereview.appspot.com/7678... statusFoo = 412 statusBar = 539 (note lowercase) Then make the new map entries lowercase too. So http.StatusText(429) will return the correct text, but we won't expand the Go 1.1 API yet.
Sign in to reply to this message.
Hello golang-dev@googlegroups.com, bradfitz@golang.org (cc: golang-dev@googlegroups.com), Please take another look.
Sign in to reply to this message.
LGTM
Sign in to reply to this message.
*** Submitted as https://code.google.com/p/go/source/detail?r=09424e87ff73 *** net/http: add additional status codes defined in RFC 6585 428 Precondition Required 429 Too Many Requests 431 Request Header Fields Too Large 511 Network Authentication Required R=golang-dev, bradfitz CC=golang-dev https://codereview.appspot.com/7678043 Committer: Brad Fitzpatrick <bradfitz@golang.org>
Sign in to reply to this message.
Message was sent while issue was closed.
Hello - May be a good time to reevaluate exposing status codes 428, 429, 431, 511, and introduce "413 Payload Too Large" (RFC 7231).
Sign in to reply to this message.
|
