मैंने query strings पर प्रतिबंध लगा दिया

• Chris Morgan ने अपनी साइट पर अनधिकृत query strings को पूरी तरह ब्लॉक करने का फैसला किया है, और इसका मौजूदा implementation Caddyfile में है
• वह ?ref=example.com जैसे tracking parameters को URL में जोड़े जाने के खिलाफ हैं; उनका मानना है कि ज़रूरत हो तो Referer header देखा जा सकता है
• ?utm_source=example&utm_*&c.* जैसे UTM parameters उनके अनुसार साइट मालिकों के इस्तेमाल की चीज़ हैं, बाहर से जोड़ने की नहीं
• फिलहाल साइट query strings का बिल्कुल उपयोग नहीं करती, और अगर भविष्य में करेगी तो सिर्फ ज्ञात parameters को ही अनुमति दी जाएगी
• अंतिम URL /no-query-strings तय किया गया, और /%3F को Caddy के try_files rewrite में समस्या होने के कारण नहीं चुना गया

---

अनधिकृत query strings को ब्लॉक करना

• Chris Morgan ने अपनी साइट पर अनधिकृत query strings को पूरी तरह ब्लॉक करने का फैसला किया
• वह ?ref=example.com जैसे tracking parameters को अपनी URL में जोड़े जाने के खिलाफ हैं; उनका मानना है कि ज़रूरत हो तो Referer header देखा जा सकता है
• ?utm_source=example&utm_*&c.* जैसे UTM parameters उनके अनुसार साइट मालिकों के इस्तेमाल की चीज़ हैं, बाहर से जोड़ने की नहीं
• फिलहाल यह साइट query strings का बिल्कुल उपयोग नहीं करती, और अगर भविष्य में करेगी तो सिर्फ ज्ञात parameters को ही अनुमति दी जाएगी
• पहले stylesheet URLs में ?t=…, ?h=… जैसे cache invalidation URLs इस्तेमाल होते थे, लेकिन उनका मानना है कि ऐसे requests टूट भी जाएँ तो ठीक है
• यह ब्लॉक अभी Caddyfile में implement किया गया है

URL चुनने की प्रक्रिया

• /? इस्तेमाल करने की योजना

  • शुरुआत में वह इस पेज को https://chrismorgan.info/? पर प्रकाशित करने के लिए काफी आकर्षित थे
  • खाली path और खाली query का यह रूप आम धारणाओं को तोड़ता और कुछ tools को मुश्किल में डाल सकता था
  • ऐसा लगा कि curl command line पर आखिर का question mark गलत तरीके से हटा देता है, हालांकि library usage की उन्होंने जाँच नहीं की
  • आखिरकार उन्होंने path की अवधारणा का सम्मान करने और लोगों के प्रति उदार रहने का फैसला किया, खासकर क्योंकि उनके अनुसार Caddy को पहले ही काफी असहज दिशा में धकेला जा चुका था

• /%3F इस्तेमाल करने की योजना

  • अगली योजना इसे /%3F पर प्रकाशित करने की थी, जहाँ path ? हो और query न हो
  • लेकिन Caddy में try_files rewriting जुड़ने पर इसे संभाल नहीं पाने की समस्या थी
  • संबंधित issue यह है: try_files breaks paths containing characters like ? and %

• अंतिम चयन

  • अंतिम URL /no-query-strings तय किया गया
  • /? या /%3F को बाद में query strings से जुड़ी किसी और उपयोगिता के लिए रखा जा सकता है

[GN⁺]

Hacker News की टिप्पणियाँ

