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
