Hello, I figured this out, it was my fault, the bug was not really the extra parameters, but an early optimization on the reuse of the SHA1 code.
Miguel. On May 21, 5:19 pm, Miguel de Icaza <miguel.de.ic...@gmail.com> wrote: > Hello, > > I was able to make progress for my original sample (?count=200) > but I am running into a different problem when I pass more than one > parameter, in this case &count=200&since_id=NNN > > I did sort the parameters as suggested by Dana from the query > string, here is my result: > > "GET&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses > %2Fhome_timeline.json&count%3D200%26oauth_consumer_key%3D******** > %26oauth_nonce%3D2gpt5qj733gpnj68%26oauth_signature_method%3DHMAC- > SHA1%26oauth_timestamp%3D1274476231%26oauth_token%3D******** > %26oauth_version%3D1.0%26since_id%3D14452646144" > > As you can see count is the first component and since_id has been > tucked at the end. > > This is the HTTP request that is sent: > > GET /1/statuses/home_timeline.json?count=200&since_id=14452646144 HTTP/ > 1.1 > authorization: OAuth > oauth_consumer_key="******",oauth_nonce="2gpt5qj733gpnj68",oauth_signature_ > method="HMAC- > SHA1",oauth_timestamp="1274476231",oauth_token="********",oauth_version="1. > 0",oauth_signature="HaWDhfKcUNBJocecm7wyYcS8VFE > %3D" > Host: api.twitter.com > > Miguel