check for empty params

[Asmod4n]

Am writing a etcd client, the server throws a http 5** error when a questionmark is added without params.

So this is needed.

[Asmod4n]

Oh and, would be nice if you could release 0.5.1 then asap ^^

[tarcieri]

Hmm, looks like the build is breaking on 1.8?

@sferik as soon as we get the #close bug licked I really think we should release 0.16. It's been too long since a release IMO.

[sferik]

@tarcieri If you look at the build failures, it’s failing because it can’t install celluloid on Ruby 1.8. This is odd because guard-rspec (which requires guard, which requires listen, which requires celluloid) is excluded from Ruby 1.8 in the Gemfile.

As for the release v0.6 release, we have a v0.6 milestone with 5 open issues. If you want to move any of those issues out of the milestone, we should talk about it. IMHO, these are all blockers that need to be addressed before we can ship the next release.

[jwinter]

I can't repro this issue, even on 0-5-stable. I've tried:

HTTP.get('http://www.google.com/?').to_s
HTTP.get('http://www.google.com/?', params: {}).to_s                                                             
HTTP.get('http://www.google.com/', params: {}).to_s

@Asmod4n can you provide either a test or some example code that fails?

[ixti]

@jwinter Issue is specific to etcd, which responds with HTTP 5XX when query has traling ?.

[jwinter]

Thanks @ixti. It looks like 83a7d15b adds this check. Can this can be closed then?

[Asmod4n]

Some etcd API methods 5XX when you add a empty query param, this is a fix for the 0.5 release, so if you '~> 0.5' http you'll get the fix.

Von einem mobilen Gerät gesendet

Am 12.03.2014 um 14:50 schrieb "Aleksey V. Zapparov" notifications@github.com:

@jwinter Issue is specific to etcd, which responds with HTTP 5XX when query has traling ?.

—
Reply to this email directly or view it on GitHub.

[Asmod4n]

@jwinter not for the 0.5 branch.

[tarcieri]

@Asmod4n need to ship 0.6 soon ;)

[ixti]

@sferik @tarcieri While we should "ship 0.6 soon", I think it worth merging this PR (it's against 0.5-stable branch) so that those using that branch will get benefit.

[sferik]

@ixti Are you suggesting we merge this into 0-5-stable, ship 0.5.1, and then git cherry-pick this commit into master? Just want to confirm.

[Asmod4n]

@sferik this is already resolved in master, was just missing in 0.5

[sferik]

I see.

[ixti]

@Asmod4n beat me to it.