• जिज्ञासा में मैंने HTML और URL के W3C standards फिर से देखे, और हैरानी की बात यह थी कि percent-encoding के अलावा query string format की कोई अलग परिभाषा नहीं थी
  query string को “form-urlencoded”[0] query string के साथ गड़बड़ किया जा सकता है, लेकिन वह interoperable formats में से सिर्फ एक है। आम तौर पर query string, URL में ? के बाद आने वाली कोई भी percent-encoded string[1] होती है, और यह HTML URL object की एक और property है जिसका इस्तेमाल response बनाने में किया जा सकता है
  URLSearchParams object, form-urlencoded parser से query string parse करने का परिणाम है, लेकिन यह JavaScript के लिए सिर्फ एक interoperability layer है
  सच कहूँ तो standards देखने से पहले मैं इसके खिलाफ तर्क देने को तैयार था, लेकिन standards काफ़ी स्पष्ट निकले। अनपेक्षित query strings पर 404 से जवाब देना भी उचित हो सकता है। query string, path जितना ही URL API का हिस्सा है, और path में मनमाना string जोड़ना अच्छा नहीं है और undefined behavior है — यह बात ज़्यादातर लोग मानेंगे
  [0]: https://url.spec.whatwg.org/#application/x-www-form-urlencod...
  [1]: https://url.spec.whatwg.org/#url-class

  • पहले CMS या forums में सिर्फ एक index.php रखना और पूरा routing query string से संभालना काफ़ी आम था
    बेशक यह form-urlencoded format होता था, लोग पूरी तरह जंगली नहीं थे। इसलिए index.php?p=home, index.php?p=shop, या index.php?action=showthread&forum=42&thread=17976 जैसे URL दिखते थे। ऐसे ढाँचे में यह तुरंत साफ़ हो जाता है कि अनजान query parameters पर 404 ही सही response है
    सच तो यह है कि आज भी बहुत-सी sites ऐसे ही चलती हैं, बस SEO के लिए Apache/nginx rewrite rules के पीछे छिपा देती हैं
  • सही है, URL में semantics बहुत ज़्यादा नहीं हैं। path को hierarchical data और query को non-hierarchical data के लिए माना जाता है, इस पर मज़बूत convention भी है, और कुछ libraries इसे support या enforce भी करती हैं, लेकिन असली rules नहीं हैं
    आखिरकार URL बस एक string है, जिसे server अपनी मर्ज़ी से process करता है
    इस चर्चा की सबसे मज़ेदार बात यह है कि 404 के side effects की चिंता करते हुए लोग यह पूरी तरह भूल गए कि web के इतिहास में path कितने लंबे समय तक अर्थहीन रहा है। अब path जीत गया है। /item?id=… जैसे URL से नई शुरुआत अब लगभग नहीं होती। अच्छा है!
  • मुझे लगता है कि साधारण 400 बेहतर होगा। page नहीं मिला ऐसा नहीं है, बल्कि एक ऐसा request भेजा गया है जिसे अनुमति नहीं है
    इसका मतलब निकलता है “request ठीक करो और फिर कोशिश करो”, और मैं अपने API में भी यही इस्तेमाल करता हूँ। 406 की बजाय इसे पसंद करने का कारण यह है कि समस्या मेरी तरफ़ से process न कर पाने की नहीं है। अगर किसी ने query string में कुछ जोड़कर चीज़ तोड़ने की कोशिश की या docs के मुताबिक request नहीं बनाया, तो ज़िम्मेदारी requester की है
  • No-Vary-Search proposal यह specify करने देता है कि query का कौन-सा हिस्सा relevant है
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
    उदाहरण के लिए caching के नज़रिए से url?a=b&c=d को url?c=d&a=b के बराबर माना जा सकता है
  • standards बस वही हैं जो किसी ने कहीं लिख दिया और जिसे व्यापक रूप से स्वीकार कर लिया गया
    बहुत-सी ऐसी conventions हैं जो कभी formal standard के रूप में document नहीं हुईं, लेकिन उन्हें न मानो तो बहुत कुछ टूट जाता है; और बहुत से ऐसे “standards” भी हैं जिन्हें शब्दशः मानो तो मूर्ख लगो
    इस मूल लेख के मामले में नुकसान सिर्फ उन लोगों को होगा जो उस site पर जाना चाहते हैं, और शायद वे browser में back दबाकर अपने काम में लग जाएँगे। इतना नुकसान स्वीकार करना है या नहीं, यह वही तय करे। लेकिन सिर्फ इसलिए कि किसी standard ने मना नहीं किया, वह परिभाषा के हिसाब से allowed नहीं हो जाता; और उल्टा, किसी standard ने मना कर दिया तो भी वह अचानक हर हाल में disallowed नहीं हो जाता

