This is what you get when debug is turned on (using the -Djavax.net.debug=ssl switch):

Thread, WRITE: TLSv1 Application Data, length = 499
Thread, received EOFException: ignoredThread, called closeInternal(false)
Thread, SEND TLSv1 ALERT:  warning, description = close_notify
Thread, WRITE: TLSv1 Alert, length = 18

In order to detect the closed connection, you actually need to perform a read on the SSLSocket’s input stream:

Socket sock = factory.createSocket(host, port);
// factory is an SSLSocketFactory() instance
// ...
// ...
// At some point, peer has already shutdown the connection
// ...
// write a byte
OutputStream out = socket.getOutputStream();
out.write(32);
// no exception here
out.flush();
// still no exception
// read something from it
InputStream in = socket.getInputStream();
int n = in.read();
// n becomes -1 here

One would expect the write to throw an exception, since the underlying socket was closed. It seems that the Apache HttpClient folks did discover this:

Due to what appears to be a bug in Sun’s older (below 1.4) implementation of Java Virtual Machines or JSSE there’s no reliable way of telling if an SSL connection is ’stale’ or not. For example, the HTTP 1.1 specification permits HTTP servers in ‘keep-alive’ mode to drop the connection to the client after a given period inactivity without having to notify the client, effectively rendering such connection unusable or ’stale’. For the HTTP agent written in Java there’s no reliable way to test if a connection is ’stale’ other than attempting to perform a read on it. However, a read operation on an idle SSL connection on Sun JVM older than 1.4 returns ‘end of stream’ instead of an expected read timeout. That effectively makes the connection appear ’stale’ to HttpClient, which leaves it with no other way but to drop the connection and to open a new one, thus defeating HTTP 1.1 keep-alive mechanism and resulting in significant performance degradation (SSL authentication is a highly time consuming operation). The problem appears to have been fixed in Sun’s Java 1.4 SSL implementation. Sockets which are not using HTTPS are unaffected on any JVM.

However, in many network protocols, there is a fixed command-response sequence so reading from the socket before writing does pose a problem. What the Apache HttpClient folks did was to wrap the socket InputStream in a BufferedInputStream, then mark the stream position, try to read a single byte from it with a timeout of 1ms. If read() returns -1 the socket is considered stale, and it resets the stream to the marked position. This is less than ideal, but probably works.

As far as I know, this problem exists on JDK versions 1.4 and 1.5.

There you go, I just wanted to throw it out there for anyone who happens to stumble on the same problem. Personally, I’ve spent a good afternoon chasing down this problem, from googling to hunting for the JSSE source code (which I gave up finding after discovering that the JDK 1.6 source doesn’t include it.)

It didn’t take long for me to find out that this affinity is uni-directional. RTM’s seeming openness is only superficial.

The story began almost a year ago.

I have been using MojiPage (my startup) daily for checking weather, reading news, and interacting with social media sites. Knowing that RTM has an API (who doesn’t these days?), I thought to myself: “how great would it be if I could write an RTM widget for MojiPage?”

So, I looked up what I need to achieve the idea, and found out that RTM issues API keys to non-commercial developers, but commercial arrangement is possible with prior arrangement. Quoting their API page:

The Remember The Milk API allows anyone to write applications that interact with Remember The Milk. At this time, the API is available for non-commercial use by outside developers (however, commercial use is possible by prior arrangement). The design of the Remember The Milk API was inspired by the Flickr API.

I’m not averse to working out an arrangement with RTM. Given that the Flickr API had similar licensing restrictions and yet they granted us a license, I couldn’t imagine it’ll be too much of a problem. So, I applied for an API key outlining my proposal to RTM.

A day, two days, god knows how many days passed.. no response.

Thinking that my message could have ended up in their spam box, I re-applied for it. Again, weeks passed without any answer, not even an acknowledgement email. I cannot recall if there was a third message that I sent, but I also tried calling the number gotten from their domain whois record, only to reach a voicemail box always. Leaving voicemail didn’t elicit any response either.

Now, I can understand that RTM is a subscription-based service, and they need to protect their revenue stream but is a response too much to ask?

For this reason, I’m migrating my personal TODO list over to Evernote, which looks more feature-complete over what RTM offers. I’m looking forward to it.

The request from Emanuel came almost serendipitously 2 days after =les nonchalantly asked me if I had plans to update it to FF3, to which I answered “one of these days.”

New in this version are 2 patches from Michael Krelin which adds detection of URIs for more OpenID versions, and the handling of append attribute values. Changelog for the patches are available at his git repository.
Thanks, Michael!

