Right now, if you normalize_param for an array, like :foo, ['bar', 'baz'], you'll get "foo[]=bar&foo[]=baz".

I'm pretty sure this is a convention that Rails uses. Regardless of its origin, not all services follow this convention. I'm wrapping the Sunlight API, and it expects a query more like "foo=bar&foo=baz".

I could monkey patch Hash#normalize_param, but that seems less ideal. Maybe HTTParty could expose a normalization hook? Maybe something so awesome I can't even fathom yet?

Reported by Josh Nichols

Right now the redirect logic resends the original query parameters on any redirects. I think in nearly all cases this is incorrect. When a 302 is encountered after a POST, it makes no sense to resend the original query parameters (I think this is also true of DELETE and PUT).

I couldn't find an authoritative answer on GET, but I believe that the Location header returned in the 302 response is to be honored in its entirety and exclusively, that is without glomming additional query parameters.

Unfortunately I've run into several web services (esp. Java ones for some reason) that send 302s to canonicalize all traffic to using trailing-slashes. For example GET /foo/bar -> 302 /foo/bar/

In this case, the practical thing to do is to probably resend the query parameters. I think the backing services probably need to be fixed to set Location to something like /foo/bar/?dude=true when /foo/bar?dude=true is sent.

Anyway...I think there's a bug there.

I think I’vs found a bug in httparty. When XML is parsed, escaped XML-characters (eg. ampersand) in attribute values are not replaced.

The method REXMLUtilityNode#translate_xml_entities is only used to unescape text values, the attribute values are left plain.

Example:

variant['url'] # "http://.../image.jpg?attr=val&attr2=val2", not "http://.../image.jpg?attr=val&attr2=val2".

What do you think?

Thanks and ciao,

der Flo

It would be nice. Someone want to do it? Yay!

I noticed you created a wrapper class HTTParty::Response that returns the same params as HTTPResponse but without the benefit of some of the methods like value() and comparison ability to things like HTTPSuccess, HTTPClientError, etc, so I have to hand roll some exception handling code to mimic this behavior rather than using the built in goodness from http/net.

Would it be possible to simply return the HTTPResponse rather than wrapping it?

I think it may be a Crack problem, but if I make a get request returning the following XML (with format :xml set) the second 'package' appears inside the first, instead of as a sibling. (YAML output follows)
(The xml is from the Remote Control plugin used with JDownloader or JDownloader.org)

XML seems valid to me, looks like a parsing problem.

-- XML data --
-- End XML --

-- YAML of HTTParty interpretation --

package:
package_percent: "77.38" package_todo: 83.62 MB package_ETA: 00:-1 package_linkstotal: "4" package_size: 369.72 MB package:

package_percent: "0.00"
package_todo: 367.97 MB
package_ETA: 00:-1
package_linkstotal: "4"
package_size: 367.97 MB
package_linksinprogress: "0"
package_speed: 0 KB/s
package_name: More Rapidshare things
package_loaded: 0 KB
package_id: "1"

package_linksinprogress: "0" package_speed: 0 KB/s package_name: My Rapidshare things package_loaded: 286.10 MB package_id: "0" -- End YAML --

if I have format :xml and get a response with something like this in it:

\url\
\url\

the hash created is {'poster' => ['url', 'url']} and the sizes are lost.
Would it make sense to have it parsed something like this:

{'poster' => [{'size'=>'original', 'poster'=>'url'}, {'size'=>'mid', 'poster'=>'url']}
that way no data is lost. Open to other suggestions.

given:

class EnterpriseService
  include HTTParty
  format :plain

  def shared_function
    "some value"
  end
end

class MyService < EnterpriseService
  base_uri "some.server:4000/my_service"
end

class YourService < EnterpriseService
  base_uri "some.server:4000/your_service"
end

when using in development mode:

  $ script/console development
  >> MyService.base_uri
  => "some.server:4000/my_service"
  >> YourService.base_uri
  => "some.server:4000/your_service"

when using in production mode:

  $ script/console production
  >> MyService.base_uri
  => "some.server:4000/your_service"
  >> YourService.base_uri
  => "some.server:4000/your_service"

problem:

when I include HTTParty in a class that I'm planning on subclassing (in order to share functions and HTTParty), each subclass works fine when running in development mode. Once I switch to production, each subclass winds up with the same base_uri as the last class to get loaded (in alphabetical order).

The culprit seems to be "config.cache_classes = true"

I'm not entirely sure how to fix this or if it's even possible to fix in HTTParty itself, but for now, my workaround has been to simply include HTTParty and specify the HTTParty options separately in each subclass rather than doing it only once in the main class.

I'm getting an intermittent REXML::ParseException when hitting the Technorati API, and it's very difficult to understand what's going on when you don't have access to the raw response body. There should be a way to get access to that when things go wrong.

/Library/Ruby/Gems/1.8/gems/httparty-0.4.3/lib/httparty/core_extensions.rb:9: warning: method redefined; discarding old write

/Library/Ruby/Gems/1.8/gems/httparty-0.4.3/lib/httparty/request.rb:18: warning: method redefined; discarding old path=

/Library/Ruby/Gems/1.8/gems/httparty-0.4.3/lib/httparty/request.rb:26: warning: instance variable @redirect not initialized

Fixed with this patch

http://github.com/ddollar/httparty/commit/9c08f68503864d06aea05177ce0f46a437822f26

A request for http://www.myurl.com/sample turns into something like http://www.myurl.com/sample?&&&&& before the request is fired off

This isn't a problem for many sites, but it turns out to be a problem for mine.

Suggested fix is in the request class:
query_string_parts << options[:default_params].to_params unless options[:default_params].nil?
should be
query_string_parts << options[:default_params].to_params unless options[:default_params].empty? (since it's an empty hash by default)

Thanks! Should be just a quick fix :)