Working with Netflix

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using the Netflix example at http://github.com/kaeppler/signpost-
examples/tree/master/OAuthNetflixExample/src
2. Specifically, the call to  provider.retrieveRequestToken(consumer, 
callBackUrl);

What is the expected output? What do you see instead?
I expect to get a link to redirect the user to, I do not get anything and 
recieve an OAuthCommunicationException. A stacktrace says that this is due 
to:
java.io.FileNotFoundException: http://api.netflix.com/oauth/request_token
By ARP-poisoning my phone and using Wireshark I can see that this is 
because retrieveRequestToken uses POST when according to the Netflix API I 
should be using GET.

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

Please provide any additional information below.
Does the Netflix example code work? Should I just create my own helper 
method to make the call through GET and rely for everything else on oauth-
signpost?

Original issue reported on code.google.com by johncena...@gmail.com on 20 Apr 2010 at 12:24

[GoogleCodeExporter]

I don't think it's actually a GET vs. POST problem, although switching to a GET 
would clear this problem up. The 
underlying problem is that Signpost is sending a POST with no Content-Length, 
which the Netflix servers are not 
okay with. Adding "Content-Length: 0" might be enough to fix the problem.

Original comment by rcken...@gmail.com on 22 May 2010 at 7:27

[GoogleCodeExporter]

I've checked in a fix for this issue and have a pending pull request to get it 
into the main github repo.

    http://github.com/ryankennedy/signpost

Original comment by rcken...@gmail.com on 22 May 2010 at 8:11

[GoogleCodeExporter]

cool, thanks.

Original comment by m.kaepp...@gmail.com on 22 May 2010 at 9:55

[GoogleCodeExporter]

Nevermind, ignore that pull request. It fixed the Android issue but broke 
Signpost for normal use. Switching 
from using the DefaultOAuthProvider and DefaultOAuthConsumer to the 
CommonsHttp* versions of those 
classes fixes the problem. It seems to me that the URL implementation on 
Android is a bit buggy and not 
consistent with the JVM implementations. I'd suggest simply having Android 
users use the CommonsHttp* 
versions, instead.

Original comment by rcken...@gmail.com on 22 May 2010 at 4:41

[GoogleCodeExporter]

It is, you must not use the DefaultOAuthProvider on Android. Note to self: put a
massive shout out on the frontpage.

The reason is that Apache Harmony's HttpURLConnection implementation is buggy. 
It
sends HTTP header names in all lower-case which is illegal with respect to the 
HTTP
specification. Some Web servers like nginx allow this, but not all. For those 
who
break, the HTTP Authorization header (sent as "authorization") is simply 
discarded
and server-side message verification fails.

Original comment by m.kaepp...@gmail.com on 22 May 2010 at 4:44

[GoogleCodeExporter]

a workaround of course is to use a different signing strategy. you could, for
instance, send all OAuth param as part of the query string.

Original comment by m.kaepp...@gmail.com on 22 May 2010 at 4:45

[GoogleCodeExporter]

Why don't use CommonsHttpOAuthConsumer.java and CommonsHttpOAuthProvider?
These issue was solution in 1.2 snapshot, no?

Original comment by tatolu...@gmail.com on 2 Jun 2010 at 2:54