• मेरी समझ से लेखक इस बात से चिढ़ा हुआ लगता है कि दूसरी websites उसकी site की links में ?ref=origin.com जैसी query string जोड़ रही हैं
  मुझे समझ नहीं आता कि इससे origin site को क्या फ़ायदा और लेखक की site को क्या नुकसान होता है
  दोनों तरफ़ का व्यवहार ही पूरी तरह उलझाऊ लगता है
  जब आप ad campaign चलाते हैं, तब Google का UTM query string जोड़कर यह track करना समझ में आता है कि user किस campaign से आया। वहाँ source और destination सहयोग में होते हैं। लेकिन यहाँ source बिना किसी वजह कुछ जोड़ रहा है। क्यों?

  • origin site के नज़रिए से यह marketing है। तर्क यह है कि लेखक ref query string में देखकर कि xyz.com से काफ़ी traffic आ रहा है, सोच सकता है कि उस site पर advertising या partnership की जा सकती है
    ईमानदारी से कहूँ तो niche/startup sites के लिए यह काफ़ी उपयोगी हो सकता है। web analytics में ऐसी values देखकर शुरू हुई बातचीत के दोनों पक्ष मैंने देखे हैं; एक बार incoming traffic देखकर मैंने खुद संपर्क किया था, और दूसरी बार जिस site को मैंने link किया था वहीं से मुझसे संपर्क हुआ। दोनों बार नतीजा mutually beneficial partnership रहा
    privacy वाली बात कुछ हद तक समझता हूँ, लेकिन यह standard Referer header से ज़्यादा जानकारी नहीं देता। Simple Analytics/Plausible जैसे analytics tools इस्तेमाल करो तो यह बस कहीं ज़्यादा साफ़ दिखाई देता है
  • मैं आम तौर पर tracking के खिलाफ हूँ। tracking अक्सर व्यक्ति के हित के खिलाफ जाती है
    query string जोड़ना अक्सर tracking के लिए इस्तेमाल होता है। सिर्फ यह देख लेना ही काफ़ी है कि Firefox में “copy clean link” या कुछ UTM parameters को पहले से हटा देने वाली Enhanced Tracking Protection जैसी features मौजूद हैं — इससे साफ़ है कि बहुत-से लोग यह नहीं चाहते
    कुछ sites उस व्यवस्था में ख़ुशी-ख़ुशी हिस्सा लेती हैं जिसे मैं हल्के अंदाज़ में “tracking economy” कहता हूँ। ऐसा इसलिए, क्योंकि receiver logs में देखकर कि बहुत लोग किसी खास site से आए हैं, उस site के पक्ष में कुछ कर सकता है
    query string को ठुकराना उसी व्यवस्था के खिलाफ़ एक सीधा विरोध है
  • अगर कोई popular website वह parameter जोड़ दे, तो target site आसानी से जान सकती है कि traffic कौन भेज रहा है, और वही sponsorship या affiliate deals की बुनियाद बन सकता है

• “एक छोटा, decentralized, self-hosted web console जो website visitors को independent personal website operators की community द्वारा सुझाई गई दिलचस्प websites और pages खोजने देता है” — यह पढ़कर याद आया कि पहले इसे Webring कहते थे। बस इतना चमकीला नहीं था
  open source application framework बनाते समय जिन समस्याओं से जूझना पड़ा, उनमें से एक यह थी कि FastCGI इस्तेमाल करने वाली hosting Auth header को सम्मान नहीं देती थी, इसलिए token को query में भेजना मजबूरी थी। web address copy/paste करते समय token शामिल हो जाना बहुत बुरा अनुभव था। शायद अब तक यह ठीक हो गया हो
  backend में, जिसे मैं control करता हूँ और जिसे सबके सामने खोलने की ज़रूरत नहीं, मैं header का इस्तेमाल करता हूँ

  • क्या आपका मतलब यह है कि open source application framework को fcgi-app में लिखने पर, उदाहरण के लिए Apache ने Auth header बिगाड़ दिया?
    अगर आप यह हिस्सा थोड़ा विस्तार से समझा सकें तो अच्छा होगा। तकनीकी रूप से यह ऐसा लग रहा है जैसे PARAM record उम्मीद के मुताबिक value दे ही नहीं रहा

