Great, I'm glad that you were able to spot the part of the pipeline where
things came apart.

The strictness with these encoding issues is a pain, but the alternative of
processing authorization requests in every possible permutation and looking
for a matching signature would be a nightmare and encourage some bad
practices...

Let us know if you run into any other issues.

@episod <http://twitter.com/episod> - Taylor Singletary


On Thu, May 5, 2011 at 5:12 PM, TheMouth <[email protected]> wrote:

> HI once more,
>
> I reread your response, had a few more cups of coffee and found a semantic
> issue in our code that was causing the issue.
> I feel a post mortem may be in order just in case any unfortunate soul
> stumbles upon the same issue and starts googling.
>
> We're using PHP and CURL to make the request.  What was happening was that
> while we were properly encoding the parameters to generate the oauth
> signature and when we set the POST status using CURLOPT_POSTFIELDS, we had
> failed to encode the status when generating the (comma separated) http
> headers set using CURLOPT_HTTPHEADER.  The unencoded comma in the header of
> course made the headers invalid.
>
> Thanks Taylor. Without your nudging me in the right direction I'd probably
> still be banging my head against the wall on this one.
>
>
>  --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Reply via email to