2012-11-08 14 views
6

Il mio client urlfetch funziona correttamente quando è distribuito su appspot. Ma il test locale (dev_appserver.py) tramite proxy ha un problema. Non riesco a trovare alcun modo per impostare il proxy per urlfetch.Transport.Come testare local gae golang urlfetch tramite proxy?

Come si esegue il test di urlfetch dietro il proxy localmente?

risposta

0

Questa è solo una supposizione, ma hai provato setting the proxy variables

In un ambiente Unix o Windows, impostare la http_proxy, o ftp_proxy variabili d'ambiente a un URL che identifica il server proxy prima di iniziare il Python interprete. Per esempio (il '%' è il comando pronta):

% http_proxy = "http://www.someproxy.com:3128"

% export http_proxy

+0

Ho installato. È un'applicazione golang che utilizza l'ID del browser per l'accesso. Grazie per la risposta – GQ77

0

se siete utilizzando il proxy predefinito quindi il trasporto viene implementato come

var DefaultTransport RoundTripper = &Transport{Proxy: ProxyFromEnvironment} 

l'impostazione della variabile di ambiente all'avvio di go dovrebbe risolvere il problema.

Vedi anche quest'altra domanda: How do I configure Go to use a proxy?

0

Il pacchetto urlfetch per sé non rispetta le impostazioni proxy, anche in fase di sviluppo, perché non è in realtà facendo l'URL prendere in sé: invia una richiesta al (possibilmente di sviluppo) app server e gli chiede di eseguire il recupero. Non ho la fonte di dev_appserver.py a portata di mano, ma dovrebbe onorare le variabili proxy standard:

export http_proxy='http://user:[email protected]:3210/' 

Se lo fai prima di iniziare dev_appserver.py, probabilmente solo di lavoro.

Se quanto sopra non funziona, si dovrebbe file an issue e quindi utilizzare la seguente soluzione:

func client(ctx *appengine.Context) *http.Client { 
    if appengine.IsDevAppServer() { 
     return http.DefaultClient 
    } 
    return urlfetch.Client(ctx) 
} 

Ciò utilizzare l'API UrlFetch sul appserver produzione, ma utilizzare il net/http client standard in caso contrario, che does honor il http_proxy variabile d'ambiente.

5

http.DefaultTransport e http.DefaultClient non sono disponibili in App Engine. Vedi https://developers.google.com/appengine/docs/go/urlfetch/overview

ricevuto questo messaggio di errore quando si verifica PayPal OAuth su GAE dev_appserver.py (funziona nella produzione quando compilato)

const url string = "https://api.sandbox.paypal.com/v1/oauth2/token" 
const username string = "EOJ2S-Z6OoN_le_KS1d75wsZ6y0SFdVsY9183IvxFyZp" 
const password string = "EClusMEUk8e9ihI7ZdVLF5cZ6y0SFdVsY9183IvxFyZp" 

client := &http.Client{}   

req, _ := http.NewRequest("POST", url, strings.NewReader("grant_type=client_credentials")) 
req.SetBasicAuth(username, password) 
req.Header.Set("Accept", "application/json") 
req.Header.Set("Accept-Language", "en_US") 
req.Header.Set("Content-Type", "application/x-www-form-urlencoded") 

resp, err := client.Do(req) 

Come si può vedere, Go App Engine rompe http.DefaultTransport (GAE_SDK /goroot/src/pkg/appengine_internal/internal.go, linea 142, GAE 1.7.5)

type failingTransport struct{} 
func (failingTransport) RoundTrip(*http.Request) (*http.Response, error) { 
    return nil, errors.New("http.DefaultTransport and http.DefaultClient are not available in App Engine. " + 
     "See https://developers.google.com/appengine/docs/go/urlfetch/overview") 
} 

func init() { 
    // http.DefaultTransport doesn't work in production so break it 
    // explicitly so it fails the same way in both dev and prod 
    // (and with a useful error message) 
    http.DefaultTransport = failingTransport{} 
} 

Ciò ha risolto a me con Go App Engine 1.7.5

transport := http.Transport{} 

    client := &http.Client{ 
     Transport: &transport, 
    }  

    req, _ := http.NewRequest("POST", url, strings.NewReader("grant_type=client_credentials")) 
    req.SetBasicAuth(username, password) 
    req.Header.Set("Accept", "application/json") 
    req.Header.Set("Accept-Language", "en_US") 
    req.Header.Set("Content-Type", "application/x-www-form-urlencoded") 
+0

Questo ha funzionato per me, ma ho dovuto usare la chiamata "client.NewRequest" non "http.NewRequest" –