The encoding is not inconsistent, the URL is just being used in two different situations with two different requirements.
The URL starts off un-encoded in your app. The second example you posted is the value that will be passed to the server as a header, so it must be URL-encoded (that's once).
The signed Authorization header is
listed as: OAuth
oauth_nonce="QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk",
oauth_callback="http%3A%2F%2Flocalhost%3A3005%2Fthe_dance%2Fprocess_callback%3Fservice_provider_id%3D11", ...
Then, the values of all of the OAuth header parameters must be combined with the other required values to create the base string for signing. The base string is created from the values as they are passed to the server. So you are taking the value you are passing to the server, your already-encoded URL, and combining it with other values, each of which must be URL encoded, to form a new string separated by &
.
You can see why this must be done, as the third section of the base-string contains the query parameters which have values already URL encoded (like the oauth_callback
) and uses &
as a separator. In order to combine this query parameter list (containing &
) into the base string safely (also using &
as a separator), it must be URL encoded again before being concatenated. At this point the oauth_callback
has been encoded twice, once on its own, and once as a part of a larger combined value:
The signature base string is listed
as:
POST&...oauth_callback%3Dhttp%253A%252F%252Flocalhost%253A3005%252Fthe_dance%252Fprocess_callback%253Fservice_provider_id%253D11%26oauth_consumer_key%3D...