Query string तोड़ें

किसी query string में एक ही नाम कई बार आ सकता है, और `tag=a&tag=b` किसी बहु-चयन का सामान्य रूप है। जो उसे किसी शब्दकोश में लाद देता है वह आख़िरी मान को छोड़कर सब खो देता है — और यह ऐसा डेटा-नुक़सान है जिसकी कोई चेतावनी नहीं आती।

यहाँ हर उपस्थिति की अपनी पंक्ति है। यह सुनने से ज़्यादा मायने रखता है, क्योंकि framework आपस में सहमत नहीं हैं: PHP `tag[]=a&tag[]=b` चाहता है, Rails कोष्ठकों को दूसरे ढंग से पढ़ता है और Express के कई तरीक़े हैं। अगर कोई बहु-चयन आधा-अधूरा पहुँच रहा है, तो वजह लगभग हमेशा यहीं है।

इनपुट का पूरा पता होना ज़रूरी नहीं। शुरू के प्रश्नचिह्न के साथ या उसके बिना कोई query string उतनी ही अच्छी तरह चलती है जितनी पूरी URL, जिसमें से query निकाल ली जाती है — यह सुविधाजनक है, क्योंकि किसी analytics निर्यात या किसी लॉग से जो कॉपी होता है वह शायद ही कभी पूरी पंक्ति होती है।

पहचान इससे होती है कि कोई प्रश्नचिह्न या बराबर का चिह्न दिखता है या नहीं। जिस इनपुट में इनमें से एक भी न हो वह query string नहीं बल्कि सामान्य टेक्स्ट है, और उसे वैसा नहीं बरता जाता — नियम सुनने में ज़ाहिर लगता है और उसके बिना पूरी URL एक ही पैरामीटर-नाम की तरह पढ़ी जाती।

Query string में `+` परंपरागत रूप से स्पेस का मतलब रखता है। वह `application/x-www-form-urlencoded` से आता है, यानी उस रूप से जिसमें HTML के फ़ॉर्म भेजते हैं, और वह URL के मौजूदा विनिर्देश से पुराना है; बचा इसलिए हुआ है कि फ़ॉर्म आज भी उसका इस्तेमाल करते हैं।

नतीजा एक जाल है: किसी मान के भीतर असली plus को `%2B` लिखना पड़ता है, वरना वह ग़ायब हो जाता है। यह सबसे ज़्यादा अंतरराष्ट्रीय रूप में लिखे मोबाइल नंबरों और subaddress वाले ईमेल पतों पर लगता है — `+91` से शुरू होने वाला भारतीय नंबर पढ़े जाते समय ` 91` बन जाता है, और भेजना ऐसी जगह विफल होता है जहाँ कोई देखता नहीं।

पैरामीटर के रूप में रखी redhirect की मंज़िल भीतर धँसी encoding का सबसे आम मामला है: `next` का मान ख़ुद एक URL है जिसकी तिरछी लकीरें और प्रश्नचिह्न escape होने चाहिए ताकि बाहरी पते का ढाँचा न टूटे। Decode होने पर वह फिर से पढ़ने लायक़ पता बन जाती है।

यहाँ यह भी दिखता है कि किसी ने दो बार encode किया है या नहीं: अगर decode हुए मान में अब भी `%2F` बचा है, तो इनपुट दो बार किसी encoder से गुज़र चुका था। और जिसे ऐसी redirect मिलती है उसे मंज़िल को मंज़ूर host की सूची से मिलाना चाहिए — खुली redirect ठीक इसी बिंदु पर जन्म लेती हैं।

डिफ़ॉल्ट रूप से मान decode होते हैं, जो पन्ने का मक़सद ही है। कच्चे रूप वाला स्विच सजावट नहीं है: अगर query string पर कोई हस्ताक्षर निकाला जा रहा है तो गिनती में encode की गई ठीक-ठीक लिखावट आती है, और `%20` तथा `+` का फ़र्क़ मंज़ूरी और इनकार के बीच का फ़ैसला कर देता है।

दोहरी encoding ढूँढ़ने के लिए भी वह उतना ही काम का है। कच्चे मान में पड़ा `%2520` इस बात का पक्का सबूत है कि शृंखला में कहीं पहले से encode हुए मान को दोबारा encode किया गया है; decode हुए नतीजे में उसका सिर्फ़ एक संदिग्ध `%20` बचता है।

हिंदी खोज-शब्द वाला पैरामीटर कच्चे रूप में percent शृंखलाओं की लंबी क़तार जैसा दिखता है, क्योंकि देवनागरी के हर अक्षर के लिए तीन शृंखलाएँ बनती हैं: «क» `%E0%A4%95` है। पाँच अक्षरों का शब्द वहाँ पैंतालीस अक्षर घेरता है, और इसी से भारतीय साइटों की खोज-URL इतनी लंबी दिखती हैं।

