Go 1.26 साक्षात्कार: net/url द्वारा host-colon वैलिडेशन सख्त किए जाने के बाद आप माइग्रेशन कैसे करेंगे?

प्रॉम्प्ट और संदर्भ

एक Go HTTP सर्विस को 1.25 से 1.26 में अपग्रेड किया गया और पाया गया कि ऐतिहासिक मान http://localhost:80:80/ और http://::1/ अब विफल हो जाते हैं, जबकि http://[::1]/ अभी भी सफल होता है। net/url.Parse बदलाव, प्रॉक्सी और SSRF सुरक्षा पर इसके प्रभाव, और एक ऐसे माइग्रेशन की व्याख्या कीजिए जो किसी स्थायी कम्पैटिबिलिटी स्विच पर निर्भर न हो।

Go 1.26 डिफ़ॉल्ट रूप से urlstrictcolons को 1 पर सेट करता है, जिससे host सबकंपोनेंट में अतिरिक्त colons अस्वीकार हो जाते हैं जिन्हें host:port के रूप में व्याख्यायित नहीं किया जा सकता; यह व्यवहार Go 1.25.2 और 1.24.8 में भी बैकपोर्ट किया गया था। RFC 3986 host को IP-literal, IPv4 एड्रेस, या रजिस्टर्ड नाम के रूप में परिभाषित करता है, जिसमें port को एक colon द्वारा अलग किया जाता है, इसलिए टेक्स्टुअल IPv6 ब्रैकेट्स के अंदर होना चाहिए।

इंटरव्यूअर क्या जांच रहा है

• क्या आप URI सिंटैक्स के आधार पर समझा सकते हैं कि अतिरिक्त colons अस्पष्ट या अमान्य क्यों हैं?
• क्या आप बिना ब्रैकेट वाले IPv6, मान्य [IPv6]:port, होस्टनाम और अमान्य ports में अंतर कर सकते हैं?
• क्या आप केवल वैलिडेशन को अक्षम करने के बजाय कॉन्फ़िगरेशन माइग्रेशन, थर्ड-पार्टी URLs, प्रॉक्सी रीराइटिंग और लॉग्स को संभाल सकते हैं?
• क्या आप समझा सकते हैं कि GODEBUG=urlstrictcolons=0 एक अस्थायी कम्पैटिबिलिटी टूल है, न कि कोई इनपुट-वैलिडेशन पॉलिसी?
• क्या आप अपग्रेड के बाद पार्सिंग, कनेक्शन, रीडायरेक्ट और SSRF व्यवहार को रिग्रेशन टेस्ट्स के साथ साबित कर सकते हैं?

पहले स्पष्ट करने योग्य प्रश्न

• क्या विफल होने वाले URLs मानव कॉन्फ़िगरेशन, डेटाबेस, यूज़र इनपुट या किसी थर्ड-पार्टी कॉलबैक से आते हैं? उनके ट्रस्ट लेवल्स अलग-अलग होते हैं।
• क्या एप्लिकेशन url.Parse, url.Hostname, और url.Port को जोड़ता है? अलग-अलग पार्सिंग APIs व्यवहार बदल देते हैं।
• क्या आंतरिक IPv6 समर्थित होना चाहिए, क्या port आवश्यक है, और क्या प्रॉक्सी Host को रीराइट कर सकता है?
• क्या पुराने मानों को ऑनलाइन ठीक किया जा सकता है, या उन्हें प्री-रिलीज़ बैच में मान्य और अस्वीकार किया जा सकता है?
• क्या सर्विस एक्सेस कंट्रोल, टेनेंट रूटिंग, या SSRF डिफेंस के लिए URL पार्सिंग का उपयोग करती है?

30-सेकंड का उत्तर

