2010-07-30 20 views
16

Ho riscontrato questo errore per le ultime 3 o 4 settimane facendo richieste al motore dell'app. Alcune richieste, in particolare le richieste DELETE HTTP, stanno avendo questo errore restituito dal server di google.App Engine: 400 - Il client ha emesso una richiesta errata o illegale

Altri hanno segnalato lo stesso errore - con 3 esiti posso individuare

  1. E 'causata da biscotti stantii - eliminare i cookie e funziona benissimo gmail help-
  2. E' causata da un URL malformati - solo i casi che posso trovare riguardano urlfetch() - spazi nell'URL - App engine Group #1, App Engine Group #2
  3. Nessuna risoluzione - comportamento sporadico, solo IE. App Engine Group #3, App Engine Group #4

Ora sto ottenendo questo comportamento tutto il tempo, in ogni browser. Posso cancellare completamente la cache/i cookie ecc. In Chrome, Firefox, Safari, riavviare il browser e ottenere comunque questo errore sulle stesse richieste, quindi non credo che i relativi cookie siano correlati. In ogni caso posso emettere GET, POST & PUT non richiede alcun problema con lo stesso cookie.

dato che si verifica in modo affidabile su specifiche richieste di eliminazione, l'URL non valido sembrerebbe la più probabile, tuttavia il mio URL è davvero molto semplice, e funziona bene sul server dev

