Help with submission- "not all request variables are set - no POST parameters"

I'm attempting to develop my own plugin for use with Rhapsody, and no matter what I do, I keep getting this same error when posting:

"FAILED Plugin bug: Not all request variables are set - no POST parameters"

But the post parameters are correct- I've tried redirecting the post to another script of mine and everything looks A-OK.


Here's the raw body of an example POST I'm sending:

u=praetorian42&s=1159d531db408ddd2aec1da7785e9c9c&a[0]=Animal+Collective
&t[0]=Did+You+See+The+Words&b[0]=Feels
&m[0]=e6d32771-439d-42b6-a5e5-f72b0df1e295&l[0]=315
&i[0]=2006-12-06+21%3A39%3A17&

(without the line breaks, obviously)

Anyone have any idea why this is happening? The only thing that seems odd is the trailing ampersand, which is there according to the specs, and leaving it off doesn't make a difference anyways.

I got this error as well.- NOW.. my own client has worked for several years but now I get this error too. I couldn't find any bug after a quick check against the 1.1 specs. I tried another client client library (Jscrobbler) and the same things happened there.
Has anything changed recently? I also get tons of "database too busy" so it is hard to test the code.

Hiya,

I've been certain that my plugin's been absolutely, spot on, and positively correct for a long time. Really, REALLY sure. And yet, I still get the 'FAILED Plugin bug: Not all request variales are set - no POST parameters' error message every so often. In the past I have contested that this has been due to a server fault where the server times out and responds before the entire request has been sent. It only happens when my network connection is busy enough to delay the sending of the requests, and is mitigated by using a proxy between the two.

However, I got frustrated by seeing these messages from my plugin again and again so I went through the code to confirm that I REALLY am sending the correct length of post data and I REALLY am actually sending the body of the data. The code looks perfectly correct.

So, this afternoon I decided to run tcpdump on my gateway to capture the conversation so that I could be REALLY sure that my code is doing what it should do. I have placed a copy of this dump on my server for anyone who is interested to see.

http://usenet.gerph.org/AudioScrobbler/3AS-TCPDump.tcpdump
- the raw tcpdump data which you can use in tcpdump or ethereal or anything else that will read them.

http://usenet.gerph.org/AudioScrobbler/3AS-Conversation.txt
- a decoded form of that conversation, produced by ethereal and annotated by me (because you don't get colour in text files).

My interpretation of this is that my original assertion is correct. The remote AudioScrobbler server has responded BEFORE I've sent the POST body - it's actually responding that I haven't sent one. It's right. I'm still talking to it, and it's stopped listening. In fact it even closed the connection (the FIN in the log) before I could send the body data.

From the timestamps :
0.000000 Connection started with proxy
0.001562 Connection established with proxy
0.522984 Start transmission of 'POST' to proxy
0.538242 Headers completely sent to proxy, ending at the \r\n\r\n sequence which delimits the body
0.725635 Proxy forwards server's response header and body, stating that no variables were set
0.826189 Proxy closes the connection in response to connection closed by server (FIN sent to my client)
0.889697 Client transmits the body to the proxy
0.889762 Proxy responds with a RST, because the connection's already closed

The entire conversation lasts under a second.
The time between the client sending the request headers and a response from the server coming back is under 20cs (0.725635 - 0.538242 = 0.187393 seconds).

I believe that this proves that there is SOMETHING wrong.
It might be contested that my request is invalid and if it is I really want to know how - because I've been through the protocol in a quite a bit of detail and I'd like to think that I know what I'm doing. If I don't know what I'm doing then I would prefer someone to tell me, rather than my just believing that I know it :-)
However, I've been through the code. I've looked at the AudioScrobbler protocol. I've looked at the HTTP protocol. I'm pretty sure I understand web servers and proxies reasonably well. And my conclusion from this is that the server is failing.

A HTTP POST request is not completed until the body data, of size specified by the Content-Length, has been received.
I do not believe that a timeout of < 0.2 seconds (the time between the header being sent and the response being received) is a reasonable failure period for a server.
I do not believe that a timeout of < 0.826 seconds (the time between the start of the conversation and the server giving up waiting and closing the connection after having sent a response) is a resonable failure period for the server.

I really would prefer someone to say 'you're talking rubbish, you should be sending <blah>', but at the moment it doesn't look like that's the case.

Quoth gadgetchannel:
You should probably check that you are not sending the \r\n\r\n multiple times. If you are then that would probably be interpreted as blank body data.

The dump shows that I am not sending them multiple times.

More specifically, the last header data is sent in the packet at 0.536431 and contains 'Content-Length: 175\r\n'.
The next packet sent, at 0.538152 is the separator, containing '\r\n'.
The response from the server is the next thing to be received, at 0.725635, starting with 'HTTP/1.0 200 OK\r\n' and continuing on to tell me that I've not sent any body data. Which is quite correct, I've not sent any body data because I'm still in the process of sending it and the server should still be waiting for it.

I want to be completely clear about this. I believe the header of my request is correct. The dump shows (I believe) that I'm sending the correct things to the server. The HTTP specification states that 'The presence of an entity body in a request is signaled by the inclusion of a Content-Length header field in the request message headers' (RFC1945 section 7.2, the specification for HTTP/1.0, which is what is being used). Similar wording is present in RFC2068 (section 4.3) which details HTTP/1.1, and RFC2616 (section 4.3) which supercedes RFC2068. My request indicates the presence of a body, but the body is being ignored. Really. Honest. I'm not going mad. No. :-)

Quoth Russ:
This isn't our bug then, it's a bug in Tomcat. I suggest you work around it because I don't have time to look into it myself.

What's Tomcat ? It's nothing I'm using, so I presume it must be your end, rather than mine.

The 'work around' is just to retry, repeatedly, until you get a valid response. I guess it might help to include something in the new protocol documentation that states that 'no post data sent' errors may occur with valid data and the scrobbler should just retry.