Go HTTP क्लाइन्टलाई आफ्नै प्रोक्सी दिनुहोस्

Go HTTP क्लाइन्टको transport ले प्रोक्सी छान्छ। मानक transport बदल्नुअघि क्लोन गर्नुहोस्, ताकि डिफल्ट क्लाइन्टका अन्य प्रयोगकर्ताको हालको रुटिङ कायम रहोस्।

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "net/url"
    "time"
)

func main() {
    proxyURL, err := url.Parse("http://203.0.113.10:8080")
    if err != nil {
        log.Fatal(err)
    }

    transport := http.DefaultTransport.(*http.Transport).Clone()
    transport.Proxy = http.ProxyURL(proxyURL)
    defer transport.CloseIdleConnections()

    client := &http.Client{
        Transport: transport,
        Timeout:   15 * time.Second,
    }

    response, err := client.Get("https://example.com/")
    if err != nil {
        log.Fatal(err)
    }
    defer response.Body.Close()

    fmt.Println(response.StatusCode)
    if _, err := io.Copy(io.Discard, response.Body); err != nil {
        log.Fatal(err)
    }
}

ठेगाना कागजातको उदाहरण हो। त्यसको सट्टा वास्तविक HTTP प्रोक्सीको IP र पोर्ट राख्नुहोस्, जस्तै HTTP प्रोक्सी सूचीबाट छानिएको विकल्प। उदाहरणले Go को मानक लाइब्रेरी मात्र प्रयोग गर्छ; यो HTTP प्रोक्सी अनुरोधलाई SOCKS प्याकेज वा पूरै प्रक्रियाको वातावरणीय चर चाहिँदैन।

DefaultTransport सीधै किन नबदल्ने?

डिफल्ट transport साझा हुन्छ। त्यसलाई बदल्दा तपाईंको प्रोक्सी कहिल्यै नमागेको कोडको व्यवहार बदलिन सक्छ। अनुरोधले प्रयोग गरिरहेको बेला परिवर्तन गर्दा टार्न सकिने समवर्ती समस्या पनि आउँछन्। छुट्टै transport ले बाटोलाई यही क्लाइन्टको कन्फिगरेसनको हिस्सा बनाउँछ।

http.ProxyURL ले सधैँ दिइएको URL छान्ने चयनकर्ता फर्काउँछ। यो प्रोक्सी चर र बाइपास नियम विचार गर्ने डिफल्ट वातावरणीय चयनकर्ताभन्दा फरक छ। HTTP सूचीको एउटा निश्चित प्रविष्टि जाँच्न चाहनुहुन्छ भने स्पष्ट चयनकर्ताले यो अस्पष्टता हटाउँछ।

प्रतिक्रिया बन्द गर्नुहोस् र क्लाइन्ट फेरि प्रयोग गर्नुहोस्

उदाहरणले प्रतिक्रियाको बडी पूरै पढेर बन्द गर्छ। अन्त्यसम्म पढ्दा transport लाई सम्भव हुँदा जडान फेरि प्रयोग गर्न सहयोग हुन्छ। एउटै प्रोक्सीबाट धेरै अनुरोध गर्ने कार्यक्रममा हरेकपटक नयाँ जोडी नबनाई क्लाइन्ट र transport राख्नुहोस्।

क्लाइन्टको टाइमआउट सकेट खोल्न मात्र सीमित छैन; यसले प्रतिक्रियाको बडी पढ्नेसहित अनुरोधको जीवनचक्र पनि सीमित गर्छ। Get फर्किएपछि पनि पढाइका त्रुटि सम्हाल्नुपर्छ। 403 जस्तो स्थिति Go transport त्रुटि होइन, त्यसैले StatusCode र err छुट्टाछुट्टै जाँच्नुहोस्।