Need post option for long strings about rturk HOT 14 CLOSED

the diff came out strangely, the comment editor seems to thing the modified file is actually a quote or older comment...

from rturk.

OK, so the URL size is too long for a GET request and the AWS server renders a 400.

I think RTurk should switch automatically to POST based on param size. I'll fix this up and get a fix out before the weekend. Thanks for catching this.

from rturk.

great, thanks!

On Thu, May 19, 2011 at 8:29 AM, mdp
[email protected]
wrote:

OK, so the URL size is too long for a GET request and the AWS server renders a 400.

I think RTurk should switch automatically to POST based on param size. I'll fix this up and get a fix out before the weekend. Thanks for catching this.

Reply to this email directly or view it on GitHub:
#8 (comment)

-----
Golda Velez

fun with ideas: http://bTeaching.com ; having your say: http://bTucson.com
and more... http://goldavelez.com ~ http://iwhome.com

(520) 440-1420 (but I check my email a lot more often than phone)

"Who guards the guards? "
-----~-

from rturk.

Hey Mark - could you take a look at qualification_builder.rb while
you're at it? I'm trying to get my hits out without requiring the
qual test to preview, so I want to set RequiredToPreview = false. But
we have

params["RequiredToPreview"] = qualifier[:RequiredToPreview] || 'true'

um...not gonna happen.

This is really useful though, I very much appreciate the work! I find
rturk much easier to use and slicker than boto (python).

Thanks!

--Golda

On Thu, May 19, 2011 at 8:29 AM, mdp
[email protected]
wrote:

OK, so the URL size is too long for a GET request and the AWS server renders a 400.

I think RTurk should switch automatically to POST based on param size. I'll fix this up and get a fix out before the weekend. Thanks for catching this.

Reply to this email directly or view it on GitHub:
#8 (comment)

-----
Golda Velez

fun with ideas: http://bTeaching.com ; having your say: http://bTucson.com
and more... http://goldavelez.com ~ http://iwhome.com

(520) 440-1420 (but I check my email a lot more often than phone)

"Who guards the guards? "
-----~-

from rturk.

Yeah, could you file this as a separate issue on Github? It's easier to track that way.

from rturk.

sure, will do

On Thu, May 19, 2011 at 11:04 AM, mdp
[email protected]
wrote:

Yeah, could you file this as a separate issue on Github? It's easier to track that way.

Reply to this email directly or view it on GitHub:
#8 (comment)

-----
Golda Velez

fun with ideas: http://bTeaching.com ; having your say: http://bTucson.com
and more... http://goldavelez.com ~ http://iwhome.com

(520) 440-1420 (but I check my email a lot more often than phone)

"Who guards the guards? "
-----~-

from rturk.

Any reason we can't just always use POST? Why bother detecting the max length + switching at all?

from rturk.

I don't know - I do it that way now (always use POST), but maybe its
less efficient sometimes?

One note, GET automatically urlencodes all params. For the Request =
{} hash in POST, I found that the values were not urlencoded, and I
needed to do that ahead of time. I actually wound up converting
upper-ascii and other utf-8 chars into XML entities like é

--G

On Thu, May 19, 2011 at 12:26 PM, dbalatero
[email protected]
wrote:

Any reason we can't just always use POST?

Reply to this email directly or view it on GitHub:
#8 (comment)

-----
Golda Velez

fun with ideas: http://bTeaching.com ; having your say: http://bTucson.com
and more... http://goldavelez.com ~ http://iwhome.com

(520) 440-1420 (but I check my email a lot more often than phone)

"Who guards the guards? "
-----~-

from rturk.

@dbaletero - Yeah, I don't know why I wanted to switch them out originally, just going with POST makes more sense.

@gvelez I'm not sure why the encoding is not happening. POST params should be the same as GET in terms of URL encoding. But I'll update to the latest RestClient and see if this is still an issue.

from rturk.

I'll post an updated topic branch tonight, but the changes look pretty good. It did force me to get rid of FakeWeb for testing and do something more like Typhoeus' solution to allow easy response stubbing.

I'm just posting up the querystring, not the hash, so encoding won't be an issue, but ideally I'd like to figure out what's up with RestClient and its Hash handling.

from rturk.

As the current Typhoeus maintainer, I highly recommend using @myronmarston's
VCR library for stubbing. It works w/ just about every HTTP client out
there.

On Mon, May 23, 2011 at 9:47 AM, mdp <
[email protected]>wrote:

I'll post an updated topic branch tonight, but the changes look pretty
good. It did force me to get rid of FakeWeb for testing and do something
more like Typhoeus' solution to allow easy response stubbing.

I'm just posting up the querystring, not the hash, so encoding won't be an
issue, but ideally I'd like to figure out what's up with RestClient and its
Hash handling.

Reply to this email directly or view it on GitHub:
#8 (comment)

from rturk.

Great, thanks! Look forward to trying it out

--Golda

On Mon, May 23, 2011 at 9:47 AM, mdp
[email protected]
wrote:

I'll post an updated topic branch tonight, but the changes look pretty good. It did force me to get rid of FakeWeb for testing and do something more like Typhoeus' solution to allow easy response stubbing.

I'm just posting up the querystring, not the hash, so encoding won't be an issue, but ideally I'd like to figure out what's up with RestClient and its Hash handling.

Reply to this email directly or view it on GitHub:
#8 (comment)

-----
Golda Velez

fun with ideas: http://bTeaching.com ; having your say: http://bTucson.com
and more... http://goldavelez.com ~ http://iwhome.com

(520) 440-1420 (but I check my email a lot more often than phone)

"Who guards the guards? "
-----~-

from rturk.

Ok, so I ripped out FakeWeb and replaced it with WebMock which seems to do a better job at matching POST requests.

It's in branch 'post_only' and I'll update the gem when I get done testing it out in the sandbox, but all the spec pass currently on that branch.

from rturk.

This is now in version 2.4.0 of the gem

from rturk.