3 ms·

Oh! I never took the time to read it and didn't knew the protocol was actually for coffee machines. It makes sense to have the 418 status code then. > Any att

Oh! I never took the time to read it and didn't knew the protocol was actually for coffee machines. It makes sense to have the 418 status code then. > Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot".

petee 8y ago
And don't forget the new extension - HTCPCP-TEA: > TEA-capable pots that are not provisioned to brew coffee may return either a status code of 503, indicating temporary unavailability of coffee, or a code of 418 as defined in the base HTCPCP specification to denote a more permanent indication that the pot is a teapot. https://tools.ietf.org/html/rfc7168 https://tools.ietf.org/html/rfc7168
Nr7 8y ago
An extension was made for tea brewing in 2014. https://tools.ietf.org/html/rfc7168 https://tools.ietf.org/html/rfc7168
Chilinot 8y ago
I think it's also important to take note that the 418 status code may be "short and stout".
hoppelhase 8y ago
Indeed. It defines code 418 for HTCPCP (which is an extension to HTTP), not HTTP itself. So, all HTTP-only implementations that have 418 are technically incorrect, since it is not part of HTTP.
- WorldMaker 8y ago
  Most of the codes defined in the WebDAV standard are assumed by most implementations and also to an extent by IETF's standardization efforts to be recognizable HTTP codes even in non-WebDAV situation. Those codes are only defined semantically in the WebDAV protocol, but they are considered broadly to be extended HTTP codes available for general usage as defined, simply with less defined semantics in those cases. Which would seem to apply equally here: While the HTCPCP standard only indicates the semantics of the codes with respect to usage in HTCPCP scenarios, they are still code extensions to HTTP and available for use as defined, simply with fewer specified semantics. Which is to say if you build your HTTP REST API using 418, we can all generally agree that the error from your API at that time is "I'm a teapot". Given that you aren't an HTCPCP endpoint, we just can't assume that we could then try HTCPCP-TEA to then try to brew tea, as we can't be sure that the semantics follow. Perhaps your REST API is simply a catalog of brewing equipment for purchase, and it still makes sense for some of your endpoints to fail with a 418. :) It's unlikely for the IETF to assign 418 to a different HTTP-based or HTTP-like protocol with an entirely different and non-compatible definition, so even if 418 is laxly defined for HTTP proper, it's still "technically correct" in the sense that you can technically use it all you want and the only repercussions from the technical specs are if you implement it wrong in HTCPCP, there's no wrong way to use 418 in plain HTTP. ;) https://http.cat/418 https://http.cat/418
  - hoppelhase 8y ago
    I was not arguing against implementing 418. IMHO, it's okay to implement it since it won't be assigned to something else.
    - WorldMaker 8y ago
      Sure, that's fair, I was simply pointing out that the web is a much more complicated mixture of its standards documents than just surface level, to the point where originally intended to be unrelated standards do bleed together. April Fools Joke or not, "HTCPCP" or not, 418 is an interesting part of HTTP's legacy now.

petee 8y ago

And don't forget the new extension - HTCPCP-TEA: > TEA-capable pots that are not provisioned to brew coffee may return either a status code of 503, indicating temporary unavailability of coffee, or a code of 418 as defined in the base HTCPCP specification to denote a more permanent indication that the pot is a teapot. https://tools.ietf.org/html/rfc7168 https://tools.ietf.org/html/rfc7168

Nr7 8y ago

An extension was made for tea brewing in 2014. https://tools.ietf.org/html/rfc7168 https://tools.ietf.org/html/rfc7168

Chilinot 8y ago

I think it's also important to take note that the 418 status code may be "short and stout".

hoppelhase 8y ago

Indeed. It defines code 418 for HTCPCP (which is an extension to HTTP), not HTTP itself. So, all HTTP-only implementations that have 418 are technically incorrect, since it is not part of HTTP.

WorldMaker 8y ago
Most of the codes defined in the WebDAV standard are assumed by most implementations and also to an extent by IETF's standardization efforts to be recognizable HTTP codes even in non-WebDAV situation. Those codes are only defined semantically in the WebDAV protocol, but they are considered broadly to be extended HTTP codes available for general usage as defined, simply with less defined semantics in those cases. Which would seem to apply equally here: While the HTCPCP standard only indicates the semantics of the codes with respect to usage in HTCPCP scenarios, they are still code extensions to HTTP and available for use as defined, simply with fewer specified semantics. Which is to say if you build your HTTP REST API using 418, we can all generally agree that the error from your API at that time is "I'm a teapot". Given that you aren't an HTCPCP endpoint, we just can't assume that we could then try HTCPCP-TEA to then try to brew tea, as we can't be sure that the semantics follow. Perhaps your REST API is simply a catalog of brewing equipment for purchase, and it still makes sense for some of your endpoints to fail with a 418. :) It's unlikely for the IETF to assign 418 to a different HTTP-based or HTTP-like protocol with an entirely different and non-compatible definition, so even if 418 is laxly defined for HTTP proper, it's still "technically correct" in the sense that you can technically use it all you want and the only repercussions from the technical specs are if you implement it wrong in HTCPCP, there's no wrong way to use 418 in plain HTTP. ;) https://http.cat/418 https://http.cat/418
- hoppelhase 8y ago
  I was not arguing against implementing 418. IMHO, it's okay to implement it since it won't be assigned to something else.
  - WorldMaker 8y ago
    Sure, that's fair, I was simply pointing out that the web is a much more complicated mixture of its standards documents than just surface level, to the point where originally intended to be unrelated standards do bleed together. April Fools Joke or not, "HTCPCP" or not, 418 is an interesting part of HTTP's legacy now.