A Programmer's Life

Menu

Tag Archives: facebook

I ran into a problem trying to use application/x-www-form-urlencoded to submit a POST request to facebook site. Every was working fine when I use normal characters but when I tried using Thai character, the post that was published to facebook would be converted into some weird text.

application/x-www-form-urlencoded

This is the default content type. Forms submitted with this content type must be encoded as follows:

Control names and values are escaped. Space characters are replaced by `+’, and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH’, a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as “CR LF” pairs (i.e., `%0D%0A’).

The control names/values are listed in the order they appear in the document. The name is separated from the value by `=’ and name/value pairs are separated from each other by `&’.

And that’s it. Turns out I have to encode my String myself.

So I used URLEncoder.encode(<my string> , “UTF-8”) to convert characters like “ภาษาไทย” to “%E0%B8%A0%E0%B8%B2%E0%B8%A9%E0%B8%B2%E0%B9%84%E0%B8%97%E0%B8%A2″ and everything is working fine now.

I was trying to use this apache HttpClient to have my web application publish posts to facebook wall.

At first sight, it looks good when I test it in my local machine. I can publish posts to user wall and I’m happy.

But when I deploy it to shared server. Things don’t go as expected. My application can not post to user’s wall and spit this error instead.

org.apache.http.conn.ssl.SSLInitializationException: Failure initializing default SSL context
at org.apache.http.conn.ssl.SSLSocketFactory.createDefaultSSLContext(SSLSocketFactory.java:360)
at org.apache.http.conn.ssl.SSLSocketFactory.getSocketFactory(SSLSocketFactory.java:175)
at org.apache.http.impl.conn.SchemeRegistryFactory.createDefault(SchemeRegistryFactory.java:49)
at org.apache.http.impl.client.AbstractHttpClient.createClientConnectionManager(AbstractHttpClient.java:306)
at org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:466)
at org.apache.http.impl.client.AbstractHttpClient.createHttpContext(AbstractHttpClient.java:286)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:851)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
Caused by: java.lang.IllegalStateException
at gnu.javax.net.ssl.provider.X509KeyManagerFactory.engineGetKeyManagers(libgcj.so.10)
at javax.net.ssl.KeyManagerFactory.getKeyManagers(libgcj.so.10)
at org.apache.http.conn.ssl.SSLSocketFactory.createSSLContext(SSLSocketFactory.java:226)
at org.apache.http.conn.ssl.SSLSocketFactory.createDefaultSSLContext(SSLSocketFactory.java:358)
...32 more

I thought it might be something related to the server since the code works properly on my local machine.

You can use this method to simply update a user’s status. When you do so, the status message appears at the top of the user’s profile and on the Friends > Status Updates page. The message also appears in the stream with your application icon.

To use this method to set a user’s status do the following:

Do not include an attachment or action link. If you do, the story will get published and will appear in the stream and on the user’s Wall only. It won’t appear at the top of the profile or in the Status Updates page.

Make sure the message is no longer than 420 characters. Otherwise, an error gets returned

If you’ve used Facebook’s share functionality on an external website, you have probably by now figured out that the first time Facebook accesses the shared link, it generates a cache of the preview image and the copy. Here are a few tips to break the cache.

First, I should mention that the Facebook cache is there for good reason, to better handle load from their over 500 million users. The challenge comes in when you forgot to implement the proper meta information to make your share preview look as nice as it could, and you try to add it in after it’s been cached. You’ll change or add meta information, but Facebook still shows the older, crummy version.

This is fine for most manual share buttons, since you’re able to specify the url, but the problem comes in when you’ve got a website that people have already been sharing, with or without a share button provided.

The first time any user shared that specific url on Facebook, even if you didn’t have a share button implemented yet, Facebook cached the data.Facebook cached the preview image(s), the title and the description copy.

This caching also means that the first time you test what your site looks like in a Facebook share, it gets cached – so if the result isn’t what you wanted, you’ve now been hoist by your own petard.

Maybe you were ready, maybe you weren’t. Maybe you updated some copy, or came up with a better preview image. Either way, it can be frustrating to know that you’ve added or updated meta information and it’s still showing the older version.

It’s also a problem when you’re using the share widget that tracks the number of likes and shares from Facebook users. Changing that url, even slightly, will wipe out those stats, since Facebook sees it as a brand new url, so those 91k shares your page received will be zeroed out if you start mucking with the share url.

I’ve heard unofficial reports that Facebook caches this information for anywhere from one day to a week. This can be inconvenient at best, and cataclysmic at worst (in the case where a typo or critical copy change came down from corporate.)

Fortunately, there is a well-hidden tool that can help speed that up.

Facebook provides a URL Linter that will let you preview what your page will look like in the share preview without condemning you to being stuck with it for a week.

As you can see, the URL linter offers a preview, and some helpful debugging information about your url.

One side-effect of the URL linter is that it clears the cached data for the url you’re previewing.

Because it’s Facebook, I would recommend not abusing this tool, and instead using it the way it was intended. Breaking the Facebook share cache should be a last resort, and you’ll be better served by using it to plan ahead instead of fixing things, since Facebook could remove or change this functionality at any time.

Instead, use the linter on a url before you launch to preview what the share will look like. Use it to perfect the preview image and copy, and then go live. (Note that it will not work if your website is password-protected via htaccess or IP restrictions, since the outside world can’t access it, which means Facebook can’t access it.)

Use the debugging beforehand to make sure your page is optimized for Facebook sharing, even if you don’t plan on implementing a share button on the page itself. Someone, somewhere is going to share that bad boy, so you may as well be ready.

To learn more about the meta tags to use to specify which images and copy you want Facebook to use in share dialog, check out the share docs. (Bear in mind that some reports state that Facebook stops crawling a page after a certain number of characters, so the higher up on the page this meta information appears, the better.)