• उसने लिखा, “इसलिए मैंने इस site पर एक blanket ban आज़माने का फैसला किया: unauthorized query strings नहीं,” लेकिन उसकी site लगता है request में query string होने पर 414 लौटाती है, और मेरे हिसाब से यह ग़लत चुनाव है
  अगर यह विरोध users की तरफ़दारी के लिए है, तो उस user को क्यों सज़ा दी जाए जिसके पास शायद उस string पर कोई control ही नहीं था?
  क्या इसे ऐसे signal की तरह इस्तेमाल नहीं किया जा सकता था जो user को बताता कि browser tools वगैरह से वह खुद यह फ़ैसला ले सकता है?

  • “आप कह सकते हैं कि मैं 414 URI Too Long का दुरुपयोग कर रहा हूँ। मेरा जवाब है: यही इसे और मज़ेदार बनाता है। जिन दूसरे विकल्पों पर मैंने सोचा, वे ये थे:
    400 Bad Request, एक सामान्य client error code होने के नाते फिट तो बैठता है, लेकिन मज़ेदार नहीं है
    402 Payment Required, सच कहूँ तो अगर कोई पैसे दे कि query string वाले कुछ खास URL काम करें, तो मैं तैयार हूँ
    404 Not Found, लेकिन इसमें side effects पैदा होने की संभावना बहुत ज़्यादा है, और यह वह भाव नहीं देता जो मैं चाहता हूँ: ‘request format ग़लत है’
    303 See Other बिना Location header के। आजकल यह बहुत दुर्लभ है, लेकिन वैध है। कम-से-कम RFC 2616 में तो था (“The different URI SHOULD be given by the Location field in the response”). लेकिन 7231 और 9110 में भाषा बदलकर Location header की मौजूदगी मान ली गई (“… as indicated by a URI in the Location header field”). जबकि 301, 302, 307, 308 कहते हैं “the server SHOULD generate a Location header field”. खैर, Location header के बिना See Other भी मुझे काफ़ी ठीक लगता है। लेकिन URI Too Long ज़्यादा मज़ेदार था”
    https://chrismorgan.info/no-query-strings?foo
  • बहुत पुरानी बात है, इसलिए धुंधला याद है, लेकिन लगता है PLSQL server pages के किसी version में अनजान query strings देने पर 500 लौटता था

• “आप कह सकते हैं कि मैं 414 URI Too Long का दुरुपयोग कर रहा हूँ। मेरा जवाब है: यही इसे और मज़ेदार बनाता है। जिन दूसरे विकल्पों पर मैंने सोचा…” — इस हिस्से में एक और विकल्प 418 I'm a teapot भी हो सकता था। आखिर teapot आम तौर पर query strings support नहीं करते

  • सीधा 400 “Bad Request” या 403 “Forbidden” भी बचाव योग्य विकल्प लगते हैं। यह थोड़ा अजीब है कि URI parameters के लिए dedicated error response code नहीं है
    कुछ codes ऊपर-ऊपर से सही लगते हैं, लेकिन गहराई से देखें तो नहीं हैं: 406 “Not Acceptable” content negotiation headers पर आधारित है, 409 “Conflict” ज़्यादातर WebDAV requests के लिए है, और 411, 422, 431 वगैरह भी अलग खास परिस्थितियों के लिए हैं जिनका इससे लेना-देना नहीं
    300 या 500 series errors भी अनुपयुक्त हैं। यह न तो redirection है, न server-side failure, बल्कि client-side request problem है
    teapot या too long ही सबसे अच्छे उम्मीदवार लगते हैं
  • बिल्कुल support करते हैं। उदाहरण के लिए ऊपर से धागा डालकर teapot का water level पूछा जा सकता है, और धागा kettle के चारों ओर लपेटकर उसकी circumference भी पूछी जा सकती है
  • लेकिन मैं teapot नहीं हूँ। मुझे चाय पसंद नहीं

