I'm having a problem with makeRequest and POST...

var p = {};
p[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
gadgets.io.makeRequest('http://eventful.com/', console.log, p);

This makeRequest encounters an "Internal Error" and status 500 very reliably, although this URL responds with a status 200 to POST requests: http://web-sniffer.net/?url=eventful.com&type=POST

When I substitute "eventful.com" with "web-sniffer.net", the makeRequest does not fail, which leads me to believe that the problem is related to this location (eventful.com).

makeRequest has stopped working for me for my server's URL at the moment as well. As all I get is an undefined internalError I have no idea what is happening.

As of 2 hours ago my app was working just fine and now, no matter how many times I try, I am receiving an internalError. I changed nothing.

Edit: I have determined that it has something to do with the optional parameters, most likely the fact that it's METHOD=POST since we both have that. If I just pass {} for params it works. Will test more shortly. This is what I have now and what worked just a few hours ago:

params[gadgets.io.RequestParameters.POST_DATA] = post_data;
params[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
params[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;

EDIT again: Just found this: Forum Post
It's very possible that your server is too slow. Will test mine and see if I changed something on the server to take longer than 3 seconds.

EDIT 3: I just tested my server and made it respond instantly, no issues. That's definitely what it is. Good to know.

Adam, thanks for investigating, but I am still having problems.

My server is definitely responding within the 3-second timeout. The time between the makeRequest's request and response is under 100ms (according to Firebug), so my server must be responding in under 100ms.

There has to be something else going wrong.

Have you tried removing the POST parameter? Worth a shot.

Yep, this case works fine. It's definitely something about POST. I tried varying the POST data with no changes. You should be able to copy my code and get the same results.

I'm also having this problem.  Gzipping a POST makeRequest fails.   Gzipping a GET makeRequest works.

We have determined that MySpace's POST request sends "Accept-Encoding: gzip", but fails to correctly decode the gzipped response.

The problem must be deeper than gzip, becuase the following code should trigger a gzipped response, but no error occurs:

var p = {};
p[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
gadgets.io.makeRequest('http://web-sniffer.net/', console.log, p);

In analyzing the HTTP packets sent to my server, I noticed that lighttpd appears to be mishandling the HTTP 100 Continue protocol, which results in an HTTP 417 Expectation Failed. Is it possible to disable HTTP 100 Continue for makeRequest POST requests?

A possible solution is set "RequestHeader unset Expect" in Apache configs (if you use Apache to proxy).

I looked into why eventful.com is failing, it's from a known bug where we append certain post data to each request.  When I hit the server with a POST with the bad appended data, it dies, when I hit it without it, it succeeds.  A fix for this should make it to the site shortly.

Haven't looked at he gzip stuff yet. 

Lighttpd users are out of luck with this one.. HTTP 100 Continue protocol is not supported by any stable versions of lighttpd...

Sebastian:

Lighttpd users are out of luck with this one.. HTTP 100 Continue protocol is not supported by any stable versions of lighttpd...

I think you're right, Sebastian. My sysadmin indicates that there is no known workaround to this problem on our side short of running a different service on port 80. If I could query a different port, this would not be a problem for me.

Here's my preferred solution. Currently the MySpace proxy sends the header "Expect: 100-continue," but lighttpd is incompatible with this header. Can the proxy be modified to not send the Expect header in the first place? Alternatively, when we send the "417 Expectation Failed" error back in response to the Expect header, the proxy should not try to send another Expect header.

Honestly, I don't think the 100-continue protocol is practical for MySpace applications, but I may be wrong.

Hi,

This thread discusses several things(issues with gzip, failures with extra POST data, the Expect: 100-continue issue etc.). But, looks like the main issue here seems to be that lighttpd being incomatible with the "Expect:100-continue" headers. Is this a correct assumption?

 We'll investigate this issue a bit more and hopefully get a fix out soon.

 Thanks

Chak

 

Chak:

Is this a correct assumption?

I believe so. The gzip issue was easier to solve on our end (turn gzip off), but we can't figure out this lighttpd issue.

Hi John,

 Thank you for the quick response. We'll investigate and hopefully get a fix out soon.

 Thanks

Chak