format patches to support serializing data out in the correct format with correct http request headers per http method type
Reported by rbpandey | June 19th, 2008 @ 11:30 AM | in 2.1.1
Currently all data is serialized out in XML for PUT and POST requests even when you choose JSON as your exchange format. The simple fix was to remove all references when serializing data with the to_xml method and replace them to use a method which passes through the selected format's encode method (ex. ActiveResource::Formats::JsonFormat.encode). Please see the ActiveResource::Base.encode method in the patch.
Secondly, the proper format based http request headers were not being set. Constructive requests (POST/PUT) should be using the 'Content-Type' header to describe the format of their payloads, while DELETE and GET requests should be using the 'Accept' header to indicate what format of data they will accept from the reqeust in question. So you would have something like:
Content-Type:application/xml (for POST/PUT)
Accept:application/xml (for GET/DELETE)
Thirdly, this also helped me uncover that the CustomMethods "post" instance method was only serializing data to_xml when the body provided to that method was explicitly nil. This would never happen because the default "body" argument to that method was an empty String, hence data was never serialized to_xml.
Lastly, the http_mock.rb did not take into account request payloads, which are quite important to testing. I modified the mock to support a request_body parameter as well as the ability to override the format based request header for testing the various formats. It is backwards compatible with the current tests.
All the tests run.
Comments and changes to this ticket
-

-

Doug Ramsay June 19th, 2008 @ 11:43 AM
+1.
The changes to the request headers follow RESTful principles. And calling .nil? on the default empty string body argument was apparently an oversight.
-

-

rbpandey June 19th, 2008 @ 01:49 PM
The latest patch file includes an update to support parsing errors from both xml and json per the validations.rb class.
-
-
rick July 4th, 2008 @ 01:53 AM
- → State changed from new to open
- → Assigned user changed from to rick
- → Tag changed from to activeresource bug patch
- → Milestone changed from to 2.1.1
Shouldn't #to_json in #encode take an options hash too? Also, is #encode really the right name for it? #serialize maybe?
-

rbpandey July 7th, 2008 @ 10:32 AM
Rick, good catch, I have attached another patch file which includes the to_json(options) call.
As for the naming, I'll leave that for the community to decide. I prefer "serialize" myself as that is how I had named my original implementation, but after seeing DHH's implementation I didn't want to start renaming things.
-
Tarmo Tänav July 15th, 2008 @ 06:55 PM
Added a patch that fixes the whitespace errors added by formats_patch.diff
-

rbpandey July 17th, 2008 @ 10:27 AM
TT, I don't think you patched the latest patch. Thanks anyway though, I'll make the correction and submit a new patch. Thx, -RBP
-

rbpandey August 12th, 2008 @ 01:39 PM
i think TT patched the patch for whitespace issues. so we don't really need another patch.
-
Jeremy Kemper August 29th, 2008 @ 08:11 PM
- → Assigned user changed from rick to Jeremy Kemper
Could you rebase against master?
-

Repository August 29th, 2008 @ 08:47 PM
- → State changed from open to resolved
(from [caabe228bc6c6e920043334d717e72093559e118]) Format related patches to support serializing data out in the correct format with correct http request headers per http method type [#450 state:resolved]
Signed-off-by: Tarmo Tänav tarmo@itech.ee Signed-off-by: Jeremy Kemper jeremy@bitsweat.net http://github.com/rails/rails/co...
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Source available from github
The Git repository resides at http://github.com/rails
Check out the current development trunk (Edge Rails) with:
git clone git://github.com/rails/rails.git
The latest development for the 1.2.x and 2.0.x releases are on the 1-2-stable and 2-0-stable branches.
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.
Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".
