views:

80

answers:

1

Hi,

I have been running into this error for the last 3 or 4 weeks making requests to app engine. Certain requests - especially HTTP DELETE requests, are having this error returned from the google server.

Others have reported the same error - with 3 outcomes I can locate

  1. It is caused by stale cookies - clear your cookies and it runs fine gmail help -
  2. It is caused by a malformed url - only cases I can find relate to urlfetch() - spaces in the url - App engine Group #1, App Engine Group #2
  3. No resolution - sporadic behaiour, IE only. App Engine Group #3, App Engine Group #4

I'm now getting this behaviour all the time, in every browser. I can completely clear down the cache/cookies etc. in Chrome, Firefox, Safari, restart the browser and still reliably get this error on the same requests, so I don't think its cookie related. In any case I can issue GET, POST & PUT requests no problem with the same cookie.

Given that it occurs reliably on specific DELETE requests, the malformed URL would seem the most likely, however my URL is really very simple, and works fine on the dev server

Firebug shows the request headers as (I've munged the keys as they contain identifying data, but did so by removing characters from the centre of the key - not either end to guarantee I didn't inadvertently remove any leading or trailing whitespace)

    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

The response headers show that the request never made it to the app engine servers (and my app engine logs bear this out) - a request which successfully makes it to the app engine server looks more like this for response headers -

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

I am constructing the requests using jquery's $.ajax() method and setting the type as 'DELETE'. Also, these have worked as recently as last week, although the problem was starting to appear intermittently. Right now, nothing I do has any effect.

At the moment I'm thinking this is some sort of configuration error/change on google servers , slowly creeping across their network - which explains why it began intermittently, steadily increased, and now happens all the time.

Is anyone else able to issue HTTP DELETE requests to google app engine? If you are, do your URL's contain app engine entity keys? Can you see anything dodgy with mine?

Any other pointers would be greatly appreciated. Cheers,

Colin

The full response from the google server is -

<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>
+3  A: 

With an HTTP DELETE, the URI should fully identify the resource to be deleted. Sending additional data in the request body is unexpected, and on App Engine, unsupported:

Indeed, when the appspot frontends see a DELETE request that includes an body, such as your app, they return a 501. But, if you remove the body then it will serve a 200.

Based on the subsequent discussion, it looks like they decided 400 was more appropriate than 501. In any event, if you omit the body and move your entity key into the URI, you should be fine.

Drew Sears
Hi Drew - thanks for highlighting this - definitely looks like the cause of the problem. It strikes me as an incredibly naive constraint - especially since it's not mandated by the spec. Regardless of my use case, DELETE is quite a complex operation - e.g. are we performing a hard delete or a soft delete - what about archiving? Surely it should be up to the serving application (and not the context unaware web server) to determine 200 or 400 in this situation. Will follow this up on the google issue which appears to have been re-opened based on similar concerns. Thx.
hawkettc
Why not just follow the convention? GET/PUT/DELETE should fetch, create/overwrite, or remove the exact resource identified by the URI. Extra parameters for all 3 should go on the query string. Only PUT should have a body, and it should be the resource contents. If you DELETE a URI and return a 200, a subsequent GET or DELETE should 404. For everything else, there's POST, which just means "send some stuff to this URI and expect something to happen". If you wanted to delete two resources at once, it would be more appropriate to do that in a POST than trying to stuff the logic into a DELETE.
Drew Sears
A few points - 1) if data should be encoded on the query string, then jQuery's impl of DELETE is broken. 2) POST should be used to create an entity subordinate to the resource indicated in the URI - I'm doing nothing even close to that - POST would be a big hack. 3) PUT doesn't use query params by convention, any more than DELETE doesn't have a body 4) I can't find any official statement that a request body is unexpected for DELETE - the author at your link seems to have embellished the specification. All that said, it looks like query string params are my best bet. Just not liking it :) Thx
hawkettc
This post is also useful, and seems to come to the conclusion in multiple answers that it should be supported according to the spec.http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request
hawkettc