Sending token request to LinkedIn results in HTTP 400 error.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. On certain servers, trying to send the token requests fail with LinkedIn API 
end-point responding with a 400 error.

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

A 200 response from LinkedIn.  Instead, a 400 response is returned.

What version of the product are you using? On what operating system?

All versions, up to and including the latest version.

Is there a workaround?

Yes, by setting the OAuth method to 'GET' from 'POST' in each of 
token_access(), token_request() the issue appears to be resolved.  However, 
using GET vs. POST for token communication goes against the LinkedIn API 
documentation.

Please provide any additional information below.

Once connected on these 'problem servers', all other communications act as 
expected, including all other POST type communications.  My working theory is 
as follows:

When posting data normally, we add a UTF-8 header, as this is what LinkedIn 
requires.  However, when we are posting the OAuth tokens in the token_request() 
and token_access() methods, there is no additional XML data being posted, and 
as such we are not explicitly setting the OAuth string to a specific encoding, 
such as UTF-8.  Potentially, on certain machines, they may be communicating 
with LinkedIn in a non-supported encoding scheme, thus the 400 bad format error.

I can't verify this, as the library works as expected for me on every install.  
Maybe someone can have a look at the source, specifically the send_request() 
method to see if there may be an issue with the way I am POSTing data that 
would only come up on certain machines.

Original issue reported on code.google.com by pmmenneg@gmail.com on 27 Oct 2010 at 3:58

[GoogleCodeExporter]

Resolved in version 3.0.0 of the library; made a change to the way cURL sends 
POST requests when there is no data present, such as in the case of request and 
access tokens.  Some servers where sending the POST content as an incorrect 
type, depending on the server defaults.  Now explicitly force the content into 
correct format.

Original comment by pmmenneg@gmail.com on 4 Jan 2011 at 9:32

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by p...@fiftymission.net on 11 Nov 2011 at 5:14