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

[rob05c]

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"

[odeke-em]

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.

[odeke-em]

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

[cookiengineer]

What is the current state of this?

As per renewed RFC 9110 which deprecates the obsolete drafts and older RFCs, this is still wrongly implemented in net/http.

The code itself even quotes RFC 9110, section 15.5.17, but still uses the wrong "Requested Range Not Satisfiable" message.

[rob05c]

As the original author, I'll note

1. I was not then, and am not now, actually experiencing problems from this.
2. I've actually experienced clients breaking from being hard-coded to expect an exact Reason Phrase response which changed (from a Tomcat 8.5 upgrade). Hyrum's law and all, every change is breaking for somebody. So my vote is not to change the existing. Though adding http.StatusRangeNotSatisfiable seems fine to me.