Thanks for your response. The crux might be
> Normalizing spaces to %20, and avoiding "+" is also a best practice.
tweetstream4j uses Apache's HttpClient 4.0 (see
). I believe
if a request has application/x-www-form-urlencoded params, HttpClient
URL-encodes (i.e. space => +), and one can't percent-encode beforehand
because the param will be double-encoded, e.g. foo%20bar => foo
%2520bar instead of "foo bar". One also can't avoid the HttpClient URL
encoding by using a different type of param, because then the params
are not labeled application/x-www-form-urlencoded.
I wouldn't be surprised if twitter4j and tweepy were in a similar sort
of bind, though I have not verified.
Can you elaborate on why avoiding + is so important? I would hate to
have to patch Apache's HttpClient.
Also, do you know of any Java or Python library that gets this right?
On Nov 10, 8:56 am, Taylor Singletary <taylorsinglet...@twitter.com
> Think of it this way.. a valid POST body already must contain
> application/x-www-form-urlencoded encoded values for the body to be valid.
> Normalizing spaces to %20, and avoiding "+" is also a best practice. OAuth
> kicks in after you've already constructed a valid POST body.
> Here's an example of tracking a term with a space character in it: "twitter
> == POST Body
> == signature_base_string
> == Authorization Header
> Authorization: OAuth
> oauth_signature_method="HMAC-SHA1", oauth_timestamp="1289400791",
> oauth_signature="jaEvelmcrQOkHdWADBvwZsQeGiQ%3D", oauth_version="1.0"
> On Wed, Nov 10, 2010 at 1:38 AM, Ciaran <ciar...@gmail.com
> > Try ui-encoding them first, my understanding of the Twitter OAuth
> > signature validation is that it is non-standard (although there
> > appears to be debate about this) I suspect if you encode them first
> > before signing the url it will start to work
> > -cj.