callback is double-urlencoded in python lib

[GoogleCodeExporter]

What steps will reproduce the problem?
1. provide a callback
2. call to_url() to put it in the the GET parameters

What is the expected output? What do you see instead?

resulting url has 'http://' replaced with 'http%253A%252F%252F' instead of
'http%3A%2F%2F' (the '%' gets encoded again)

What version of the product are you using? On what operating system?
  current trunk, os doesnt matter

Please provide any additional information below.

Original issue reported on code.google.com by dinkuma...@gmail.com on 2 Oct 2008 at 4:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here's a patch. 

Original comment by Hiroaki.Kawai@gmail.com on 22 Oct 2008 at 1:17

Attachments:

• 43.patch

[GoogleCodeExporter]

I assume this is because in OAuth Core 1.0 spec, section 9.4.1 describes "The 
result 
MUST be encoded again.". The spec is ambiguous. I assumed that the string in 
the 
example might be a partial string in query string (GET method), reffering the 
example in section 9.1.1.

So, OAuth python library is double encoding.

Original comment by Hiroaki.Kawai@gmail.com on 24 Oct 2008 at 1:06

[GoogleCodeExporter]

Sorry I couldn't understand this sentence: "I assumed that the string in the 
example
might be a partial string in query string (GET method)"

I am redirecting the user to the authorization page over GET (not POST) if that 
is
what you are saying.  But, as far as I can tell, none of the other libraries are
doing this.  To top it off, Netflix's OAuth implementation does not urldecode 
twice,
so the redirect back to my page doesnt work.  So I assume that this is the 
problem,
and not everyone else...

Original comment by dinkuma...@gmail.com on 24 Oct 2008 at 3:02

[GoogleCodeExporter]

Sorry, I did not describe well what I wanted to mean. I think this is actually 
a 
library's bug, and thought about why this happened. I assumed that this was 
introduced by misunderstanding of the spec. Why misunderstood? Because the spec 
is 
so misleading.

The spec allows three method to pass the parameters, GET(in query string), 
POST(as 
Content-type: application/x-www-form-urlencoded), http header(Authorization: 
OAuth ....params). 

The example in the spec section 9.4.1 is:
 oauth_signature=djr9rjt0jd78jf88%26jjd999tj88uiths3 
This is not a good example, because this is not what appears in case in http 
header.

If you choose GET, the URL might be 
 http://example.com/..../path?query=value&....&oauth_signature=djr9rjt0jd78jf88%
26jjd999tj88uiths3&.....
Or, you choose POST, the body might be
 query=value&....&oauth_signature=djr9rjt0jd78jf88%26jjd999tj88uiths3&.....
Or, you choose http header,
 Authorization OAuth query="value",
  ...
  oauth_signature="djr9rjt0jd78jf88%26jjd999tj88uiths3",
  .....

The spec says "The result MUST be encoded again.", this is ambiguous. So, I 
assume 
this bug was introduced.

Original comment by Hiroaki.Kawai@gmail.com on 24 Oct 2008 at 4:18

[GoogleCodeExporter]

Thanks for catching this bug! It's fixed now.

Original comment by leah.culver on 14 Jan 2009 at 9:03

• Changed state: Fixed
• Added labels: Lib-Python