Firebug mostra le intestazioni di richiesta come (I 've munged le chiavi in ​​quanto contengono dati identificativi, ma ha fatto rimuovendo i caratteri dal centro della chiave - non entrambe le estremità per garantire non ho rimosso inavvertitamente un qualsiasi spazio o finale)

Request URL:http://my-app.appspot.com/agprhcjgLEgVLbm93dCItX0RrbV9Ea25vd3RfbmV0X19wccxDA/Task.xml 
    Request Method:DELETE 
    Status Code:400 Bad Request 

    Request Headers 
    Accept:*/* 
    Cache-Control:max-age=0 
    Content-Type:application/x-www-form-urlencoded 
    Origin:http://my-app.appspot.com 
    Referer:http://my-app.appspot.com/ 
    User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4 
    X-Requested-With:XMLHttpRequest 

    Form Data 
    entity_key:agprdC1hcjYLEgVLbm93dCIrX09Ea25vd3RfbmV0X19wMQw 

    Response Headers 
    Content-Length:1350 
    Content-Type:text/html; charset=UTF-8 
    Date:Fri, 30 Jul 2010 15:51:58 GMT 
    Server:GFE/2.0 

la risposta le intestazioni mostrano che la richiesta non è mai arrivata ai server del motore delle app (e i registri del mio motore app lo confermano out) - una richiesta che fa con successo al server di App Engine appare più come questo per le intestazioni di risposta -

Cache-Control:no-cache 
Content-Length:4332 
Content-Type:application/xml 
Date:Fri, 30 Jul 2010 11:08:21 GMT 
Expires:Fri, 01 Jan 1990 00:00:00 GMT 
Server:Google Frontend 
X-AppEngine-Estimated-CPM-US-Dollars:$0.004033 
X-AppEngine-Resource-Usage:ms=573 cpu_ms=146 api_cpu_ms=30 

sto costruendo le richieste utilizzando il metodo $ .ajax() di jQuery e l'impostazione del tipo 'ELIMINA' . Inoltre, questi hanno funzionato di recente come la scorsa settimana, anche se il problema stava iniziando a comparire in modo intermittente. In questo momento, nulla di ciò che faccio ha alcun effetto.

Al momento sto pensando che si tratti di una sorta di errore di configurazione/modifica sui server di google, che lentamente si insinua nella loro rete, il che spiega il motivo per cui è iniziato a intermittenza, costantemente aumentato e ora accade continuamente.

Qualcun altro è in grado di inviare richieste DELETE HTTP al motore di app di google? Se lo sei, i tuoi URL contengono le chiavi delle entità del motore delle app? Riesci a vedere qualcosa di losco con il mio?

Qualsiasi altro suggerimento sarebbe molto apprezzato. Cheers,

Colin

La risposta completa dal server di Google è -

<html><head> 
<meta http-equiv="content-type" content="text/html;charset=utf-8"> 
<title>400 Bad Request</title> 
<style><!-- 
body {font-family: arial,sans-serif} 
div.nav {margin-top: 1ex} 
div.nav A {font-size: 10pt; font-family: arial,sans-serif} 
span.nav {font-size: 10pt; font-family: arial,sans-serif; font-weight: bold} 
div.nav A,span.big {font-size: 12pt; color: #0000cc} 
div.nav A {font-size: 10pt; color: black} 
A.l:link {color: #6f6f6f} 
A.u:link {color: green} 
//--></style> 
<script><!-- 
var rc=400; 
//--> 
</script> 
</head> 
<body text=#000000 bgcolor=#ffffff> 
<table border=0 cellpadding=2 cellspacing=0 width=100%><tr><td rowspan=3 width=1% nowrap> 
<b><font face=times color=#0039b6 size=10>G</font><font face=times color=#c41200 size=10>o</font><font face=times color=#f3c518 size=10>o</font><font face=times color=#0039b6 size=10>g</font><font face=times color=#30a72f size=10>l</font><font face=times color=#c41200 size=10>e</font>&nbsp;&nbsp;</b> 
<td>&nbsp;</td></tr> 
<tr><td bgcolor="#3366cc"><font face=arial,sans-serif color="#ffffff"><b>Error</b></td></tr> 
<tr><td>&nbsp;</td></tr></table> 
<blockquote> 
<H1>Bad Request</H1> 
Your client has issued a malformed or illegal request. 

<p> 
</blockquote> 
<table width=100% cellpadding=0 cellspacing=0><tr><td bgcolor="#3366cc"><img alt="" width=1 height=4></td></tr></table> 
</body></html> 
+0

Il tuo primo suggerimento (cancellazione di tutti i dati, cookie, ecc.) Ha funzionato grazie –

risposta

17

Con un HTTP DELETE, l'URI dovrebbe pienamente identificare la risorsa da eliminare.L'invio di dati aggiuntivi nel corpo della richiesta è inaspettato, and on App Engine, unsupported:

Infatti, quando i frontend AppSpot vedono una richiesta DELETE che include un corpo, come ad esempio la vostra applicazione, che restituiscono un 501. Ma, se si rimuovi il corpo quindi servirà un 200.

Sulla base della discussione successiva, sembra che abbiano deciso che 400 era più appropriato di 501. In ogni caso, se si omette il corpo e si sposta la chiave dell'entità nel URI, dovresti stare bene.

+0

Ciao Drew - grazie per averlo evidenziato - sembra decisamente la causa del problema. Mi sembra un vincolo incredibilmente ingenuo, soprattutto perché non è richiesto dalle specifiche. Indipendentemente dal mio caso d'uso, DELETE è un'operazione piuttosto complessa - ad es. stiamo eseguendo un'eliminazione difficile o un'eliminazione soft - cosa dire dell'archiviazione? Sicuramente dovrebbe spettare all'applicazione servente (e non al server Web inconsapevole del contesto) per determinare 200 o 400 in questa situazione. Seguirà questo problema su Google che sembra essere stato riaperto in base a preoccupazioni simili. Grazie. – hawkett

+1

Perché non seguire solo la convenzione? GET/PUT/DELETE dovrebbe recuperare, creare/sovrascrivere o rimuovere la risorsa esatta identificata dall'URI. I parametri aggiuntivi per tutti e 3 dovrebbero andare sulla stringa di query. Solo PUT dovrebbe avere un corpo e dovrebbe essere il contenuto della risorsa. Se si elimina un URI e si restituisce un 200, un successivo GET o DELETE dovrebbe 404. Per tutto il resto, c'è il POST, che significa semplicemente "inviare alcune cose a questo URI e aspettarsi che accada qualcosa". Se si desidera eliminare due risorse contemporaneamente, sarebbe più appropriato farlo in un POST piuttosto che provare a inserire la logica in DELETE. –

+0

Alcuni punti - 1) se i dati devono essere codificati sulla stringa di query, quindi impl di DELETE di jQuery è rotto. 2) Il POST dovrebbe essere usato per creare un'entità subordinata alla risorsa indicata nell'URI - Non sto facendo nulla di simile - POST sarebbe un grosso problema. 3) PUT non usa parametri di query per convenzione, più di DELETE non ha un corpo 4) Non riesco a trovare alcuna istruzione ufficiale che un corpo di richiesta sia inaspettato per DELETE - l'autore al tuo collegamento sembra aver impreziosito la specifica Detto questo, sembra che i parametri della stringa di query siano la mia migliore scommessa. Semplicemente non mi piace :) Thx – hawkett

2

Ho notato che questo si verifica quando l'autenticazione del sito non risolve correttamente più o più utenti di browser. In ChromeOS la correzione è di uscire completamente e accedere al sito quando è stata autenticata solo l'identità principale. Esempi: Gmail e Ingress.

Problemi correlati