1 पॉइंट द्वारा GN⁺ 2024-10-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • HTTP 418 I'm a teapot एक status response code है जिसमें सर्वर यह कहकर अनुरोध अस्वीकार करता है कि वह स्थायी रूप से चायदानी है, इसलिए coffee नहीं बना सकता
  • अगर coffee/tea दोनों के लिए बनी kettle अस्थायी रूप से coffee उपलब्ध नहीं करा पा रही हो, तो 418 नहीं बल्कि 503 Service Unavailable लौटाना चाहिए
  • यह code Hyper Text Coffee Pot Control Protocol से निकला April Fool's joke है, और 1998 व 2014 में परिभाषित protocols से जुड़ा है
  • मूल रूप से यह RFC 2324 का joke code था, लेकिन व्यापक रूप से deploy हो जाने के कारण RFC 9110 में इसे आधिकारिक तौर पर reserve किया गया
  • कुछ websites उन requests के लिए 418 इस्तेमाल करती हैं जिन्हें वे process नहीं करना चाहतीं, जैसे automated queries; निकट भविष्य में इसे non-joke अर्थ नहीं दिया जा सकता

HTTP 418 किन परिस्थितियों को दर्शाता है

  • 418 I'm a teapot status response code का मतलब है कि server coffee बनाने से इनकार कर रहा है
  • इनकार की वजह यह है कि server स्थायी रूप से चायदानी है
  • अगर coffee/tea दोनों के लिए बनी kettle अस्थायी रूप से coffee उपलब्ध नहीं करा सकती, तो 503 लौटाना चाहिए

April Fool's protocol से शुरू हुआ code

  • यह status code Hyper Text Coffee Pot Control Protocol को refer करता है
  • यह protocol 1998 और 2014 में April Fool's joke के रूप में define किया गया था
  • 418 मूल रूप से RFC 2324 में April Fool's joke के तौर पर define किया गया code था

RFC 9110 में reserve किए जाने की वजह

  • 418 status code joke के रूप में व्यापक रूप से deploy हो चुका था, इसलिए RFC 9110 में इसे आधिकारिक तौर पर reserve किया गया
  • इस reservation की वजह से निकट भविष्य में 418 को non-joke meaning assign नहीं किया जा सकता

वास्तविक इस्तेमाल का तरीका

  • कुछ websites उन requests के लिए 418 response इस्तेमाल करती हैं जिन्हें वे process नहीं करना चाहतीं
  • इसका प्रतिनिधि उदाहरण automated queries जैसी requests हैं

संबंधित specifications और reference material

