2016-01-25 14 views
18

Ho riscontrato strani problemi ora con l'invio della richiesta http dall'estensione di Chrome che sto sviluppando (JavaScript normale). Questo è un richiesta POST con XmlHttpRequest (da background.js) con URL del tipo:L'URI assoluto POST viene inviato al server da XmlHttpRequest quando si utilizza il proxy Squid3

http://host.com/postform/upload 

anch'io mando questa richiesta dal sito web normale (estensione non cromato), e importante po è che se apro Developer Strumenti e controllare la scheda di rete per la mia richiesta (selezione prime intestazioni visualizzazione) vedo prima intestazione c'è:

POST /postform/upload HTTP/1.1 

e funziona bene prima abilito il proxy invece di una connessione diretta. Uso squid3 sulla mia Ubuntu per questo. Solo una cosa è diversa tra le richieste quando si utilizza procura - e fa ritorno server HTTP 404 non trovato - solo quando si utilizza delega ..

Quando forzo Chrome per lavorare con la mia procura sulla base di squid3 (io uso Script PAC per questo nella mia estensione chrome), la mia richiesta non funzionerà. Ho controllato molte volte e ho fatto tutto il possibile per ridurre le differenze nel corpo della richiesta, e tutto quello che ho lasciato per ora è la prima intestazione.

Ecco come si presenta quando richiesta inviata con delega attiva (dalla scheda di rete di strumenti di sviluppo, aperta da sfondo della pagina):

POST http://host.com/postform/upload HTTP/1.1 

Ho provato con chome.webRequest.onBeforeSendHeaders API, ma quello non ha aiutato. Ho anche provato a rimuovere l'hostname dall'URL in XmlHttpRequest.open ma questo non ha aiutato.

Sì, sto trasmettendo le intestazioni di host e di origine corrette in ogni caso. Questo potrebbe essere un problema nella mia configurazione di squid3, o cosa dovrei cambiare nel mio javaScript?

UPDATE rese conto che il calamaro non è il problema in alcun modo, e il problema è che POST richiesta contiene uri PIENO (http://...) Invece di "percorso". GET funziona correttamente. Mi sta uccidendo.

Non riesco a utilizzare le soluzioni alternative iframe. Qual è il mio problema?

+0

Capisco cosa causa l'errore 404 sul server quando si utilizza il proxy, ma non capisco perché qualcosa funzioni (con proxy PAC) bene se la richiesta viene inviata dalla normale pagina Web di Chrome (jquery/ajax) e non dallo script di backend dell'estensione. – Croll

risposta

4

Per utilizzare l'API XHR dall'estensione di Chrome, è necessario richiedere l'autorizzazione per l'host di destinazione specificando l'URL nell'attributo manifest di "permissions" manifest. Ad esempio, se l'host di destinazione (a cui si desidera inviare la richiesta XHR) è http://www.example.org, il manifest deve contenere le seguenti righe di codice.

... 
"permissions" : { 
    "http://www.example.org", 
    ... 
} 

Se si è già fatto, poi, ovviamente, l'errore è sulla parte di back-end. Leggi anche lo match patterns per consentire la corrispondenza di più URL utilizzando una singola stringa, ad esempio *://www.example.org/*.

+2

Ho già l'autorizzazione '*: //*.*' nel mio manifest – Croll

+1

@DmitrjA Se questo è ciò che avete, è un pattern di corrispondenza malformato. Dovrebbe essere "" *: // */* "' – Xan

+1

@Xan '*: // *. Org' fa esattamente quello che mi serve. Ho provato la tua soluzione e nulla è cambiato. GET funziona come previsto, il POST fallisce perché l'intestazione contiene l'URI di richiesta completo invece di "posizione" (percorso). – Croll