"मैं विफलताओं को स्रोत और host के आकार के आधार पर वर्गीकृत करूंगा। Go 1.26 डिफ़ॉल्ट रूप से urlstrictcolons को सक्षम करता है, इसलिए बिना ब्रैकेट वाले IPv6 और एकाधिक host colons वाले स्ट्रिंग्स अस्वीकार कर दिए जाते हैं; इसका स्पष्ट रूप [::1] है, जिसमें port को [::1]:8080 के रूप में लिखा जाता है। मैं कॉन्फ़िगरेशन सीमाओं पर खराब मानों को सुधारूंगा और अस्वीकार करूंगा, पार्सिंग और नेटवर्क रिग्रेशन टेस्ट जोड़ूंगा, और कैनरी में विफलता दर की निगरानी करूंगा। GODEBUG=urlstrictcolons=0 केवल एक अल्पकालिक रोलबैक और क्लीनअप टूल है, अविश्वसनीय इनपुट के लिए कभी भी एक स्थायी नीति नहीं।"

चरण-दर-चरण गहन विश्लेषण

1. एक बेसलाइन स्थापित करें। पुराने संस्करण और Go 1.26 पर विफल होने वाले नमूनों को एकत्र करें, पार्स एरर, रॉ मान, स्रोत और अंतिम उपयोग को रिकॉर्ड करें। "पार्स होता है" का अर्थ "कनेक्ट करने के लिए सुरक्षित" नहीं है; स्कीम, होस्टनाम, पोर्ट और रीडायरेक्ट्स की भी जांच करें।

1. URI सिंटैक्स द्वारा वर्गीकृत करें। http://[::1]/ एक ब्रैकेटेड IP-literal है; http://[::1]:8080/ ब्रैकेट्स के बाद port रखता है। http://::1/ colons का उपयोग host डेटा और port डिलीमीटर दोनों के रूप में करता है, जबकि http://localhost:80:80/ में एकाधिक port डिलीमीटर होते हैं; दोनों ही सुधारे जाने योग्य मान हैं।

1. डेटा सीमाओं को पहले ठीक करें। कॉन्फ़िगरेशन फ़ाइलों, डेटाबेस माइग्रेशन और एडमिन APIs में वैलिडेशन जोड़ें: IPv6 को ब्रैकेट्स के साथ सामान्यीकृत (normalize) करें, ports को रेंज के अंदर पूर्णांक के रूप में पार्स करें, और व्याख्या न किए जा सकने वाले hosts को अस्वीकार करें। बैच क्लीनअप के दौरान, मूल मान, सही किया गया मान और स्रोत को सुरक्षित रखें; उन रिकॉर्ड्स को अलग करें जिन पर स्वचालित रूप से निर्णय नहीं लिया जा सकता।

1. सुरक्षा पथ की समीक्षा करें। एक्सेस कंट्रोल को पार्स किए गए Hostname(), port और IP परिणामों का उपयोग करना चाहिए, जिसमें DNS, रीडायरेक्ट्स और प्रॉक्सी रीराइटिंग के लिए स्पष्ट सीमाएं हों। स्ट्रिंग प्रीफ़िक्स या केवल एक Parse परिणाम से आंतरिक बनाम सार्वजनिक गंतव्यों को कभी वर्गीकृत न करें। अपग्रेड के बाद SSRF, प्रॉक्सी और रीडायरेक्ट मामलों को फिर से चलाएं।

1. एक अस्थायी रोलबैक डिज़ाइन करें। GODEBUG=urlstrictcolons=0 एक नियंत्रित वातावरण में पुराने व्यवहार को पुनर्स्थापित कर सकता है, लेकिन इसके लिए समाप्ति समय, मेट्रिक्स और अलर्ट की आवश्यकता होती है, और इसे नए यूज़र इनपुट को वैलिडेशन बायपास करने की अनुमति नहीं देनी चाहिए। एक अधिक सुरक्षित विकल्प इसे केवल एक अलग प्रक्रिया में इन्वेंट्री किए गए लीगेसी कॉन्फ़िगरेशन सेट के लिए सक्षम करना और क्लीनअप के बाद इसे अक्षम करना है।

