Taylor, I am having a very similar problem. I think I am missing some crucial point about the encoding method that needs to be used with twitter. THe library I am working on has successfully authenticated using Oauth with twitter. I have my access_token and access_token_secret and I want to update my twitter status. If I only send one word as my status, the update works. If I send two words separated by a space the update does not work. I get back a 401 unauthorized response to the udpate request. My signing base string POST request and response are below. As noted I have already negotiated and OAuth access token so I don't show that information.
I noticed one thing in your example that is different from my code. In my signing base string a space is encoded as %20. In yours, a space is encoded as %2520. Do you have any ideas what the difference is between your encoding method and mine? Here is my signature base string: POST&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses %2Fupdate.xml&oauth_consumer_key%3Dbt7VUyYJ4adSHxIrGJYFxQ%26oauth_nonce %3DISJERMBJCAQEYGUAWXAKQXTFPGFATRFUOQORGAMD%26oauth_signature_method %3DHMAC-SHA1%26oauth_timestamp%3D1274372472%26oauth_token %3D136131415-1kvYKiXUP8kS7yq39cGqmruDzvsF7uOoLPSK7Eh1%26oauth_version %3D1.0%26status%3Dtest%20this And the POST request I made follows below: POST http://api.twitter.com/1/statuses/update.xml HTTP/1.1 Authorization: OAuth oauth_consumer_key="bt7VUyYJ4adSHxIrGJYFxQ", oauth_nonce="ISJERMBJCAQEYGUAWXAKQXTFPGFATRFUOQORGAMD", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1274372472", oauth_token="136131415-1kvYKiXUP8kS7yq39cGqmruDzvsF7uOoLPSK7Eh1", oauth_version="1.0", oauth_signature="mkF7LWE4UqscMsjUlLQTRJFDFhg%3D" Content-Type: application/x-www-form-urlencoded Host: api.twitter.com Content-Length: 18 Expect: 100-continue status=test%20this And the POST response HTTP/1.1 401 Unauthorized Connection: Keep-Alive Connection: Proxy-Support Content-Length: 135 Via: 1.1 RED-PRXY-21 Expires: Thu, 20 May 2010 16:51:16 GMT Date: Thu, 20 May 2010 16:21:16 GMT Content-Type: application/xml; charset=utf-8 Server: hi Proxy-Support: Session-Based-Authentication Status: 401 Unauthorized WWW-Authenticate: Basic realm="Twitter API" Cache-Control: no-cache, max-age=1800 Set-Cookie: k=131.107.0.71.1274372476598501; path=/; expires=Thu, 27- May-10 16:21:16 GMT; domain=.twitter.com Set-Cookie: guest_id=127437247670844927; path=/; expires=Sat, 19 Jun 2010 16:21:16 GMT Set-Cookie: _twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCDLPhLYoAToHaWQiJTE1M2MzMzg5ODc4MzI4%250ANDlkMWMwYjFlMzZkMTlkYTdkIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy %250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA-- c409bb092a71a15b4823075255ee464267520fba; domain=.twitter.com; path=/ Vary: Accept-Encoding <?xml version="1.0" encoding="UTF-8"?> <hash> <request>/1/statuses/update.xml</request> <error>Incorrect signature</error> </hash> On May 20, 6:45 am, Taylor Singletary <[email protected]> wrote: > Hi Onn, > > It's best to consider all space characters as %20 when building both your > POST body and signature base string -- instead of using " " or "+", just get > right down to it as "%20". > > I'll show you how a pretty varied string of characters would be correctly > encoded both for the POST body and signature base string: > > Given that you want to set a status that says: "I can tweet many kinds of > characters ! (* $ @ 漢字 عربي)" > > Your POST body should have that string encoded as: > > status=I%20can%20tweet%20many%20kinds%20of%20characters%20%21%20%28%2A%20%24%20%40%20%E6%BC%A2%E5%AD%97%20%D8%B9%D8%B1%D8%A8%D9%8A%29 > > Which when passed into your Signature Base String will get URL escaped > again: > > POST&http%3A%2F%2Fapi.twitter.com > %2F1%2Fstatuses%2Fupdate.xml&oauth_consumer_key%3Dri8JxYK2ddwSV5xIUfNNvQ%26oauth_nonce%3DFt6p0YgKlI2Htdk3WLE4mthwQXVpWc9Nv9ApzoQKUg%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1274362505%26oauth_token%3D119476949-gF0B5O1Wwa2UqqIwopAhQtQVTzmfSIOSiHQS7Vf8%26oauth_version%3D1.0%26status%3DI%2520can%2520tweet%2520many%2520kinds%2520of%2520characters%2520%2521%2520%2528%252A%2520%2524%2520%2540%2520%25E6%25BC%25A2%25E5%25AD%2597%2520%25D8%25B9%25D8%25B1%25D8%25A8%25D9%258A%2529 > > The Content-Length for that fully-encoded POST body will be: 69 > > And when Twitter spits the status back at you, in my case in XML: > <?xml version="1.0" encoding="UTF-8"?> > <status> > <created_at>Thu May 20 13:35:04 +0000 2010</created_at> > <id>14361447181</id> > <text>I can tweet many kinds of characters ! (* $ @ 漢字 > عربي)</text> > <source><a href="http://realitytechnicians.com"; > rel="nofollow">Crying Indian</a></source> > <truncated>false</truncated> > <in_reply_to_status_id></in_reply_to_status_id> > <in_reply_to_user_id></in_reply_to_user_id> > <favorited>false</favorited> > <in_reply_to_screen_name></in_reply_to_screen_name> > <user> > <id>119476949</id> > <name>OAuth Dancer</name> > <screen_name>oauth_dancer</screen_name> > <location>San Francisco, CA</location> > <description></description> > > <profile_image_url>http://a3.twimg.com/profile_images/730275945/oauth-dancer_normal.jpg > </profile_image_url> > <url>http://bit.ly/oauth-dancer</url> > <protected>false</protected> > <followers_count>11</followers_count> > <profile_background_color>C0DEED</profile_background_color> > <profile_text_color>333333</profile_text_color> > <profile_link_color>0084B4</profile_link_color> > <profile_sidebar_fill_color>DDEEF6</profile_sidebar_fill_color> > <profile_sidebar_border_color>C0DEED</profile_sidebar_border_color> > <friends_count>11</friends_count> > <created_at>Wed Mar 03 19:37:35 +0000 2010</created_at> > <favourites_count>0</favourites_count> > <utc_offset></utc_offset> > <time_zone></time_zone> > > <profile_background_image_url>http://a3.twimg.com/profile_background_images/80151733/oauth-dance.png > </profile_background_image_url> > <profile_background_tile>true</profile_background_tile> > <notifications>false</notifications> > <geo_enabled>false</geo_enabled> > <verified>false</verified> > <following>false</following> > <statuses_count>31</statuses_count> > <lang>en</lang> > <contributors_enabled>false</contributors_enabled> > </user> > <geo/> > <coordinates/> > <place/> > <contributors/> > </status> > > Hope this helps. > > TaylorOn Thu, May 20, 2010 at 5:03 AM, Onn E <[email protected]> wrote: > > Hi Taylor, > > > I am using Curl to update status. > > I use POST method. > > The new status is not included in the headers, but is included in the > > POST body and in the signature base string. > > Also (and this Curl does automatically for me) I am sending the > > following header: > > Content-Type: application/x-www-form-urlencoded. > > My new status value is URL encoded (UTF-8). > > > And now to the business itself: > > I know my signature method is correct since I am able to update single > > word statuses with no special characters, such as: "hello", "ok", > > "magnificent" and such. They work just fine. > > But when trying to update statuses with characters such as: " ", "!", > > "@". It will throw me with a 401: > > {"request":"/1/statuses/update.json","error":"Incorrect > > signature"} > > > I'm attaching here the curl verbose: > > > " > > > curl -v -X POST -H 'Authorization: OAuth > > oauth_nonce="5671352764895675466", oauth_signature_method="HMAC-SHA1", > > oauth_timestamp="1274355202", oauth_consumer="**********************", > > oauth_signature="**************************************", > > oauth_version="1.0", > > oauth_token="**************************************"' -d > > "status=magnificent"https://api.twitter.com/1/statuses/update.json > > * About to connect() to api.twitter.com port 443 (#0) > > * Trying 128.242.240.61... connected > > * Connected to api.twitter.com (128.242.240.61) port 443 (#0) > > * successfully set certificate verify locations: > > * CAfile: none > > CApath: /etc/ssl/certs > > * SSLv3, TLS handshake, Client hello (1): > > * SSLv3, TLS handshake, Server hello (2): > > * SSLv3, TLS handshake, CERT (11): > > * SSLv3, TLS handshake, Server finished (14): > > * SSLv3, TLS handshake, Client key exchange (16): > > * SSLv3, TLS change cipher, Client hello (1): > > * SSLv3, TLS handshake, Finished (20): > > * SSLv3, TLS change cipher, Client hello (1): > > * SSLv3, TLS handshake, Finished (20): > > * SSL connection using AES256-SHA > > * Server certificate: > > * subject: C=US; O=*.twitter.com; OU=GT57932074; OU=See > >www.rapidssl.com/resources/cps(c)09; OU=Domain Control Validated - > > RapidSSL(R); CN=*.twitter.com > > * start date: 2009-05-26 12:14:57 GMT > > * expire date: 2010-07-27 06:10:16 GMT > > * common name: *.twitter.com (matched) > > * issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global > > eBusiness CA-1 > > * SSL certificate verify ok. > > > POST /1/statuses/update.json HTTP/1.1 > > > User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k > > zlib/1.2.3.3 libidn/1.15 > > > Host: api.twitter.com > > > Accept: */* > > > Authorization: OAuth oauth_nonce="5671352764895675466", > > oauth_signature_method="HMAC-SHA1", oauth_timestamp="1274355202", > > oauth_consumer_key="**********************", > > oauth_signature="**************************************", > > oauth_version="1.0", oauth_token="**************************************" > > > Content-Length: 18 > > > Content-Type: application/x-www-form-urlencoded > > > < HTTP/1.1 200 OK > > < Date: Thu, 20 May 2010 11:27:15 GMT > > < Server: hi > > < Status: 200 OK > > < X-Transaction: 1274354835-66746-24190 > > < ETag: "61a0fc27a676be7b50eb72042998d554" > > < Last-Modified: Thu, 20 May 2010 11:27:15 GMT > > < X-Runtime: 0.18394 > > < Content-Type: application/json; charset=utf-8 > > < Content-Length: 1212 > > < Pragma: no-cache > > < X-Revision: DEV > > < Expires: Tue, 31 Mar 1981 05:00:00 GMT > > < Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, > > post-check=0 > > < Set-Cookie: k=62.219.129.78.1274354835642625; path=/; expires=Thu, > > 27-May-10 11:27:15 GMT; domain=.twitter.com > > < Set-Cookie: guest_id=127435483564553842; path=/; expires=Sat, 19 Jun > > 2010 11:27:15 GMT > > < Set-Cookie: lang=en; path=/ > > < Set-Cookie: > > _twitter_sess=BAh7CjoRdHJhbnNfcHJvbXB0MDoPY3JlYXRlZF9hdGwrCMegd7UoAToMY3Ny > > %250AZl9pZCIlNTUxMThjYjg0ZTc2MTU2MzAwZWM1MjA1NGMxMmNlZGM6B2lkIiVm > > > %250AOTdiMWFlNTc4OGZhODM2NjRkZTRhMTdkMTgxOGFlMSIKZmxhc2hJQzonQWN0%250AaW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA > > %253D%253D--0b5f5cee23124380fd2db90ff369fee30c0122d9; > > domain=.twitter.com; path=/ > > < Vary: Accept-Encoding > > < Connection: close > > < > > {"in_reply_to_user_id":null,"contributors":null,"source":"<a href= > > \"http://www.snaptu.com\"; rel=\"nofollow\">Snaptu Mobile</ > > a>","created_at":"Thu May 20 11:27:15 +0000 > > > 2010","in_reply_to_screen_name":null,"place":null,"favorited":false,"truncated":false,"in_reply_to_status_id":null,"coordinates":null,"user": > > {"favourites_count": > > > 2,"description":"*********","contributors_enabled":false,"lang":"en","profile_link_color":"0000ff","profile_image_url":"http:// > > s.twimg.com/a/1274144130/images/ > > > default_profile_2_normal.png","geo_enabled":false,"time_zone":"Greenland","profile_sidebar_fill_color":"e0ff92","screen_name":"SnaptuDummy","following":false,"verified":false,"created_at":"Sun > > Mar 22 13:31:04 +0000 2009","profile_background_image_url":"http:// > > s.twimg.com/a/1274144130/images/themes/theme1/ > > bg.png","profile_background_tile":false,"followers_count": > > 24,"protected":false,"url":"http:// > >www.snaptu.com > > ","name":"*********","friends_count":*,"profile_sidebar_border_color":"87bc44","profile_background_color* > > Closing connection #0 > > * SSLv3, TLS alert, Client hello (1): > > ":"9ae4e8","location":"Israel","id":25817409,"statuses_count": > > > 245,"notifications":false,"utc_offset":-10800,"profile_text_color":"000000"},"geo":null,"id":**********,"text":"magnificent"} > > > " > > > Thanks you all for the support. > > Onn E > > > On May 17, 4:46 pm, Taylor Singletary <[email protected]> > > wrote: > > > Hi Gero, > > > > This particular issue looked to have been caused by a quirk in the way > > that > > > the Scribe library was encoding spaces. The library has since been > > updated > > > by the author. > > > > However, if you're still having the issue in another implementation, I'll > > be > > > happy to help. Can you share the POST body of the request and your > > signature > > > base string of when you're having the issue? > > > > Taylor Singletary > > > Developer Advocate, Twitterhttp://twitter.com/episod > > > > On Mon, May 17, 2010 at 12:12 AM, Gero <[email protected]> wrote: > > > > Hi, > > > > > Any updates on this issue? I'm running into the same problem and have > > > > not yet been able to resolve it. > > > > > Regards, > > > > Gero > > > > > On May 1, 12:42 am, Taylor Singletary <[email protected]> > > > > wrote: > > > > > Hi Pablo, > > > > > > Thanks for chiming in about Scribe. I'll take a look again soon at > > Scribe > > > > > and see if I can ascertain its potential fault (or our own if that is > > the > > > > > case). > > > > > > Keep up the good work on your OAuth library, Pablo! :) > > > > > > Taylor Singletary > > > > > Developer Advocate, Twitterhttp://twitter.com/episod > > > > > > On Fri, Apr 30, 2010 at 3:31 PM, Pablo Fernandez < > > > > [email protected] > > > > > > > wrote: > > > > > > Hi Taylor! > > > > > > > I believe Rahul is having this problem while using my library > > (http:// > > > > > > github.com/fernandezpablo85/scribe) > > > > > > > I've tested myself, I'm pretty sure the error lies in my code but I > > > > > > can't tell why :S > > > > > > > Here's the string that gets signed and the OAuth header in case > > that > > > > > > helps! > > > > > > > String to sign >> > > > > > > > POST&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses > > > %2Fupdate.xml&oauth_consumer_key%3D6icbcAXyZx67r8uTAUM5Qw%26oauth_nonce > > > %3D32c0b090041a4b233a36590a10c8749e%26oauth_signature_method%3DHMAC- > > > > > > SHA1%26oauth_timestamp%3D1272666648%26oauth_token%3D14654522- > > > ayJ064ck0Gtp1ABmjVVxMqd0OcgIG0fMRPFxN00E%26oauth_version%3D1.0%26status > > > > > > %3DScribe%2520works.%2520Hell%2520yeah%2521 > > > > > > > OAuth header >> > > > > > > > OAuth oauth_consumer_key="6icbcAXyZx67r8uTAUM5Qw", > > > > > > oauth_nonce="32c0b090041a4b233a36590a10c8749e", > > > > > > oauth_signature="hmzME2L2qAmzRYOj5P%2BBcja9ECg%3D", > > > > > > oauth_signature_method="HMAC-SHA1", oauth_timestamp="1272666648", > > > > > > oauth_token="14654522-ayJ064ck0Gtp1ABmjVVxMqd0OcgIG0fMRPFxN00E", > > > > > > oauth_version="1.0" > > > > > > > Pablo > > > > > > > PS: Kudos for developer.twitter.com. the site rocks! > > > > > > > On Apr 30, 3:34 pm, Rahul <[email protected]> wrote: > > > > > > > Taylor, > > > > > > > > Here you go. I have tried adding the content type as follows. > > > > > > > > conn.setRequestProperty("Content-Type", "application/x-www-form- > > > > > > > urlencoded"); > > > > > > > > But this doesn't help at all and i still continue receiving the > > same > > > > > > > error of incorrect signature. > > > > > > > > Any guess? > > > > > > > > Thanks,Rahul > > > > > > > > On Apr 29, 9:03 pm,Rahul<[email protected]> wrote: > > > > > > > > > Taylor, > > > > > > > > > I am presently using scribe java library for OAuth and as you > > said > > > > all > > > > > > > > spec compliant libraries the signature base string will only > > > > contain > > > > > > > > POST body parameter so does this one. > > > > > > > > > Also I will try to add the header 'Content-Type' to the library > > and > > > > > > > > let you know how it goes. > > > > > > > > > Thanks, > > > > > > > >Rahul > > > > > > > > > On Apr 29, 5:38 pm, Taylor Singletary < > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > > > Whether it matters before creating your signature or not > > depends > > > > > > entirely on > > > > > > > > > the OAuth library you are using. In spec-compliant OAuth > > > > libraries, > > > > > > the > > > > > > > > > signature base string will only contain POST body parameters > > when > > > > > > they are > > > > > > > > > of the application/x-www-form-urlencoded type -- most OAuth > > > > libraries > > > > > > need a > > > > > > > > > way to be instructed on the disposition of the content being > > > > passed > > > > > > as the > > > > > > > > > POST body and a common way is to look at an abstract request > > > > object > > > > > > of some > > > > > > > > > kind to determine the type of data being piped in rather than > > > > just > > > > > > trying to > > > > > > > > > guess or simply assuming that POST bodies will always be of > > the > > > > > > URL-encoded > > > > > > > > > type. There might be another way to instruct your library on > > the > > > > > > disposition > > > > > > > > > of data, but it's likely it'll just assume all POST data > > provided > > > > is > > > > > > of the > > > > > > > > > URL encoded variety. I don't think you have any issues with > > your > > > > code > > > > > > in > > > > > > > > > this area today. > > > > > > > > > > But as a best practice when dealing with an HTTP-based API of > > any > > > > > > kind, you > > > > > > > > > should be sending a Content-Type header whenever POSTing or > > > > PUTing > > > > > > any kind > > > > > > > > > of payload. You don't pass a Content-Type header on a GET > > because > > > > > > there is > > > > > > > > > no content being sent. > > > > > > > > > > It's likely that your OAuth library automatically sends the > > > > proper > > > > > > > > > Content-Type header on the OAuth negotiation steps because > > those > > > > > > steps are > > > > > > > > > required to use URL-encoded POST bodies by the spec. > > > > > > > > > > Taylor Singletary > > > > > > > > > Developer Advocate, Twitterhttp://twitter.com/episodOnThu, > > Apr > > > > 29, > > > > > > 2010 at 2:20 PM,Rahul<[email protected]> wrote: > > > > > > > > > > So what are trying to say is that i should explicitly add > > > > > > Content-type > > > > > > > > > > header in the message going out and that too before > > creating > > > > the > > > > > > > > > > signature? > > > > > > > > > > > Thanks, > > > > > > > > > >Rahul > > > > > > > > > > > On Apr 29, 4:58 pm, Taylor Singletary < > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > Since you're sending a status, you should be setting a > > > > > > Content-Type > > > > > > > > > > header > > > > > > > > > > > to indicate the type of payload -- it's best never to > > assume > > > > that > > > > > > a HTTP > > > > > > > > > > > server or a HTTP library will know how to understand a > > > > payload > > > > > > without > > > > > > > > > > being > > > > > > > > > > > explicitly told what kind of payload that is. The > > signature > > > > might > > > > > > be > > > > > > > > > > > mis-calculating on the Twitter side due to not including > > your > > > > > > parameters > > > > > > > > > > > when constructing it. > > > > > > > > > > > > Taylor Singletary > > > > > > > > > > > Developer Advocate, Twitterhttp://twitter.com/episod > > > > > > > > > > > > On Thu, Apr 29, 2010 at 1:36 PM,Rahul< > > [email protected] > > > > > > > wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > > To answer your questions. The following is the body > > > > response i > > > > > > receive > > > > > > > > > > > > back > > > > > > > > > > > > > <?xml version="1.0" encoding="UTF-8"?> > > > > > > > > > > > > <hash> > > > > > > > > > > > > <request>/1/statuses/update.xml</request> > > > > > > > > > > > > <error>Incorrect signature</error> > > > > > > > > > > > > </hash> > > > > > > > > > > > > > Also, I am not setting any content type header at this > > > > point & > > > > > > I am > > > > > > > > > > > > using "POST" only for token negotiation. and have not > > tried > > > > any > > > > > > get > > > > > > > > > > > > restricted resource yet. I did try some but they seem > > to be > > > > > > public > > > > > > > > > > > > timeline etc which seems to be working good. > > > > > > > > > > > > > Any help on this is highly appreciated. > > > > > > > > > > > > > Thanks, > > > > > > > > > > > >Rahul > > > > > > > > > > > > > On Apr 29, 4:22 pm, Taylor Singletary < > > > > > > [email protected]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > HiRahul, > > > > > > > > > > > > > > I'm trying to think of other reasons. We might be > > > > throwing > > > > > > the > > > > > > > > > > invalid > > > > > > > > > > > > > signature error in a case where the signature is not > > in > > > > fact > > > > > > invalid. > > > > > > > > > > > > > > How about requests are not of the type POST? Have you > > had > > > > a > > > > > > GET > > > > > > > > > > (other > > > > > > > > > > > > than > > > > > > > > > > > > > OAuth token negotiation steps) work for you? When you > > > > were > > > > > > doing the > > > > > > > > > > > > token > > > > > > > > > > > > > negotiation steps, were you using POSTs or GETs? When > > > > > > performing a > > > > > > > > > > POST, > > > > > > > > > > > > are > > > > > > > > > > > > > you setting your HTTP Content-Type header to > > > > > > > > > > > > > "application/x-www-form-urlencoded"? > > > > > > > > > > > > > > What's the exact response from the server? There's > > > > usually a > > > > > > payload > > > > > > > > > > > > > included with the response that may give more clarity > > to > > > > the > > > > > > error. > > > > > > > > > > We > > > > > > > > > > > > have > > > > > > > > > > > > > some upcoming enhancements to the OAuth > > implementation > > > > that > > > > > > will > > > > > > > > > > return > > > > > > > > > > > > to > > > > > > > > > > > > > you the "signature base string we calculated" which > > would > > > > be > > > > > > useful > > > > > > > > > > here > > > > > > > > > > > > > now.. > > > > > > > > > > > > > > Taylor Singletary > > > > > > > > > > > > > Developer Advocate, Twitterhttp://twitter.com/episod > > > > > > > > > > > > > > On Thu, Apr 29, 2010 at 1:12 PM,Rahul< > > > > [email protected] > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Taylor, > > > > > > > > > > > > > > > A quick update on this. I tried generating the > > > > signature > > > > > > from my > > > > > > > > > > > > > > library and the page mentioned below they both > > seems > > > > tbe > > > > > > exactly > > > > > > > > > > the > > > > > > > > > > > > > > same..... > > >http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signin. > > > > > > > > > > > > .. > > > > > > > > > > > > > > > What else can be the reason and how come twitter is > > > > > > responding with > > > > > > > > > > > > > > Incorrect Signature ? > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > >Rahul > > > > > > > > > > > > > > > On Apr 29, 1:19 pm,Rahul<[email protected]> > > > > wrote: > > > > > > > > > > > > > > > Taylor, > > > > > > > > > > > > > > > > Thanks for taking a look at it. and to answer > > your > > > > > > question yes I > > > > > > > > > > do > > > > > > > > > > > > > > > pass the status in the signature basetring. > > > > ... > > > > read more »
