2010-07-30 34 views
16

He estado corriendo en este error durante las últimas 3 o 4 semanas realizando solicitudes al motor de la aplicación. Ciertas solicitudes, especialmente las solicitudes HTTP DELETE, tienen este error devuelto por el servidor de google.App Engine: 400 - Su cliente ha emitido una solicitud incorrecta o mal formada

Otros han reportado el mismo error - con 3 resultados puedo localizar

  1. Es causada por las galletas rancias - borrar las cookies y funciona bien gmail help -
  2. Es causada por una dirección URL incorrecta - solo los casos que puedo encontrar se relacionan con urlfetch() - espacios en la url - App engine Group #1, App Engine Group #2
  3. Sin resolución - comportamiento esporádico, IE solamente. App Engine Group #3, App Engine Group #4

Ahora estoy consiguiendo este comportamiento todo el tiempo, en todos los navegadores. Puedo borrar por completo el caché/cookies, etc. en Chrome, Firefox, Safari, reiniciar el navegador y todavía obtener este error en las mismas solicitudes, así que no creo que esté relacionado con las cookies. En cualquier caso, puedo emitir GET, POST & PUT no solicita ningún problema con la misma cookie.

dado que se produce de forma fiable en las solicitudes DELETE específicos, la dirección URL incorrecta parece la más probable, sin embargo, mi URL es realmente muy simple, y funciona bien en el servidor dev

Firebug muestra los encabezados de la solicitud como (I 've munged las teclas, ya que contienen datos de identificación, pero también lo hizo mediante la eliminación de caracteres desde el centro de la tecla - no cualquiera de los extremos para garantizar que no se quita inadvertidamente cualquier espacio en blanco iniciales o finales)

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 respuesta los encabezados muestran que la solicitud nunca llegó a los servidores del motor de la aplicación (y los registros de mi motor de aplicaciones llevan esto fuera) - una petición que hace con éxito al servidor de App Engine se parece más a esto para las cabeceras de respuesta -

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 

estoy construyendo las solicitudes utilizando el método de jQuery $ .ajax() y ajustar el tipo como 'Borrar' . Además, estos han funcionado tan recientemente como la semana pasada, aunque el problema comenzó a aparecer intermitentemente. En este momento, nada de lo que hago tiene ningún efecto.

Por el momento estoy pensando que esto es algún tipo de error/cambio de configuración en los servidores de Google, ralentizando lentamente su red, lo que explica por qué comenzó de forma intermitente, constantemente y ahora sucede todo el tiempo.

¿Alguien más puede emitir solicitudes HTTP DELETE al motor de la aplicación google? Si es así, ¿su URL contiene claves de entidad de motor de aplicación? ¿Puedes ver algo dudoso con el mío?

Cualquier otro puntero sería muy apreciado. Saludos,

Colin

La respuesta completa desde el servidor de Google es -

<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

Su primera sugerencia (borrar todos los datos, cookies, etc.) funcionó gracias –

Respuesta

17

Con un HTTP eliminar, el URI debe identificar plenamente el recurso que desea eliminar.El envío de datos adicionales en el cuerpo de la petición es inesperado, and on App Engine, unsupported:

De hecho, cuando las interfaces AppSpot ver una solicitud de eliminación que incluye un cuerpo , como su aplicación, que devuelven un 501. Sin embargo, si eliminar el cuerpo y luego servirá un 200.

Según la discusión posterior, parece que decidieron que 400 era más apropiado que 501. En cualquier caso, si omite el cuerpo y mueve la clave de entidad en el URI, deberías estar bien.

+0

Hola Drew, gracias por destacar esto, definitivamente parece la causa del problema. Me parece una restricción increíblemente ingenua, especialmente porque no está ordenada por la especificación. Independientemente de mi caso de uso, DELETE es una operación bastante compleja, por ej. ¿Estamos realizando una eliminación difícil o una eliminación suave? ¿Qué pasa con el archivo? Seguramente debería corresponder a la aplicación que sirve (y no al servidor web que desconoce el contexto) determinar 200 o 400 en esta situación. Seguirá esto en el problema de Google que parece haber sido reabierto en base a preocupaciones similares. Gracias. – hawkett

+1

¿Por qué no seguir la convención? GET/PUT/DELETE debe buscar, crear/sobrescribir o eliminar el recurso exacto identificado por el URI. Los parámetros adicionales para los 3 deben ir en la cadena de consulta. Solo PUT debe tener un cuerpo, y debe ser el contenido del recurso. Si ELIMINA un URI y devuelve un 200, un GET o DELETE posterior debe 404. Para todo lo demás, hay un POST, que simplemente significa "enviar algunas cosas a este URI y esperar que algo suceda". Si desea eliminar dos recursos a la vez, sería más apropiado hacerlo en un POST que tratar de rellenar la lógica en un DELETE. –

+0

Algunos puntos: 1) si los datos deben codificarse en la cadena de consulta, entonces la impl de jQuery de DELETE está rota. 2) POST se debe utilizar para crear una entidad subordinada al recurso indicado en el URI - No estoy haciendo nada, ni siquiera cerca de eso - POST sería un gran truco. 3) PUT no usa parámetros de consulta por convención, más que DELETE no tiene un cuerpo 4) No puedo encontrar ninguna declaración oficial de que un cuerpo de solicitud sea inesperado para DELETE - el autor en su enlace parece haber embellecido la especificación. Dicho todo esto, parece que los parámetros de cadena de consulta son mi mejor opción. Simplemente no me gusta :) Thx – hawkett

2

He visto esto suceder cuando la autenticación del sitio no resuelve varios usuarios del navegador de forma adecuada o adecuada. En ChromeOS, la solución es cerrar la sesión por completo y acceder al sitio cuando solo se ha autenticado la identidad principal. Ejemplos: Gmail e Ingress.

Cuestiones relacionadas