1. कैनरी और सत्यापन। शैडो ट्रैफ़िक और एक छोटे इंस्टेंस सेट को चलाएं, जिसमें पार्स एरर, कनेक्शन एरर, प्रॉक्सी मैच और रीडायरेक्ट परिणामों की तुलना की जाए। गेट्स में मान्य IPv4, ब्रैकेटेड IPv6, खराब IPv6, अतिरिक्त colons, खाली ports और दुर्भावनापूर्ण रीडायरेक्ट शामिल होने चाहिए। लीगेसी क्लीनअप पूरा होने के बाद ही विस्तार करें।

func validateEndpoint(raw string) (*url.URL, error) {
    u, err := url.Parse(raw)
    if err != nil {
        return nil, err
    }
    if u.Scheme != "http" && u.Scheme != "https" {
        return nil, fmt.Errorf("unsupported scheme")
    }
    host := u.Hostname()
    if host == "" {
        return nil, fmt.Errorf("missing host")
    }
    if p := u.Port(); p != "" {
        n, err := strconv.Atoi(p)
        if err != nil || n < 1 || n > 65535 {
            return nil, fmt.Errorf("invalid port")
        }
    }
    return u, nil
}

मॉडल उत्तर

मैं सबसे पहले प्रत्येक खराब मान के स्रोत की पहचान करूंगा और सिंटैक्स एरर को कनेक्शन विफलताओं से अलग करूंगा। Go 1.26 डिफ़ॉल्ट रूप से urlstrictcolons=1 करता है, जिससे http://::1/ और http://localhost:80:80/ अस्वीकार हो जाते हैं क्योंकि colons को स्पष्ट रूप से मान्य IPv6 या एक एकल port के रूप में व्याख्यायित नहीं किया जा सकता; http://[::1]:8080/ स्पष्ट है।

कॉन्फ़िगरेशन और एडमिन सीमाओं पर, मैं विकृत मानों को अस्वीकार करूंगा, IPv6 साबित होने वाले रिकॉर्ड्स को स्वचालित रूप से ठीक करूंगा, और अस्पष्ट रिकॉर्ड्स को उनके मालिकों के लिए अलग करूंगा। रूटिंग, प्रॉक्सीइंग या SSRF सुरक्षा के लिए URLs का उपयोग करने वाले प्रत्येक पथ को होस्टनाम, port, DNS, रीडायरेक्ट्स और प्रॉक्सी रीराइट्स का पुन: परीक्षण करना चाहिए। GODEBUG=urlstrictcolons=0 मेट्रिक्स और अलर्ट के साथ एक समयबद्ध कम्पैटिबिलिटी रोलबैक है, अविश्वसनीय इनपुट को नए चेक को बायपास करने देने का तरीका नहीं। रोलबैक हटाने से पहले कैनरी पार्स एरर, कनेक्शन एरर और सुरक्षा मामलों की तुलना करता है।

सामान्य गलतियाँ

• लक्षण: प्रत्येक बिना ब्रैकेट वाले IPv6 स्ट्रिंग को मान्य मानना → यह विफल क्यों होता है: Host और port की सीमाएं अस्पष्ट हो जाती हैं → समाधान: [IPv6] का उपयोग करें और port को ] के बाद रखें।
• लक्षण: GODEBUG=urlstrictcolons=0 को स्थायी रूप से सेट करना → यह विफल क्यों होता है: खराब इनपुट और लीगेसी अस्पष्टता बनी रहती है → समाधान: एक समाप्ति तिथि निर्धारित करें और पहले डेटा और सीमाओं को ठीक करें।
• लक्षण: केवल यह टेस्ट करना कि क्या url.Parse कोई एरर लौटाता है → यह विफल क्यों होता है: होस्टनाम, port, DNS, रीडायरेक्ट्स और प्रॉक्सी सुरक्षा परिणाम को बदल सकते हैं → समाधान: पूरे नेटवर्क पथ का परीक्षण करें।
• लक्षण: रॉ स्ट्रिंग्स से प्राइवेट एड्रेस को वर्गीकृत करना → यह विफल क्यों होता है: एन्कोडिंग, पार्सिंग, DNS और रीडायरेक्ट्स स्ट्रिंग नियमों को बायपास कर सकते हैं → समाधान: लगातार पार्स करें, IPs को रिज़ॉल्व करें, और प्रत्येक रीडायरेक्ट के बाद पॉलिसी को फिर से लागू करें।