Due to what seems like a new security restriction that protocol handlers are not allowed to link to chrome URIs, I can’t seem to get it to load the CSS and icons from the chrome any more. Therefore, those files are now hosted remotely at xrid.net so if you see requests to that host, please don’t be alarmed.

Occasionally, I find myself needing to think of a product name or domain name for a web site. Ideas can knock on my head at any time: at lunch, in the toilet or waiting in the queue. I could note it down on a generic note taker on the phone, or jot it down on a piece of paper, but nothing beats being able to instantly find out if the domain is available and keep track of it in a dedicated app. Hence, DomainTool was born.

As with any great app, it should be simple to use, and addresses a focused need. Thus, you’ll find the following grand feature list:

• Query WHOIS servers to find out if a domain name is taken. Similar to the command line whois tool
• Bookmark a domain name, and query it again anytime
• Supports all TLD that has a published WHOIS server: COM, NET, ORG, BIZ, INFO, CC, JP, CN, TW, KR, MY, SG, PR, DE, EU, and many more!
• Supports Internationalized Domain Names (IDN)

Some screenshots:

By now, I suppose you’re dying to try it out on your iPhone, and I can certainly sympathize with that. It can be yours for USD0.99 (or the equivalent in your currency) — 70% of which goes to my coffee bank, and the rest goes to Mr. Jobs.

Get it here!

There were some talks about how VRM relates to DataPortability on the DataPortability-Public mailing list. In particular, this excerpt of a blog post from Adriana Lukas sums up the “What’s in it for business” aspect very well:

What’s in it for businesses?

We live in an increasingly decentralized world with more customer choice, yet vendors continue to fiercely collect and control customer data and exploit the opportunities therein. The ultimate goal of VRM is better relationships between customers and vendors, by considering and constructing tools that put the customer in control of their data and ultimately their relationships with other individuals, companies and institutions.

Benefits of ‘letting go’ of customer data:

• Customers share the burden of storing and protecting the data - eases compliance, privacy & security concerns
• Increased access to information about customers - direct benefits to the customer to share more data rather than less.
• New services from previously unavailable access to customer data

The first bullet is a good point that I had never thought about, and is a very practical benefit. The second point is a classic example of “less-is-more”; maintain less control, and gain more in return. The third point being direct consequence of the second.

When will we see the first product that presents a holistic solution with tangible benefits of VRM to companies, as well as integration with / transition from their existing CRM systems?

jchristabelle: OpenID真的很難記，我又忘了我的。

which translates to:

OpenID is really hard to remember, I forgot mine again.

I have shared that sentiment before, when I tried to login to my Plaxo account and couldn’t for the life of me remember which one it was that I first used to associate my account. Granted that, in my case, I have many OpenID URIs because I’ve been so involved in the implementation. However, it is true that the OP:RP ratio is still too high (counting Blogger as a single RP rather than thousands of OpenID-ready spam blogs.)

I think it is inevitable that in future most users will have at least a handful of OpenID URIs. One can easily imagine getting one from each webmail/IM provider, personal i-name or domain name, social networks, etc. It may just be one of those annoyances we have to live with. Or maybe users will just remember the brands that stick, and click on the “Sign in with my Yahoo! ID” button instead.

I don’t have a solution here, just relaying the message.

p.s. Incidentally, geeks are of course still able to use URIs within their control (personal domain) to delegate to another OP (e.g. Yahoo) and switch OP at anytime while keeping the original URIs. For example, here’s what I use.

I experienced a problem while testing my application on the excellent Joyent Facebook Accelerator, which runs Solaris Nevada snv_67 X86, has memcached 1.2.2 with libevent 1.3b2 installed by default.

My memcached usage is pretty low and I refresh the cache often to keep it from going stale, but somehow I still get lots of cache misses. By elimination, I ruled out the possibility of faults on the python memcache module, or memcached version (tried the latest 1.2.4 compiled against the libevent-1.3b2 and it still had the same problem.) When I connected my app to the memcached instance running on my FreeBSD box, though, the problem doesn’t exist.

Eventually, it turns out that memcached disconnects the client and all I got from the python memcache module was:

  File "/opt/local/lib/python2.5/site-packages/memcache.py", line 846, in recv
    'read returned 0 length bytes' % ( len(buf), foo ))

Well, that’s another bug. The above foo should really be rlen, but fixing that only proved that memcached always disconnects the client after sending 66887 bytes in response to a get.

After some poking around (by inserting prints and running memcached in foreground mode), it was apparent to me that memcached was getting an error from libevent, so I upgraded libevent and problem was solved.

Hope this helps anyone who may run into the same problem (as I couldn’t find any clue in the googs.)

This goes to show that when it comes to ads, creativity pays off.