यह जानने लायक़ है क्योंकि गिनती करने वाले तंत्र यहीं टकराते हैं: पैरामीटर की लंबाई की सीमाएँ, लॉग की पंक्ति-सीमाएँ और कुछ analytics औज़ारों की काट-छाँट सब बाइट या अक्षर गिनते हैं, अंग्रेज़ी शब्द नहीं। जब कोई हिंदी खोज-शब्द रिपोर्ट में कटा हुआ पहुँचे, तो कच्चा रूप ही दिखाता है कि कटाव कहाँ हुआ — और आम तौर पर वह किसी अक्षर की तीन शृंखलाओं के बीच में हुआ होता है।

`utm_source`, `utm_medium`, `utm_campaign`, `utm_term` और `utm_content` Urchin से आते हैं, उसी औज़ार से जिससे Google Analytics निकला — नाम वहीं से है। सर्वर पर वे कुछ नहीं करते: वे टेक्स्ट हैं जिन्हें ब्राउज़र में कोई माप वाली स्क्रिप्ट पढ़ती है।

चूँकि वे कुछ करते नहीं, कोई लिंक आगे भेजते समय उन्हें बिना नतीजे के हटाया जा सकता है, अगर आप भेजने वाले के आँकड़ों में अपना अग्रेषण मिलाना नहीं चाहते। और चूँकि वे पते में रहते हैं, वे इतिहास में, साझा लिंक में और bookmark में पहुँच जाते हैं — यही वजह है कि newsletter के कुछ लिंक बेतुके ढंग से लंबे होते हैं।

पते सर्वर के लॉग में, ब्राउज़र के इतिहास में, अगले क्लिक के referrer हेडर में और अक्सर रास्ते के किसी proxy के लॉग में पहुँच जाते हैं। इसलिए किसी पैरामीटर में रखा पासवर्ड, session कुंजी या token कम से कम चार ऐसी जगहों पर सहेजा जा चुका होता है जिनके बारे में किसी ने सोचा नहीं था।

पुष्टि और पासवर्ड रीसेट के लिंक के लिए, जहाँ इससे बचने का कोई तरीक़ा नहीं, नियम यह है: छोटी अवधि, एक ही बार का इस्तेमाल, और खुलते ही उसे पते से हटा देना। अगर यहाँ आपको कोई मान रहस्य जैसा दिखे, तो खोज वही है — यह नहीं कि उसे decode किया जा सका।

बिना मान वाला `?debug`, ख़ाली मान वाला `?a=` और ग़ैरमौजूद पैरामीटर तीन अलग चीज़ें हैं, और framework उन्हें अलग-अलग बरतते हैं: कभी ख़ाली स्ट्रिंग की तरह, कभी `true` की तरह, कभी ग़ैरमौजूद की तरह। यहाँ उन्हें वैसा ही दिखाया जाता है जैसे वे स्ट्रिंग में हैं।

यह लगने से ज़्यादा प्रासंगिक है। सिर्फ़ नाम के रूप में भेजा गया कोई स्विच कुछ भाषाओं में ख़ाली मान बनकर पहुँचता है और वहाँ असत्य की तरह मूल्यांकित होता है — पैरामीटर लगा हुआ है, सुविधा चालू नहीं होती, और किसी लॉग में कुछ ध्यान खींचने वाला दर्ज नहीं होता।

किसी query string के लिए यह कहीं परिभाषित नहीं है कि पैरामीटर किस क्रम में आएँ, और लगभग हर सर्वर उन्हें क्रम की परवाह किए बिना पढ़ता है। इसलिए `?a=1&b=2` और `?b=2&a=1` वही अनुरोध हैं — जब तक कोई उन्हें टेक्स्ट की तरह न बरतने लगे।

दो जगहों पर वह बरतता है। पहली, हस्ताक्षर: OAuth 1.0 और AWS Signature version 4 पैरामीटरों को पहले तय नियम से क्रम में लगाते हैं, ठीक इसीलिए कि वरना दो बराबर अनुरोधों के hash अलग निकलते। दूसरी, cache key: अगर वह पूरी query string से बनती है तो दोनों रूप अलग-अलग प्रविष्टियाँ बनाते हैं, और कैश का आधा फ़ायदा चुपचाप चला जाता है। यहाँ क्रम वैसा ही रखा जाता है जैसा इनपुट में है, ताकि दोनों जाँचें संभव रहें।

लॉग और analytics निर्यात के query string में अक्सर निजी डेटा होता है: खोज-शब्द, पैरामीटर बने ईमेल पते, ऐसी पहचानें जो किसी खाते से जोड़ी जा सकती हैं। चूँकि यहाँ विभाजन उसी पन्ने पर होता है, उनमें से कुछ भी आपके डिवाइस से बाहर नहीं जाता।

ऐसा निर्यात किसी ऑनलाइन औज़ार से देख पाने की शर्त यही है। जो सेवा उसे किसी सर्वर पर तोड़ती वह वह पंक्ति पा चुकी होती और वह उसके लॉग में होती — ठीक उस क़िस्म के डेटा के साथ जिसका आगे बढ़ना रोकने के लिए अधिकतर आंतरिक नीतियाँ बनी होती हैं।