Die Kodierung ist nicht inkonsistent, die URL wird nur in zwei verschiedenen Situationen mit zwei unterschiedlichen Anforderungen verwendet.
Die URL beginnt in Ihrer Anwendung unverschlüsselt. Das zweite Beispiel, das Sie gepostet haben, ist der Wert, der als Header an den Server weitergegeben wird, also muss er URL-kodiert sein (das ist einmalig).
Der signierte Autorisierungskopf lautet aufgeführt als: OAuth oauth_nonce="QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk", oauth_callback="http%3A%2F%2Flocalhost%3A3005%2Fthe_dance%2Fprocess_callback%3Fservice_provider_id%3D11", ...
Anschließend müssen die Werte aller OAuth-Header-Parameter mit den anderen erforderlichen Werten kombiniert werden, um die Basiszeichenkette für die Signierung zu erstellen. Die Basiszeichenkette wird aus den folgenden Werten erstellt wenn sie an den Server weitergeleitet werden . Sie nehmen also den Wert, den Sie an den Server übergeben, Ihre bereits kodierte URL, und kombinieren ihn mit anderen Werten, die alle URL-kodiert sein müssen, um eine neue Zeichenkette zu bilden, die durch & .
Sie können sehen, warum dies getan werden muss, da der dritte Abschnitt des Basisstrings die Abfrageparameter enthält, deren Werte bereits URL-kodiert sind (wie der oauth_callback ) und verwendet & als Trennzeichen. Um diese Liste von Abfrageparametern zu kombinieren (die & ) sicher in die Basiszeichenkette (auch mit & als Trennzeichen), muss es vor der Verkettung erneut URL-kodiert werden. An diesem Punkt wird die oauth_callback wurde zweimal kodiert, einmal als eigenständiger Wert und einmal als Teil eines größeren kombinierten Wertes:
Die Signatur-Basiszeichenfolge ist aufgeführt als: POST&...oauth_callback%3Dhttp%253A%252F%252Flocalhost%253A3005%252Fthe_dance%252Fprocess_callback%253Fservice_provider_id%253D11%26oauth_consumer_key%3D...
