System update notice: January 15, 2010

Later today, we will be rolling out some system upgrades, so there might be some occasional system instability while the update deploys. Normal service shouldn't be disrupted significantly. The update includes a lot of changes, most of which will hopefully be invisible to users, but will help performance and stability on the back end.

There will be an exciting new feature (which will be followed in a few weeks by others) and the search API format will change slightly - details to come shortly.

As normal, the community site and the blog will be unaffected by the update, and you can also follow us on Twitter for updates: @pachube and @pachube_dev.

Re: System update notice: January 15, 2010

We've had some reports of problems for users that have previously been sending updates to the api using a POST request masquerading as a PUT request by means of a _method parameter attached to the request.

For example: POST /api/1234.xml?_method=put type requests have been reporting errors, with updates not being processed properly by the system.

It appears that this difficulty has been caused by a change to the way the Rails application handles faked PUT requests. Previously just having this parameter was sufficient to inform the code that the incoming POST request should be treated as if was actually a real PUT, but this behaviour seems to have changed.

We'll need to look into this further to see if the original behaviour can be reinstated, but in the mean time, the recommended solution is to send an additional header, indicating the HTTP method the request should be treated as.

The header that the Rails app is looking for to define the request type is: X-Http-Method-Override, so this extra header would be sent along with your API key in the request. To give an example using Curl, it might look something like this:

curl -X POST -H "X-PachubeApiKey:[api key]" 
-H "X-Http-Method-Override: put" -d <eeml></eeml> 
http://www.pachube.com/api/feeds/1234.xml

This method is recognised by our application code, so while we look into whether we can easily revert to the previous behaviour, it should allow clients unable to send real PUT requests to continue to send updates.