फॉलो-अप प्रश्न और उत्तर

लीगेसी कॉन्फ़िगरेशन को आज ही ठीक होना चाहिए। आप जोखिम को कैसे नियंत्रित करते हैं?

urlstrictcolons=0 को केवल एक पृथक प्रक्रिया या स्पष्ट रूप से इन्वेंट्री किए गए लीगेसी सेट के लिए सक्षम करें, जिसमें समाप्ति तिथि, स्रोत और लक्ष्य प्रतिबंध, और प्रत्येक हिट के लिए एक मीट्रिक हो। नए मान अभी भी सख्त वैलिडेशन का उपयोग करेंगे; क्लीनअप के बाद रोलबैक को बंद कर दें।

[::1] मान्य क्यों है जबकि ::1 हतोत्साहित किया जाता है?

URI authority host और port को अलग करने के लिए colon का उपयोग करती है। ब्रैकेट्स IPv6 IP-literal और port के बीच की सीमा को स्पष्ट करते हैं। ::1 को सीधे hostport में रखना अस्पष्ट होता है, इसलिए Go 1.26 इसे अस्वीकार कर देता है।

प्रॉक्सी को कहाँ पुन: सत्यापित करना चाहिए?

इनग्रेस पर पार्स करना पर्याप्त नहीं है। Host को रीराइट करने, रीडायरेक्ट का पालन करने, या फिर से DNS रिज़ॉल्व करने के बाद, नए गंतव्य पर स्कीम, होस्टनाम, IP, port और नेटवर्क नीति को पुन: लागू करें; शुरुआती URL के निर्णय को अगले हॉप पर सीधे लागू न करें।

आप कैसे दिखाते हैं कि अपग्रेड ने अस्वीकृति को गलत तरीके से व्यापक नहीं किया?

मान्य IPv4, ब्रैकेटेड IPv6, ports वाले URLs, विकृत अतिरिक्त-colon hosts, खाली hosts, अमान्य ports और रीडायरेक्ट्स का एक निश्चित कॉर्पस रखें। इसे Go 1.24.8, 1.25.2, और 1.26 पर चलाएं, फिर कैनरी के दौरान वास्तविक कॉन्फ़िगरेशन विफलता दरों की तुलना करें।

संदर्भ

• Go 1.26 रिलीज़ नोट्स
• Go, बैकवर्ड कम्पैटिबिलिटी, और GODEBUG
• RFC 3986 यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर: जेनेरिक सिंटैक्स
• Go net/url सोर्स

इंटरव्यू चेकलिस्ट

पहले host, IPv6 ब्रैकेट्स और port सीमा की व्याख्या करें। फिर डेटा क्लीनअप, सख्त सीमा वैलिडेशन, SSRF-पथ रीटेस्टिंग और एक समय-सीमित GODEBUG रोलबैक को कवर करें। पार्सिंग कम्पैटिबिलिटी को एक्सेस सुरक्षा से अलग रखें।

एक-पंक्ति का निष्कर्ष

Go 1.26 सेवाओं से अस्पष्ट URLs को स्पष्ट URIs में बदलने और सुरक्षित माइग्रेशन के लिए टेस्ट्स, एक कैनरी और एक समय-सीमित रोलबैक का उपयोग करने की अपेक्षा करता है।