Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Http-statuscode 'I'm a teapot' is voorlopig veilig

Door , 36 reacties

Http-statuscode 418, ook wel bekend als 'I'm a teapot', heeft de status 'gereserveerd' ontvangen van de Internet Engineering Task Force. Dit gebeurde nadat de organisatie een poging had ondernomen om de statuscode te verwijderen, wat protest opleverde.

De code maakt deel uit van het Hyper Text Coffee Pot Control Protocol, oftewel rfc2324, dat in 1998 was bedacht als een 1-aprilgrap. Het is een protocol voor het besturen en in de gaten houden van een koffiepot en diende volgens maker Larry Masinter als illustratie van het verschijnsel dat http op allerlei ongepaste manieren werd uitgebreid.

Het protocol kent twee statuscodes, waaronder 418. Die leest: "Any attempt to brew coffee with a teapot should result in the error code '418 I'm a teapot'. The resulting entity body MAY be short and stout." Onlangs nam IETF-werkgroepvoorzitter Mark Nottingham het op zich om de statuscode te verwijderen uit bijvoorbeeld Node.js en Googles Go. Daar was de code als easteregg in opgenomen.

Zijn actie stuitte echter op weerstand en kort daarna riep een scholier de website save418 in het leven. Daar schrijft hij dat de code 'een herinnering is aan het feit dat de onderliggende processen van computers nog steeds door mensen worden gemaakt'. Nottingham heeft zijn poging nu gestaakt en heeft de code nu de status 'gereserveerd' toegekend in het IANA-register, waardoor deze niet aan een ander doel toegewezen kan worden.


Htcpcp-theepot. Foto: A.cilia, Wikipedia / Creative Commons

Sander van Voorst

Nieuwsredacteur

14 augustus 2017 09:03

36 reacties

Linkedin Google+

Reacties (36)

Wijzig sortering
Vergelijkbaar met HTTP Status code 418, heb je ook RFC 1149 / 2549 / 6214:
IP over Avian Carriers :+
In computer networking, IP over Avian Carriers (IPoAC) is a humorously intended proposal to carry Internet Protocol (IP) traffic by birds such as homing pigeons. IP over Avian Carriers was initially described in RFC 1149, a Request for Comments (RFC) issued by the Internet Engineering Task Force (IETF) written by D. Waitzman and released on April 1, 1990. It is one of several April Fools' Day RFCs.

Waitzman described an improvement of his protocol in RFC 2549, IP over Avian Carriers with Quality of Service (1 April 1999). Later, in RFC 6214 released on 1 April 2011, and 13 years after the introduction of IPv6, Carpenter and Hinden published Adaptation of RFC 1149 for IPv6.[1]

[Reactie gewijzigd door P1nGu1n op 14 augustus 2017 09:49]

Toch is de gedachte niet zo gek, als je bedenkt dat veel Cloud service providers de optie bieden om een harde schijf met data op te sturen..
Maar das geen internet protocol. Wel is er bijv. https://en.m.wikipedia.org/wiki/Interplanetary_Internet voor comminicatie in de ruimte, met simpel gezegd helehoge time-outs. Wellicht ook geschikt door postduiven?
met de huidige capaciteit van micro-sd kaartjes die al een halve TB kunnen bevatten kan je zo'n beest al snel op pad sturen met 8TB (naar analogie met Tanenbaum zijn beroemde quote :+ )
Ik dacht 256GB met micro SD.
Ook deze onofficiele 'RFC' is een erg bekende: http://www.darklab.org/jrp.txt

Doet het prima op hackercamps :Y
wat dacht je van rfc3514
0x0 If the bit is set to 0, the packet has no evil intent. Hosts,
network elements, etc., SHOULD assume that the packet is
harmless, and SHOULD NOT take any defensive measures. (We note
that this part of the spec is already implemented by many common
desktop operating systems.)

0x1 If the bit is set to 1, the packet has evil intent. Secure
systems SHOULD try to defend themselves against such packets.
Insecure systems MAY chose to crash, be penetrated, etc.
https://www.ietf.org/rfc/rfc3514.txt
Het is ook van belang om 418 in stand te houden, anders krijgen we helemaal geen geldige berichten meer van https://xkcd.com/1866/ (voor de snel afgeleiden is hier meer informatie https://nl.m.wikipedia.org/wiki/Russells_theepot )

maar om terug te komen op het topic; geek: Tweaker zet espresso via browser
In het kader van efficiŽntie; er is gewoon een lijst met alle April Fools' RFCs.
Mijn persoonlijke favorieten zijn Y10K (uit 1999), IMPS (2000) en Evil Bit (2003).

