Live data from Hacker News

Reserve the 418 status code

tools.ietf.org

21–30 of 124 posts

Re: Reserve the 418 status code

#21
post #7

Earlier quoted context omitted.

Note that the "contributor" (Mark Nottingham) is also the author of the document in OP, and deserves a lot of credit for taking this approach. Given that his area of work is HTTP standards, I think he initially started removing 418 to tidy up and make things compliant and isn't just some bore who hates fun. Now he's managed to make everyone happy in a standards-compliant way.

It was interesting reading the threads on /r/webdev about this whole debacle. The threads were full of people saying that he's an arsehole with too much time on his hands who must hate fun. Nobody actually stopped to read the guys bio and realise that he's more than qualified to be bringing up these issues. It doesn't help that the guy who made save418.com is literally 14 (which seems to be about the average age of /…

The /r/webdev thread (https://www.reddit.com/r/webdev/comments/6stdcj/http_error_c...) remained quite respectful actually, afaik there were no real hostile remarks directed towards Mark Nottingham within it. In fact, it's ironic - the very comment I'm replying to is probably more distasteful and antagonistic than anything that could be found in the Reddit thread.

Re: Reserve the 418 status code

#22
post #2

Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)

An example of an existing easter egg (for reference): https://www.google.com/teapot

Is there a scenario where people end up there?

Re: Reserve the 418 status code

#24
post #2

Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)

An example of an existing easter egg (for reference): https://www.google.com/teapot

It looks as if the teapot is responsive to my phone's gyros. I would've thought it would need special permission for that.

What a terribly clever Easter egg.

Re: Reserve the 418 status code

#26
post #13
post #8

Earlier quoted context omitted.

The contributor trying to remove 418 and the author of this RFC are the same person (Mark Nottingham[1]) [1] https://en.wikipedia.org/wiki/Mark_Nottingham

...and seems aware that this is simply "tidying up" as opposed to someone from the "No-Fun League"... see the working title: draft-nottingham-thanks-larry-00

For context: "Larry" is the author of the April Fools' RFC that introduced 418.

Re: Reserve the 418 status code

#27

Earlier quoted context omitted.

> It's like saying was "consumed" in HTML because two browsers used to support it. Which is accurate. Reintroducing a tag named "blink" into HTML to mean something other than "blinking text" would be a really bad idea for compatibility reasons.

So we're trying to avoid breaking the internet by committing to people expecting an error when they're talking to a teapot? So that past implementations of clients connecting to teapots won't break? Like I say, we could also just add it to the spec... But that would be ridiculous, because why would you support telling someone you were a teapot in an HTTP protocol, when the feature is only useful in a protocol for bre…

> That would be like taking a programming language's syntax for assigning data objects and turning it into it's own standard for a text file format.

Looking at you, JSON...

Re: Reserve the 418 status code

#28
post #3
post #2

Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)

It's a response to this story ( https://news.ycombinator.com/item?id=14987460 ), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code. EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.

[deleted]

Re: Reserve the 418 status code

#29

Earlier quoted context omitted.

> It's like saying was "consumed" in HTML because two browsers used to support it. Which is accurate. Reintroducing a tag named "blink" into HTML to mean something other than "blinking text" would be a really bad idea for compatibility reasons.

So we're trying to avoid breaking the internet by committing to people expecting an error when they're talking to a teapot? So that past implementations of clients connecting to teapots won't break? Like I say, we could also just add it to the spec... But that would be ridiculous, because why would you support telling someone you were a teapot in an HTTP protocol, when the feature is only useful in a protocol for bre…

It's a miniscule bit of humour that consumes 1 of 31 used slots in a 100-slot block, in an area of tech that isn't even remotely drowning in 'fun stuff'. What does it really matter? There are plenty of perfectly serious RFCs that are even less implemented than 418.

It's not like this RFC ratifying a 20-year-old joke that 'made it' is going to generate a cavalcade of lookalikes.

Re: Reserve the 418 status code

#30

Earlier quoted context omitted.

That's not clear to me. Nobody relies on the feature, it's a tiny piece of code, only some vendors support it, and it's not even part of the spec. (It also can't be reassigned because it was never assigned to begin with) If they like 418, they can add it to the spec. But this idea that it's been "consumed" is weird. It's like saying was "consumed" in HTML because two browsers used to support it. It was just an unoffi…

Say you want to add some feature critical to correctness. "Request can't be committed until resent to other quorum members." Something serious like that. You can't use 418 for that feature because some non-conforming servers are already returning it as a joke. You'd have to triage new RFCs until you get one that isn't important enough to work reliably, and sacrifice it to use up the tainted code.

The 400-block is 69% free, after 28 years of development. If we're ever in the position where we need to free up just one more code, then we're already consuming beyond our capacity and will need to sort out an alternative anyway.
Post reply on HN