1 टिप्पणियां

 
GN⁺ 2024-10-30
Hacker News टिप्पणियाँ
  • अगर समय हो तो उस बहस को पढ़ना दिलचस्प है, जब mnot ने तकनीकी रूप से सही न होने के कारण कई भाषाओं और implementations से 418 status code हटाने की कोशिश की थी
    https://github.com/nodejs/node/issues/14644
    https://github.com/golang/go/issues/21326
    आखिरकार किसी ने http://save418.com/ जैसी साइट भी बना दी

    • 418 की बात सुनकर मुझे अपनी पुरानी नौकरी की वह बहस याद आ जाती है, जिसमें application में emoji डालने को लेकर विवाद हुआ था
      जैसे काम सफल होने पर rocket emoji डालने का प्रस्ताव था, और मैं इसके खिलाफ था। एक बार ऐसी चीजें डालनी शुरू कर दो तो हर किसी की अपनी पसंद होने लगती है, फिर कहाँ और डालें, कहाँ न डालें, इस पर लगातार बहस चलती रहती है, और बिल्कुल अलग विषयों की चर्चा में भी यह घुस आती है
      खासकर अगर user behavior tracking से यह न देखा जाए कि metrics वाकई बेहतर हुए या नहीं, तो मुझे communication cost का बढ़ना बड़ा नुकसान लगता है। यह professional होने का सवाल नहीं था; बस कुछ लोगों को यह पसंद था, कुछ को नहीं, और कुछ को फर्क ही नहीं पड़ता था, लेकिन इस तरह की subjectivity बार-बार छोटे friction पैदा करती थी
  • मैं गैर-वाजिब bot requests का जवाब 418 से देता हूँ। थोड़ा मज़ेदार भी है और logs filter करना भी आसान हो जाता है
    Nginx config का उदाहरण इस तरह है

    Nothing to hack around here, I’m just a teapot:

    location ~* .(?:php|aspx?|jsp|dll|sql|bak)$ {
    return 418;
    }
    error_page 418 /418.html;
    उदाहरण: https://FreeSolitaire.win/wp-login.php
    वैसे, /wp-login.php WordPress का login URL है, और कमजोर WordPress इंस्टॉलेशन खोजने वाले बॉट अक्सर इसे अंधाधुंध request करते हैं

    • कम मज़ेदार है, लेकिन 444 शायद ज़्यादा तेज़ हो: https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#...
      मैं जानना चाहूँगा कि सिर्फ ऐसे URL request करने की वजह से उस address को स्थायी रूप से block कैसे किया जाए
  • लिंक किया गया मूल RFC भी पढ़ने लायक है: https://www.rfc-editor.org/rfc/rfc2324

    • मुझे ऐसे RFC documents पसंद हैं। मैं अभी CCSDS documents के साथ काम कर रहा हूँ, और RFCs की तुलना में वे पूरी तरह बिखरे हुए लगते हैं
      जब TCP या TLS कैसे काम करते हैं, यह documents से पढ़ते हैं तो लगता है कि यह अनुभव और दृष्टि वाले experts ने लिखा है, जबकि CCSDS documents ऐसे लगते हैं मानो उन्हें ऐसे bureaucrats ने लिखा हो जिन्होंने जीवन में कभी code की एक line भी न लिखी हो
  • 2010 के दशक में, “sir, this is a wendy's” के Facebook meme के तौर पर बहुत लोकप्रिय होने से पहले, यह nerdy random joke जैसा था

    • ऐसे jokes बहुत थे, और xkcd की वजह से सबको “the game” से मुक्ति भी मिली थी
  • पहले किसी वजह से HTTP/2 RFC पढ़ते समय मिला यह शानदार हिस्सा हमेशा याद रहता है
    “429 Too Many Requests” के standardize होने से पहले Twitter API request rate limiting पर non-standard 420 status code और “Enhance Your Calm” वाक्य लौटाता था। समझ में आने वाली वजहों से उन्होंने इसे बंद कर दिया, लेकिन वह phrase चुपके से HTTP/2 में पहुँच गया
    https://datatracker.ietf.org/doc/html/rfc7540#section-7
    0xb item में excessive load के कारण connection terminate करने वाला phrase सचमुच ENHANCE_YOUR_CALM है। हर बार देखकर हँसी आती है

  • असली services में जब भी यह error code मिला, बहुत झुंझलाहट हुई
    कोई smart दिखने के लिए 429 या 503 जैसे सही status code की जगह इसे लौटाता है, और उसकी वजह से कई HTTP status code parsers टूट जाते हैं
    यह न चतुर है, न मज़ेदार; सच कहूँ तो उबाऊ है। मुझे पता है कि मैं मज़ेदार इंसान नहीं हूँ, लेकिन काम भी तो करने हैं

    • अगर parser spec में मौजूद error code को handle नहीं कर सकता, तो वह parser की समस्या है
    • अगर कोई HTTP implementation 418 को ही miss कर दे, तो फिर वह और क्या-क्या miss कर रहा होगा, यह सोचने पर मजबूर करने वाली एक थोड़ा संदिग्ध लेकिन शिक्षाप्रद कहानी है
      कहा जाता है कि Van Halen ने अपने concert contract में लिखा था कि backstage में M&M रखी जाए, लेकिन सारे भूरे वाले हटा दिए जाएँ
      vocalist David Lee Roth ने अपनी autobiography ‘Crazy From the Heat’ में समझाया कि यह बचकानी मांग नहीं थी, बल्कि यह तुरंत जाँचने का एक चतुर तरीका था कि venue सुरक्षित है या नहीं
      अगर venue ने भूरे M&M रख दिए, तो इसका मतलब था कि उन्होंने contract ठीक से नहीं पढ़ा, और संभव है कि बिजली आपूर्ति या stage load जैसी अधिक खतरनाक चीजों में भी गलती की हो
      https://www.metaltalk.net/chris-dale-myth-busting-the-van-ha...
  • पहले Sonatype Nexus ने artifact upload के दौरान 418 लौटाया था, और यह बिल्कुल प्रभावशाली नहीं लगा

    • मज़ाक को अलग रखें तो सोचता हूँ कि आखिर 418 ही क्यों चुना गया। कभी-कभी लगता है जैसे HTTP codes में कोई missing error होना चाहिए, इसलिए developers खुद कुछ बना लेते हैं या 418 जैसे कम टकराव वाले code को reuse कर लेते हैं
      HTTP status code misuse हर बार देखकर हैरानी होती है। मेरा पसंदीदा उदाहरण एक ऐसा service था जो “200 OK” लौटाने के बाद response body में सिर्फ text के रूप में “500” डाल देता था
      मैंने कहा कि API error होने पर 200 की जगह 500 error लौटाइए, तो उन्होंने headers नहीं, response के अंदर वाले 200 को ही बदल दिया। “200 Created” भी developer की समझ की कमी या किसी अजीब framework constraint का काफी मजबूत संकेत है
    • यह किसी Serious Enterprise™ Solution® से आया था, यह बात अपने आप में अजीब है
  • authentication service में हम 418 response code का इस्तेमाल करते हैं
    इससे यह अलग करने में मदद मिलती है कि token expiry के कारण invalid है या किसी और वजह से। अगर 418 है, तो हम मान लेते हैं कि access token को अपने-आप refresh किया जा सकता है। यह काफ़ी harmless है, और यह कोई security measure भी नहीं है

  • संबंधित चर्चाएँ
    2020, 153 points·118 comments: https://news.ycombinator.com/item?id=24206899
    2021, 193 points·108 comments: https://news.ycombinator.com/item?id=28541327
    2023, 206 points·189 comments: https://news.ycombinator.com/item?id=36090344

  • ऐसे threads में आम तौर पर कोई न कोई iiNet coffee cam का लिंक डाल देता है। यह रहा
    https://coffeecam.iinet.net.au/coffee/history/

    • iiNet शायद मेरी अब तक की नौकरियों में सबसे बेहतरीन जगह थी, जहाँ मैंने सबसे ज़्यादा सीखा और सबसे ज़्यादा मज़ा भी किया
      coffeecam भी प्यारा था, और coffeecam को ज़्यादातर संभालने वाले acb आसपास American snacks भी बेचते थे। कम-से-कम जब मैं Hay Street में काम करता था, तब तो ऐसा ही था