Overigens zijn deze RFCs niet allemaal alleen maar humoristisch; een aantal hebben wel degelijk een serieuze gedachte erachter zitten.
Wat een humorloze actie zeg; Zolang het niet nodig is kan het toch gewoon als 418 blijven staan :) En dan te zijner tijd kun je altijd nog beslissen om de betekenis te veranderen mocht dat ťcht nodig zijn. Wat mij betreft dus een prima beslissing om deze gereserveerd te maken :)

aanvulling
En wat romellem ook zegt op GitHub bij de GO issue:
Just to be clear, is your argument that when/if the 400 block runs out, we'll want that one extra code available to stretch out the usefulness of the 400 block just a bit further?

Unless I'm reading it incorrectly, the 400 block of HTTP status codes has more than 50 codes available. With the available "space" of the 400 block at more than 50%, this might be a pre-mature optimization for a problem that may never occur (400 block running out of available codes, that is).

Not trying to sound harsh, but I for one like fun little easter eggs that you find throughout a programming career. To me, it shows that everything that goes on to make a computer actually do work is still made by humans, and keeping small slices of that human element is nice (in my opinion). Your argument is sound and logical, but this requested change ever so slightly lowers the "fun-ness" of Go (and potentially NodeJS) in the spirit of engineering robustness. At the end of the day, I have to say I don't think that tradeoff is worth it.

(I appreciate the history lesson though! I always thought 418 was a part of the HTTP/1.x spec; didn't know about the "HTCPCP/1.0" spec. 🙂)

[Reactie gewijzigd door mrdemc op 14 augustus 2017 09:14]

Het is geen humorloze actie. Beste meneer is van IETF dus het is soort van zijn werk. Op het moment dat je dit niet aankaart kan je dus een sick breaking change gaan krijgen op het moment dat 418 wel assigned wordt met iets "belangrijks". Enorm veel applications/frameworks etc hebben deze easteregg namelijk.

Wat hij ook gewoon wel had kunnen doen is 418 officieel aanvragen. Daarmee "fix" je het probleem ook zonder dat je wat jaartjes geschiedenis verpest inclusief het lolletje. Dat is namelijk ook gewoon het issue, we werken met standaarden en 418 is niet een standaard.
418 is een standaard. Alleen niet die van HTTP. En wat je zegt, hij had het ook kunnen aandragen om toe te voegen aan de HTTP standaard ipv te opperen het te verwijderen ;)
Reserveren is wat mij betreft echter een andere en betere oplossing.

[Reactie gewijzigd door mrdemc op 14 augustus 2017 09:54]

Het is geen standaard. Dat is nou juist het probleem. Het is een losstaande grap die een standaard leek te zijn geworden. Iedereen verwijst naar de RFC om te bewijzen dat het een standaard is, maar de RFC zegt zelf:
This document is not an Internet Standards Track specification; it is published for informational purposes.
Hij heeft het juiste gedaan. Het is geen standaard, dus hoort het niet in frameworks. Als het wel gebruikt wordt, moet het een standaard worden. Dus maakte hij issues aan om te kijken wat de reactie zou zijn. Dat vervolgens mensen zo reageren vind ik wat overdreven. Hij heeft enorm veel shit over zich heen gekregen omdat hij een probleem met het volgen van de standaard aankaartte, terwijl het niet gelijk lopen van de standaard en populaire frameworks toch zeker wel een groot probleem is bij de introductie van nieuwe HTTP codes (namelijk dat niet gebruikte codes niet veilig ingezet kunnen worden).
En in dat geval is dus reserveren een prima oplossing zoals nu is gedaan. Sowieso de reden die hij aandroeg ging nergens over. Als de reden was aangedragen zoals jij dat aangeeft was er misschien meer draagkracht geweest, maar dan nog gaf hij zelf ook nog aan dat als mensen het zouden willen implementeren ze een extensie zouden kunnen schrijven, maar dat gaat dus in tegen de argumentatie dat frameworks zich moeten houden aan een standaard zonder deze aan te vullen. En dat vind ik eerlijk gezegd wel erg beknopt. Je kunt niet voor elke toevoeging de standaard gaan wijzigen.
Waarom hoort het niet in frameworks? Zolang 418 niet aan iets anders toegekend is is er geen reden om er niet wat dan ook mee te doen. Een standaard volgen betekent alleen doen dat wat de standaard van je verlangt voor voorgeschreven zaken. Het schrijft je niet voor wat te doen voor niet voorgeschreven situaties. Dus als 418 geen standaard is is het je vrij om te doen wat je wilt.

