Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reserve the 418 status code

tools.ietf.org

Post reply on HN
Print view View original

11–20 of 124 posts

Re: Reserve the 418 status code

#11

Post by geofft »

peterwwillis wrote: post #10
endgame wrote: 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's weird though. The origin spec is specifically a discrete protocol called HTCPCP, not HTTP, so it has nothing to do with HTTP standards. They can do whatever they want with 418 in HTTP.

They can, but they believe in rough consensus and working code and in being conservative in what they do and liberal in what they accept from others.

It's clear that a lot of real-world HTTP implementations are using HTTP 418 to mean I'm A Teapot, whether or not they should, and that reassigning it would cause practical difficulties.

Re: Reserve the 418 status code

#12

Post by toomanybeersies »

endgame wrote: post #7
cyphar wrote: post #3

Earlier quoted context omitted.

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.

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 /r/webdev).

Re: Reserve the 418 status code

#13

Post by ramses0 »

habitue wrote: post #8
cyphar wrote: post #3

Earlier quoted context omitted.

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.

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

Re: Reserve the 418 status code

#14

Post by peterwwillis »

geofft wrote: post #11
peterwwillis wrote: post #10

Earlier quoted context omitted.

It's weird though. The origin spec is specifically a discrete protocol called HTCPCP, not HTTP, so it has nothing to do with HTTP standards. They can do whatever they want with 418 in HTTP.

They can , but they believe in rough consensus and working code and in being conservative in what they do and liberal in what they accept from others. It's clear that a lot of real-world HTTP implementations are using HTTP 418 to mean I'm A Teapot, whether or not they should, and that reassigning it would cause practical difficulties.

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 unofficial feature of popular vendor software, and is now officially disavowed.

Basically what we're saying is we're not going to implement 418 in the spec, but at the same time, we're not going to let anyone use it?

Re: Reserve the 418 status code

#15

Post by JoshTriplett »

peterwwillis wrote: post #14
geofft wrote: post #11

Earlier quoted context omitted.

They can , but they believe in rough consensus and working code and in being conservative in what they do and liberal in what they accept from others. It's clear that a lot of real-world HTTP implementations are using HTTP 418 to mean I'm A Teapot, whether or not they should, and that reassigning it would cause practical difficulties.

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…

> 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.

Re: Reserve the 418 status code

#16

Post by peterwwillis »

JoshTriplett wrote: post #15
peterwwillis wrote: post #14

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…

> 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 brewing coffee? 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.

Maybe a time traveler set this whole thing up 19 years ago just to troll people on standards boards.

Re: Reserve the 418 status code

#17

Post by dexterdog »

JoshTriplett wrote: post #15
peterwwillis wrote: post #14

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…

> 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.

Except blink is a string that means what it is. 418 is one of a small set of codes to use and has no purpose as it exists other than nonsense.

Re: Reserve the 418 status code

#18

Post by LambdaComplex »

lccarrasco wrote: post #5
joombaga wrote: 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

I was worried that page would actually return a 200 OK response, but curl confirmed it actually returns a 418 code

Re: Reserve the 418 status code

#19

Post by [deleted] »

peterwwillis wrote: post #14
geofft wrote: post #11

Earlier quoted context omitted.

They can , but they believe in rough consensus and working code and in being conservative in what they do and liberal in what they accept from others. It's clear that a lot of real-world HTTP implementations are using HTTP 418 to mean I'm A Teapot, whether or not they should, and that reassigning it would cause practical difficulties.

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…

[deleted]

Re: Reserve the 418 status code

#20

Post by concede_pluto »

peterwwillis wrote: post #14
geofft wrote: post #11

Earlier quoted context omitted.

They can , but they believe in rough consensus and working code and in being conservative in what they do and liberal in what they accept from others. It's clear that a lot of real-world HTTP implementations are using HTTP 418 to mean I'm A Teapot, whether or not they should, and that reassigning it would cause practical difficulties.

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.
Post reply on HN