Misc #12935: Webrick: Update HTTP Status codes, share them

• Status: Closed
• Assignee: naruse (Yui NARUSE)

[chucke (Tiago Cardoso)]

I was looking for a common source of http status-to-reason map in ruby, and I've found many sources that address the same, some of them overlapping, most of them clearly copy-pasting from each other. In the process, I also found that the current hashmap used by webrick seems not to be up-to-date. Compare:

https://github.com/nahi/ruby/blob/webrick_trunk/lib/webrick/httpstatus.rb#L56-L97
with https://github.com/puma/puma/blob/3f66b3d7d4413f843e4e541c4d282238318c4cd2/lib/puma/const.rb#L16-L74

I started (this thread in puma)[https://github.com/puma/puma/issues/1133] to see about openness is centralizing this information in ruby (or just use an updated version of webrick hash), and I found out some interesting things, like the fact that rails reloading is not compatible with some of these things.

My main motivation would be to have something similar to nodejs's http.STATUS_CODES:

> require("http").STATUS_CODES
{ '100': 'Continue',
 '101': 'Switching Protocols',
 '102': 'Processing',
 '200': 'OK',
 ....

As http is something which is internally implemented in ruby's stdlib, question would just remain on how and where to implement it, and public API stability and "up-to-date"ness guarantees. I'd suggest maybe making it part of "net/http", like:

require "net/http/status"
puts Net::HTTP::STATUS_CODES

but that's just a suggestion.

[zverok (Victor Shepelev)]

My 5c:

• It seems really reasonable to have centralized repo of status codes;
• I am not sure it should be in stdlib, why we not just do a gem?.. (With, probably, automatic update from an authorative source);
• Now, what would be an authoritative source? http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml (like Wikipedia says)? It is OK, but not OK, as it does not list, for example, "418 I'm a teapot" thing -- which, from one point of view is definitely a joke, but from other, it is a) properly covered with RFC and b) used in ton of occasion in reality (in place of "something weird happened").

[duerst (Martin Dürst)]

On 2016/11/15 04:03, [e-mail] wrote:

Issue #12935 has been updated by Victor Shepelev.

• Now, what would be an authoritative source? http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml (like Wikipedia says)? It is OK, but not OK, as it does not list, for example, "418 I'm a teapot" thing -- which, from one point of view is definitely a joke, but from other, it is a) properly covered with RFC and b) used in ton of occasion in reality (in place of "something weird happened").

Can you point to some of these examples? If there is actual use of this
code in a somewhat uniform way, then it should be possible to register
it. Also, if there are other, similar codes, then the same applies.

Regards, Martin.

[phluid61 (Matthew Kerwin)]

Martin Dürst wrote:

Can you point to some of these examples? If there is actual use of this
code in a somewhat uniform way, then it should be possible to register
it. Also, if there are other, similar codes, then the same applies.

Regards, Martin.

I know, and I guess you also know, that "418 I'm a Teapot" comes from traditional April 1 RFCs:

• https://tools.ietf.org/html/rfc2324#section-2.3.2
• https://tools.ietf.org/html/rfc7168#section-2.3.3

The code (and more importantly its name) has appealed to a lot of people over the years. Personally I've used it in the past for application-specific signalling that a client has hit an endpoint that knows the higher-level protocol enough to know that it's the wrong (type of) peer.

Maybe there's a non-April-1 Informational RFC in there somewhere, if other folk are doing the same thing.

NB:

~$ curl -I https://www.google.com/teapot
HTTP/2 418 
content-type: text/html; charset=ISO-8859-1
date: Tue, 15 Nov 2016 05:34:12 GMT
server: gws
cache-control: private
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
alt-svc: quic=":443"; ma=2592000; v="36,35,34"
accept-ranges: none
vary: Accept-Encoding

~$

[chucke (Tiago Cardoso)]

Thoroughness aside, what would be the best approach? Having it in a gem is the easiest way, but it's an extra dependency to resolve (unless it's bundled with ruby, like openssl or net-telnet). I'd aim at availability, as this is a common set of vars shared both by http server and clients (and cgi?), and can be reused by other third-party servers like thin or puma.

[zverok (Victor Shepelev)]

Can you point to some of these examples? If there is actual use of this code in a somewhat uniform way, then it should be possible to register it. Also, if there are other, similar codes, then the same applies.

Well, except for Google's (and similar) Easter Eggs, I saw several times (including pretty big companies) when the code was used internally, but in production, for signaling some weird conditions.

And I should say that gems that convert HTTP codes to exceptions or explanations, typically aware of it:

RestClient.get('https://www.google.com/teapot')
# => RestClient::ImATeapot: 418 I'm A Teapot
Faraday.get('https://www.google.com/teapot').reason_phrase
# => "I'm a Teapot" 
HTTParty.get('https://www.google.com/teapot').response
# => #<Net::HTTPClientError 418 I'm a Teapot readbody=true>

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned
• Assignee set to naruse (Yui NARUSE)

[shyouhei (Shyouhei Urabe)]

We looked at this issue at yesterday's developer meeting and decided to let naruse (who was there) handle this issue.

[naruse (Yui NARUSE)]

• Status changed from Assigned to Closed

Applied in changeset trunk|r58801.

---

Net::HTTP::STATUS_CODES is added as HTTP Status Code Repository [Misc #12935]

Note that 418 I'm a teapot doesn't exist because RFC 2324 and
RFC 7168 are not registered in IANA repository.
https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

[chucke (Tiago Cardoso)]

Could the namespaces be open, thereby allowing me to only require this file instead of the whole of net/http? It seems to me that, if I require this file without the Net::HTTP constant be defined, that this will fail.