http://sentry.dmz.phx1.mozilla.com/addons/marketplace-dev/group/13162/ http://cl.ly/image/18302a0O3e2x

I made a test that did a PUT with url form encoding and it passed with no issues. Tomorrow I can try with curl and/or try and get fireplace hooked up to see what's going on.

Curl worked just fine: ~ $ curl -XPUT http://z.mozilla.dev/api/v1/apps/rating/3/ -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" --data "body=bar&rating=1" {"app": "/api/v1/apps/app/23/", "body": "bar", "pk": "3", "rating": 1, "report_spam": "/api/v1/apps/rating/3/flag/", "resource_uri": "/api/v1/apps/rating/3/", "user": {"display_name": "amckay", "resource_uri": "/api/v1/account/settings/27/"}, "version": null}

I can't reproduce this with a test or any of my other testing tools, either. Basta, could you give us a failing test or branch of Fireplace with the affected code? At a bit of a loss here.

i told :chuck this morning that it might be triggered by the CORS behavior. Fireplace is currently wired up to do this, so if you create a review with Fireplace and then try to edit it (you may need to refresh the page ATM to see the edit button) you can reproduce it that way.

Using Fireplace hooked up to my local install: no problems. This should be a full replication of what basta is working with. I'm not sure what this means. === Params: _user hi@chuck.mn,798afa94326437581306967ea04faef91ad11c01cef25a9b60f1205d06042ca473ae50cb2760c1d1db6ac9a8cf73031c75d06b92ca65cf106e6eed12f784bd30,24c8c398bb1f4363996bcf6131954662 dev firefoxos lang en-US pro 4554410.23.1 region internet --- Response Headers Access-Control-Allow-Head... X-HTTP-Method-Override, Content-Type Access-Control-Allow-Meth... GET, PUT, DELETE, OPTIONS Access-Control-Allow-Orig... * Access-Control-Expose-Hea... X-API-Version, X-API-Status Connection keep-alive Content-Type application/json; charset=utf-8 Date Wed, 17 Apr 2013 22:34:19 GMT Server nginx/1.2.6 Set-Cookie lang="en-US\054en-US"; Path=/ region=us; Path=/ Strict-Transport-Security max-age=2592000 Transfer-Encoding chunked Vary X-Requested-With, Accept-Language, Cookie, X-Mobile, User-Agent X-API-Version 1 x-content-security-policy... policy-uri /services/csp/policy?build= Request Headers Accept */* Accept-Encoding gzip, deflate Accept-Language en-US,en;q=0.5 Content-Length 21 Content-Type application/x-www-form-urlencoded; charset=UTF-8 DNT 1 Host localhost Origin http://0.0.0.0:8675 Referer http://0.0.0.0:8675/app/test-app-otter2898/ratings/edit User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0 ---- Put Parameters application/x-www-form-urlencoded body 3 Stars rating 3 Source rating=3&body=3+Stars --- Response {"app": "/api/v1/apps/app/6/", "body": "3 Stars", "is_author": true, "pk": "31", "rating": 3, "report_spam": "/api/v1/apps/rating/31/flag/", "resource_uri": "/api/v1/apps/rating/31/", "user": {"display_name": "hi", "resource_uri": "/api/v1/account/settings/28/"}, "version": null}

For my sanity and everyone else's, can you point your local fireplace at -dev and make sure it's not just my build?

It's not just your build.

Stuck a log in dispatch: Apr 17 17:08:11 dev2.addons.phx1.mozilla.com: [<anon>][63.245.220.240] z.api:INFO Content-Type: - :/data/www/addons-dev.allizom.org/zamboni/mkt/api/base.py:74 Apr 17 17:08:11 dev2.addons.phx1.mozilla.com: [<anon>][63.245.220.240] z.api:INFO Logged in using SharedSecretAuthentication :/data/www/addons-dev.allizom.org/zamboni/mkt/api/base.py:164 Apr 17 17:08:13 dev2.addons.phx1.mozilla.com: [][] django.request.tastypie:ERROR /api/v1/apps/rating/414647/ /api/v1/apps/rating/414647/: JSONDecodeError No JSON object could be decoded: line 1 column 0 (char 0)#012 File "/data/www/addons-dev.allizom.org/venv/lib/python2.6/site-packages/tastypie/resources.py", line 192, in wrapper#012 response = callback(request, *args, **kwargs)#012#012 File "/data/www/ad The request coming in has no content-type (- means its not there) and the default is to parse as JSON. But this doesn't occur in the local instances, so I'm looking suspiciously at CORS.

@basta fixed an issue in chimney. Long and short of it, there was no Content-Type in the headers when it hit zamboni. Let's fix it so if that happens, we don't get a 500.

Mobile, but didn't I fix that here? https://github.com/mozilla/zamboni/commit/859a1b036ddb3de4003ed4569976795dc53bc60f

Landed here: https://github.com/mozilla/zamboni/commit/7085fb15c20a1b15ec12cf0fdadf6e521152f10a

It was a small fix, but 2 points' worth of effort were put into the sleuthing.