2010-07-30 4 views
16

Ich habe diesen Fehler in den letzten 3 oder 4 Wochen mit Anfragen an die App Engine erhalten. Bei bestimmten Anfragen - insbesondere bei HTTP-DELETE-Anfragen - wird dieser Fehler vom Google-Server zurückgegeben.App-Engine: 400 - Ihr Kunde hat eine ungültige oder illegale Anfrage ausgegeben

Andere haben den gleichen Fehler gemeldet - mit 3 Ergebnissen I

  1. Es verursacht durch veraltete Cookies finden können - Ihre Cookies löschen, und es läuft gut gmail help-
  2. Es durch eine fehlerhafte URL verursacht wird - Nur Fälle, die ich finden kann beziehen sich auf urlfetch() - Leerzeichen in der URL - App engine Group #1, App Engine Group #2
  3. Keine Auflösung - sporadisches Verhalten, nur IE. App Engine Group #3, App Engine Group #4

ich jetzt bin immer dieses Verhalten die ganze Zeit, in jedem Browser. Ich kann den Cache/Cookies etc. in Chrome, Firefox, Safari komplett löschen, den Browser neu starten und trotzdem diesen Fehler zuverlässig auf die gleichen Anfragen bekommen, also denke ich nicht, dass sein Cookie damit zusammenhängt. In jedem Fall kann ich GET, POST & PUT Anfragen kein Problem mit dem gleichen Cookie ausstellen.

Da es zuverlässig auf spezifischen DELETE-Anfragen auftritt, würde die fehlerhafte URL scheint die wahrscheinlichste, aber meine URL ist wirklich sehr einfach und funktioniert gut auf dem Dev-Server

Firebug den Request-Header als (I zeigt habe die Schlüssel munged da sie Daten enthalten, zu identifizieren, aber er so durch entfernen von Zeichen aus der Mitte des Schlüssels - entweder nicht zu gewährleisten enden I nicht versehentlich jede führende oder nachfolgende Leerzeichen entfernen hat)

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 

die Antwort Überschriften zeigen, dass die Anfrage nie zu den App-Engine-Servern gelangt ist (und die Protokolle meiner App-Engine tragen dies auch) out) - eine Anforderung, die sie erfolgreich an den Server App-Engine macht wie folgt aussieht mehr für Response-Header -

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 

Ich Konstruktion die Anforderungen jQuerys $ Schnipsel() Methode verwendet und die Art als ‚DELETE‘ -Einstellung . Auch diese haben so letzte Woche gearbeitet, obwohl das Problem begann, zeitweise zu erscheinen. Im Moment hat nichts, was ich tue, irgendeinen Effekt.

Im Moment denke ich, das ist eine Art Konfigurationsfehler/Änderung auf Google-Servern, schleicht langsam über ihr Netzwerk - was erklärt, warum es begann mit Unterbrechungen, stetig erhöht, und jetzt passiert die ganze Zeit.

Kann jemand andere HTTP DELETE Anfragen an die Google App Engine senden? Wenn ja, enthält Ihre URL App Engine Entity Keys? Kannst du etwas sehen, das mit meinen zweideutig ist?

Alle anderen Hinweise würden sehr geschätzt werden. Cheers,

Colin

Die vollständige Antwort vom Google-Server -

<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

Ihr erster Vorschlag (Löschen aller Daten, Cookies usw.) funktioniert dank –

Antwort

17

Mit einem HTTP-DELETE, sollte die URI der Ressource gelöscht werden vollständig identifizieren.Senden zusätzlicher Daten in der Anfrage Körper ist unerwartet, and on App Engine, unsupported:

der Tat, wenn die AppSpot Frontends eine DELETE-Anfrage zu sehen, die einen Körper, wie Ihre App enthält, kehren sie ein 501. Aber, wenn Sie entfernen Sie den Körper, dann wird es dienen ein 200.

Basierend auf der anschließenden Diskussion, es ist wie sie aussieht 400 entschieden war besser geeignet als 501. In jedem Fall, wenn Sie den Körper auslassen und Ihre Entitätsschlüssel in die bewegen URI, du solltest in Ordnung sein.

+0

Hi Drew - danke für die Hervorhebung dieser - sieht definitiv wie die Ursache des Problems. Es erscheint mir als eine unglaublich naive Einschränkung - vor allem, weil es nicht durch die Spezifikation vorgeschrieben ist. Unabhängig von meinem Anwendungsfall ist DELETE eine ziemlich komplexe Operation - z. Führen wir ein Harddelete oder ein Softdelete durch - was ist mit der Archivierung? Sicherlich sollte es Sache der Serving-Anwendung (und nicht des kontextunabhängigen Webservers) sein, in dieser Situation 200 oder 400 zu ermitteln. Dies wird auf die Google-Frage folgen, die auf der Grundlage ähnlicher Bedenken wieder geöffnet wurde. Danke. – hawkett

+1

Warum nicht einfach der Konvention folgen? GET/PUT/DELETE sollte die genaue Ressource, die durch den URI identifiziert wurde, abrufen, erstellen/überschreiben oder entfernen. Zusätzliche Parameter für alle 3 sollten in der Abfragezeichenfolge enthalten sein. Nur PUT sollte einen Körper haben, und es sollte der Inhalt der Ressource sein. Wenn Sie einen URI LÖSCHEN und eine 200 zurückgeben, sollte ein nachfolgender GET oder DELETE 404 sein. Für alles andere gibt es POST, was nur bedeutet, dass "etwas an diesen URI gesendet wird und erwartet wird, dass etwas passiert". Wenn Sie zwei Ressourcen gleichzeitig löschen möchten, wäre es besser, dies in einem POST zu tun, als zu versuchen, die Logik in ein DELETE zu stopfen. –

+0

Einige Punkte - 1) Wenn Daten in der Abfragezeichenfolge codiert werden sollen, ist jQuerys Impl von DELETE defekt. 2) POST sollte verwendet werden, um eine Entität zu erstellen, die der Ressource untergeordnet ist, die in der URI angegeben ist - ich mache nichts, auch nur annähernd - POST wäre ein großer Hack. 3) PUT verwendet per Konvention keine Abfrageparameter, genauso wenig wie DELETE einen Body 4) Ich kann keine offizielle Aussage finden, dass ein Anfragetext für DELETE unerwartet ist - der Autor an Ihrem Link scheint verschönert zu haben die Spezifikation. Alles in allem sieht es so aus, als ob die Abfragezeichenfolge meine beste Wahl wäre. Einfach nicht gefallen :) Thx – hawkett

2

Ich habe gesehen, dass dies passiert, wenn die Website-Authentifizierung mehrere Browserbenutzer nicht richtig oder ausreichend auflöst. In ChromeOS besteht das Problem darin, sich vollständig abzumelden und auf die Site zuzugreifen, wenn nur die primäre Identität authentifiziert wurde. Beispiele: Google Mail und Ingress.

Verwandte Themen