App Engine: 400 - Ваш клиент отправил неверный или незаконный запрос - PullRequest
16 голосов
/ 30 июля 2010

Я сталкивался с этой ошибкой в ​​течение последних 3 или 4 недель, делая запросы к ядру приложения.Определенные запросы, особенно запросы HTTP DELETE, возвращают эту ошибку с сервера Google.

Другие сообщают о той же ошибке - с 3 результатами я могу найти

  1. Это вызваноустаревшие файлы cookie - удалите файлы cookie, и они будут работать нормально Справка по gmail -
  2. Это вызвано неверно сформированным URL - только те случаи, которые я могу найти, относятся к urlfetch () - пробелы в URL - Группа обработчиков приложений № 1 , Группа обработчиков приложений № 2
  3. Нет разрешения - случайное поведение, только IE. Группа App Engine Group # 3 , Группа App Engine Group # 4

Сейчас я наблюдаю такое поведение постоянно, в каждом браузере.Я могу полностью очистить кэш / cookie-файлы и т. Д. В Chrome, Firefox, Safari, перезапустить браузер и по-прежнему надежно получать эту ошибку при тех же запросах, поэтому я не думаю, что их cookie связаныВ любом случае я могу выдавать запросы GET, POST & PUT без проблем с одним и тем же файлом cookie.

Учитывая, что это происходит надежно при определенных запросах DELETE, неверно сформированный URL может показаться наиболее вероятным, однако мой URL действительно оченьпростой и отлично работает на сервере dev

Firebug отображает заголовки запроса как (я перебирал ключи, поскольку они содержат идентифицирующие данные, но сделал это, удалив символы из центра ключа - ни с одного концачтобы гарантировать, что я случайно не удалил ни одного начального или конечного пробела)

    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

Заголовки ответа показывают, что запрос никогда не поступал на серверы механизма приложений (и журналы моего механизма приложений подтверждают это) -запрос, который успешно поступает на сервер механизма приложений, больше похож на этот запрос для заголовков ответов -

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

Я создаю запросы с помощью метода jquery $ .ajax () и устанавливаю тип как «DELETE».Кроме того, они работали только на прошлой неделе, хотя проблема начинала появляться периодически.Прямо сейчас, ничто из того, что я делаю, не имеет никакого эффекта.

В настоящий момент я думаю, что это какая-то ошибка / изменение конфигурации на серверах Google, медленно ползущая по их сети - что объясняет, почему это началось с перерывами, постоянноувеличивается, и теперь все время происходит.

Кто-нибудь еще может отправлять HTTP-запросы DELETE в механизм приложений Google?Если да, содержат ли ваши URL-адреса ключи сущности ядра приложения?Можете ли вы увидеть что-нибудь хитрое с моим?

Любые другие указатели будут с благодарностью.Приветствия,

Колин

Полный ответ от сервера 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>

Ответы [ 2 ]

17 голосов
/ 31 июля 2010

При HTTP-УДАЛЕНИИ URI должен полностью идентифицировать ресурс, который нужно удалить. Отправка дополнительных данных в теле запроса является неожиданной, и в App Engine, не поддерживается :

Действительно, когда интерфейс appspot видит запрос DELETE, который включает в себя тело, такое как ваше приложение, они возвращают 501. Но если вы уберете тело, то оно будет служить 200.

Исходя из последующего обсуждения, похоже, что они решили, что 400 было более подходящим, чем 501. В любом случае, если вы опустите тело и переместите свой ключ сущности в URI, у вас все будет в порядке.

2 голосов
/ 02 августа 2014

Я видел, как это происходит, когда аутентификация сайта не решает несколько пользователей браузера должным образом или адекватно. В ChromeOS исправление состоит в том, чтобы полностью выйти из системы и получить доступ к сайту, когда аутентифицирована только основная личность. Примеры: Gmail и Ingress.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...