• इस लेख और Chris के लेख की tone देखकर लगता है कि ऐसे query parameters शामिल करना हानिकारक है, लेकिन मुझे समझ नहीं आता कि यह नुकसान कैसे पहुँचाता है
  कुछ URLs टूट सकते हैं, यह बात समझ में आती है, और सिर्फ वही वजह भी इसे न करने के लिए काफ़ी है। फिर भी यह मामूली असुविधा जैसी लगती है। क्या कोई समझा सकता है?

  • इसे देखने के तीन नज़रिए हैं
    तकनीकी शुद्धतावाद के नज़रिए से, convention के तौर पर स्वीकार होने पर भी URL को modify करना तकनीकी रूप से ग़लत है। URL को मूलतः opaque value की तरह treat करना चाहिए
    सामाजिक नज़रिए से यह tracking है, और sibling comment threads इसे अच्छी तरह समझा रही हैं, इसलिए मैं दोहराऊँगा नहीं
    noise के नज़रिए से, यह user के लिए महत्वपूर्ण हिस्सों को छिपाता है और URL को इतना मुश्किल और जटिल बनाता है कि आम लोग URL पर ध्यान देना ही छोड़ दें
  • HTTP Referer header से जुड़ी समस्याएँ पढ़ेंगे तो समझ आएगा कि लोग इसे क्यों नापसंद करते हैं: https://en.wikipedia.org/wiki/HTTP_referer
    बहुत-सी वजहें हो सकती हैं कि आप नहीं चाहते कि जिस site पर आप जा रहे हैं, उसे यह पता चले कि आप उससे पहले कहाँ थे। मूलतः यह visited site के साथ आपका browsing history साझा करने जैसा है
    इसी वजह से HTTP Referer header में भेजे जाने की conditions पर रोक, और feature को पूरी तरह बंद कर देने जैसी कई updates आईं
    वही जानकारी URL parameters में जोड़ना इन मौजूदा नियमों और opt-out सुविधाओं को bypass कर देता है। standard का इस्तेमाल करना चाहिए
  • इसकी बिल्कुल कोई वजह नहीं है। उस जानकारी को बस discard कर देना चाहिए
    यह बेहद अतिवादी रुख़ है, और यह ठीक से समझा नहीं पाता कि इससे web कैसे बेहतर होता है
  • दिलचस्प बात यह है कि ऐसी sites में से कई के पास search feature ही नहीं होती। search एक महत्वपूर्ण accessibility feature है, और query string का बिल्कुल साफ़ और वैध use case भी
  • कुछ वजहें हैं। user ने tracking के लिए consent नहीं दिया, और ऐसे query parameters tracking information हैं। साथ ही site admin यह नहीं चाह सकता कि incoming traffic track हो
    दूसरी बात समझना कठिन हो सकता है, लेकिन मेरे मामले में मैं कभी नहीं चाहता कि logs में ऐसी जानकारी रहे जो users को नुकसान पहुँचा सके
    व्यक्तिगत तौर पर, जब मुझे कोई link copy करके message में भेजना हो और उसमें मूल URL से दोगुना लंबा tracking code चिपका हो, तो मुझे बहुत चिढ़ होती है। फिर या तो मुझे उसे हाथ से साफ़ करना पड़ता है, या सामने वाला screen भर के random characters देखकर सोचता रह जाए कि यह क्या है
    यह user privacy का उल्लंघन है, user experience भी ख़राब करता है, और सबसे बढ़कर, किसी ने इसे माँगा ही नहीं

• क्योंकि मूल source पर HN में अब तक चर्चा नहीं हुई थी, इसलिए मैंने उस link (https://chrismorgan.info/no-query-strings) को सबसे ऊपर रखा और response post का link (https://susam.net/no-query-strings.html) ऊपर के description में खिसका दिया
  दोनों अच्छे हैं, लेकिन मूल लेख को प्राथमिकता देना ज़्यादा fair लगा

• मेरे आसपास अब भी GET query इस्तेमाल करने वाली ज़्यादातर sites स्थानीय सरकारों की tax collection sites हैं, जो login के बाद variables को इधर-उधर पास करती हैं
  सच कहूँ तो वह routing parser, जो GET request का ही काम करता है लेकिन असली URL होने का नाटक करता है, उससे कहीं ज़्यादा झुंझलाहट होती है

• query strings उपयोगी हैं। file search या दूसरी तरह की dynamic files जैसे मामलों में इनका काम है, लेकिन जिस URL को query string की उम्मीद नहीं है, उसमें इन्हें नहीं जोड़ना चाहिए
  इसलिए UTM जैसी चीज़ें जुड़ी हुई requests को reject करना सही लगता है
  अगर query string अपेक्षित नहीं थी लेकिन मौजूद है, तो response के तौर पर 404 सबसे उचित लगता है, और 400 भी ठीक हो सकता है