cfhttp how to not encode plus sign

Question

Situation: I am trying to call the LinkedIn API from a ColdFusion CFC to get the user's profile and network (connections). The LinkedIn API states that to do this you must call a URL with scope=r_fullprofile+r_network.

Issue: ColdFusion is automatically encoding the URL, so the plus sign is getting encoded, and LinkedIn is rejecting my call. Is there any way around this? I've posted a link below to some code snippets on github which I believe illustrate the issue.

https://gist.github.com/4535364

Any help would be appreciated!

Answer 1

I have searched around on this for a bit and I am seeing lots of examples where ColdFusion is not playing nicely with the LinkedIn API. So I'm afraid if you do get passed this issue (although I have not come up with an alternative yet) another will crop up. While searching I found several suggestions from people to use the linkedin-j, A Java wrapper for LinkedIn APIs instead. Here are some of the references that I found:

Working example Coldfusion and Linkedin API

LinkedIn-J does not return educations

401 Unauthorized response. API people/~ and people/id=; ColdFusion, cfhttp

Problem updating status - 401 unauthorized - ColdFusion

linkedin-j Getting Started

Side Note Your github code example is making a cfhttp call to 'receiver.cfm' but you called the file 'cfhttp_receiver.cfm'. In this line:

<cfhttp url="http://#cgi.http_host#/sandbox/receiver.cfm?scope=#url.scope#" method="post" resolveurl="no">

Answer 2

The scope field is a space delimited list.

The + character is commonly used as a shortcut for space, since it's more readable than %20 (which is what space encodes to).

If using a plus character results in an encoded plus (%2B) being sent, then you are left with two other ways of putting the space into the URL:

1. using a literal space character, or
2. using an encoded space %20

Try both of those options, ideally using a network snifer (e.g. WireShark) so that you can see accurately what is being sent.

Update: As per comments below, %20 is correct, but the signature based string needs to be encoded again, so for that the % becomes %25, giving a result of %2520.