Skip to content
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

net/http: StatusText(416) returns "Requested Range Not Satisfiable" should be "Range Not Satisfiable" #42276

Open
rob05c opened this issue Oct 29, 2020 · 2 comments
Labels
Milestone

Comments

@rob05c
Copy link

@rob05c rob05c commented Oct 29, 2020

RFC 7233 defines 416 as "Range Not Satisfiable". This was previously "Requested Range Not Satisfiable" in RFC 2616, which is obsolete.
https://tools.ietf.org/html/rfc7233#section-4.4

But everywhere this occurs, whether it's user code calling http.StatusText, or http.ServeFile when a client requests a bad range, Go gives the client 416 Requested Range Not Satisfiable when the canonical text is 416 Range Not Satisfiable.

Obviously http.StatusRequestedRangeNotSatisfiable will have to stay to avoid breaking compatibility, but:

  1. Should https://golang.org/src/net/http/status.go#L121 statusText[StatusRequestedRangeNotSatisfiable] be changed to "Range Not Satisfiable" ?
  2. Should http.StatusRangeNotSatisfiable be added?
  3. Should http.StatusRequestedRangeNotSatisfiable be removed in Go 2?

And yes, I realize this is the minorest of issues.

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rbutts201/Library/Caches/go-build"
GOENV="/Users/rbutts201/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/rbutts201/lang/go/"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vy/4dwjjyh96295zr995ny4wn400000gp/T/go-build975609211=/tmp/go-build 
-gno-record-gcc-switches -fno-common"

What did you do?

http.StatusText(416)
http.StatusText(http.StatusRequestedRangeNotSatisfiable)

What did you expect to see?

"Range Not Satisfiable"

What did you see instead?

"Requested Range Not Satisfiable"

@dmitshur dmitshur changed the title http.StatusText(416) returns "Requested Range Not Satisfiable" should be "Range Not Satisfiable" net/http: StatusText(416) returns "Requested Range Not Satisfiable" should be "Range Not Satisfiable" Oct 30, 2020
@odeke-em
Copy link
Member

@odeke-em odeke-em commented Oct 30, 2020

Thank you for this question @rob05c and welcome to the Go project!

So firstly we've had this status message for the past 11+ years without a complaint. RFC 7233 was made in 2014 aka >6 years ago.

Data from survey

To survey prominent infrastructure on the internet to see if we've deviated, or perhaps as motivation for if we should change it, backed by data on what others have done:

Entity Kind Response Reference
AWS S3 Cloud storage "Requested Range cannot be satisfied" https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
Google Cloud Storage Cloud storage "Requested Range not satisfiable" https://cloud.google.com/storage/docs/json_api/v1/status-codes?hl=tr#416_Requested_Range_Not_Satisfiable
Microsoft Azure Cloud storage "Requested Range not satisfiable" https://docs.microsoft.com/en-us/rest/api/storageservices/specifying-the-range-header-for-file-service-operations
Python Language "Requested Range not satisfiable" https://docs.python.org/3/howto/urllib2.html
PHP Language "Requested Range not satisfiable" https://github.com/php/php-src/blob/5d6e923d46a89fe9cd8fb6c3a6da675aa67197b4/main/http_status_codes.h#L59
Node.js Language "Range Not Satisfiable" https://github.com/nodejs/node/blob/d70c0ed250ac79e267e87213c6fa0a6c51a634af/lib/_http_server.js#L129
Nginx Server "Requested Range not satisfiable" https://github.com/nginx/nginx/blob/15544440425008d5ad39a295b826665ad56fdc90/src/http/ngx_http_special_response.c#L222
Varnish Server "Requested Range not satisfiable" https://github.com/varnishcache/varnish-cache/blob/d686166ad469cad4043ed24328f4377e0d5f71a7/include/tbl/http_response.h#L74
Finagle RPC system for the JVM "Requested Range not satisfiable" https://github.com/twitter/finagle/blob/eee6835546e32ea42d429db626c80e6a864fc9ff/finagle-base-http/src/main/scala/com/twitter/finagle/http/Status.scala#L238
Netty RPC system for Java "Requested Range not satisfiable" https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/HttpResponseStatus.java#L217-L219
Jetty RPC system for Java "Range not satisfiable" https://github.com/eclipse/jetty.project/blob/f4fc78ac66a5811a68e264055114d879d74ae477/jetty-http/src/main/java/org/eclipse/jetty/http/HttpStatus.java#L149
Apache Tomcat HTTP server "Range not satisfiable" https://github.com/apache/tomcat/blob/a08ac04849a59e157433c3730c56db8a083765b4/java/org/apache/catalina/valves/LocalStrings.properties#L85
Apache httpd HTTP server "Requested Range not satisfiable https://github.com/apache/httpd/blob/2517583a449cc109733e443f8994bf7782687bdc/modules/http/http_protocol.c#L133
h2o HTTP server "Requested Range not satisfiable https://github.com/h2o/h2o/blob/1defc77a2243804d06401a9331ecf81735606f9c/lib/handler/file.c#L692

Results

Of the 14 surveyed popular/critical internet infrastructure, only 3 use that newer RFC's definition -> 21.43%

Conclusion

Given that that might be a sudden change that hasn't been propagated to majority of the surveyed infrastructure as per above, I don't think we should make this change. Despite it being low-risk and not necessarily under the Go1 compatibility promise as it is a status message so amenable, by Hyrum's law, a change (moreover after 11+ years) is bound to break code for someone, and no report has come in in the past 6+ years since its introduction. I thus vote to say let's not change this, but definitely a consideration for Go2, which will give enough time perhaps for maturity of that RFC and adoption by others too.

@dmitshur dmitshur added this to the Backlog milestone Oct 30, 2020
@odeke-em
Copy link
Member

@odeke-em odeke-em commented Oct 30, 2020

@bradfitz @rsc @agl @FiloSottile what do y'all think, as per the survey I've conducted in #42276 (comment)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.