Als diverse frameworks het leuk vinden om met de niet-officiŽle spec mee te gaan staat dat ze vrij - het doet geen enkele standaard kwaad.
Zolang 418 niet aan iets anders toegekend is is er geen reden om er niet wat dan ook mee te doen.
Die reden is er dus wťl: Als frameworks 418 (of een andere status code die niet in de standaard zit) al geimplementeerd hebben, dan kan de standaard er niks mee doen, omdat de adoptie van een nieuwe code bij alle frameworks een breaking change zal opleveren. Daardoor zal de adoptie van de nieuwe statuscode zeer traag gaan verlopen, in plaats van dat het in een minor versie meegepakt kan worden.
Maar waarom is dat een probleem? Als het een "officiŽle" betekenis krijgt is er toch nog geen ondersteuning voor in software, dus bij het toevoegen van ondersteuning kan dan gelijk de easter egg verwijderd worden. Daarmee is wel een stukje geschiedenis aan z'n einde gekomen, maar dat is weer een ander verhaal. Technisch gezien denk ik niet dat je problemen zult krijgen. Net zo min als met uitbreidingen op HTML die nog niet door iedere browser ondersteund worden.

De meeste http software heeft trouwens al applicatie-specifieke uitbreidingen op de set van standaard codes. Nginx, Apache, IIS, allemaal hebben ze wel iets.
Het is gewoon prettig als iedereen hetzelfde volgt qua 'standaard' of implementatie. Ik hoef niet perse iets te verzinnen maar als iedere vendor een 'unassigned' waarde zelf gaat declareren dat je op een gegeven moment een oerwoud krijgt van implementaties.

Nu is dat zeker niet het geval, maar vele vendors zouden niet binnen een korte termijn 418 kunnen fixen mocht hier een "echte" status voor komen. Dat is voor velen een breaking change.

Het is allemaal niet zo spannend maar het is goed dat er even weer een discussie is geweest en ik hoop dat 418 officieel zn status krijgt :)
Klopt en als je een serieuze tegenhanger voor de 418 nodig hebt pak dan de 422 (Unprocessable Entity).

[Reactie gewijzigd door OruBLMsFrl op 14 augustus 2017 09:15]

Op zich een win-win situatie. De community behoud 418 als easter egg, en de IETF-werkgroepvoorzitter heeft de onduidelijkheid rondom 418 weggenomen door het te laten standaardiseren in plaats van het open te laten. Wel een mooie actie van die Mark, eerst een kant kiezen (zeggen dat 418 weg moet), en dan kijken hoe de community reageert, om vervolgens 418 te pushen naar standaardisatie.
Een errorcode reserveren is lang niet hetzelfde als standaardiseren. Daarbij zou het belachelijk zijn om deze 418 te standaardiseren omdat je dan exact doet wat hier geprotesteerd werd in de eerste plaats.
Is dat niet gewoon "open minded"? ☺️
418 "I'm a Teapot" is niet gestandaardiseerd. Integendeel, 418 is gereserveerd voor toekomstig ander gebruik. Maar met 50 vrije codes is daar geen haast bij.
Met al die IoT is die 418 wel handig :+
Haha idd, in de toekomst krijgen we 4xxx codes:
I'm a fridge
I'm a vacuum cleaner
I'm a lawn mower
I'm a stapler
...
:P
Sja. dit gaat natuurlijk een stuk dieper.

Bijvoorbeeld hoe om te gaan met objecten die anders zijn, maar gegeven randvoorwaarden een bepaalde functie wel legitiem kunnen vervullen - zoals een steen als hamer op de camping.

En als kunstmatige intelligentie mischien ooit echt wat gaat voorstellen, hoe dan om te gaan 'transobjecten' - objecten met bewustzijn die er van buiten als iets uit zien maar die zich van binnen iets anders voelen....

Mischen moet er een internet engineering task force op gezet worden
I'm need a repair :+ express verkeerd geschreven
Ik stel me voor dat dat onze last-line-of-defense is als we ooit worden overgenomen door robot AI's die ons als een bedreiging zien.

De 418 failsafe.
Ach ja we zullen waarschijnlijk meerdere statussen krijgen als de 451.
Als die code bestaat en volgens wat we lezen zinvol is - moet men dat niet afvoeren. Zo simpel is't - het risico dat zaken breken mag men gewoon niet nemen. Men moet dan maar leren nadenken voor men iets invoert - en er tijd voor nemen. Nadien opruimen is afpakken - en dat doet altijd honderd keer meer pijn dan't nooit in te voeren.
Ik knal hackpogingen meestal naar 418 dan kan ik makkelijk filteren in de logs :P
Die man keek gewoon vooruit met alle iot tegenwoordig

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*