IE and Chrome/Firefox see different expiration date on cookies

I was puzzled recently by a cookie problem that can only reproduced on IE and cannot be seen on Firefox and Chrome. The cookies generated by a testing server were set on Firefox and Chrome, but were rejected by IE. This resulted in that a user cannot access any protected resource right after logged in. After struggling with both the server and the client for abouting three hours, I read the messages line by line with wide open eyes and found a fresh cookie was already expired when it was sent to a client. The root reason was the test server's system time is about 24 hours behind.

The browsers I used to test are all the latest stable versions, but I assume it reflects how these three browsers check whether a cookie is expired. Since the expiration date/time in the Set-Cookie header is indeed expired when the client sees it in the response, IE's approach seems valid at the first sight. This approach is also straightforward to be implemented.

We all know that any system's clock is inaccurate, and the clocks of a server and a client are not synchronized in most cases. If the clocks are not too off the "true" time, and the cookie's age is not too short, and the cookie delivery latency is not too long, the approach of judging expiration by Expires header should work fine. However, what if these assumptions are wrong?

In such cases, Firefox and Chrome use more information to tell if a cookie is expired. The other piece of information is the Date header.  With both Date and Expires headers, the client interprets how long the cookie can be valid from the local "now" on.  I think this is a more realistic approach to handle the problem in a distributed environment.

When email box sizes were increased 10 years ago

Ten years ago, all the major email service providers increased their free storage size as a response to Google's 1GB offer.  Microsoft increased to 250MB, and Yahoo increased to 100MB. Obviously, the bigger seemed beautiful. The size in fact reflected the technology capability that each company can handle and also the vision for the future at that moment. All these in turn determined how they performed in the area of cloud computing and big data in the last 10 years. It is so interesting to look backward and connect the dots.

201 or 303

Post/Redirect/Get is a common pattern to create a new resource and then load the representation of the new resource in browser. An advantage of this pattern is to prevent duplicate form submission when a user clicks the browser refresh button after the Post request. The response code of the Post request is 303 if the request is successful. The browser will always redirect to the Location link in the 303 response header.

Unfortunately, this behavior can be confusing when the Post request is sent via AJAX. That means JavaScript will see response code 200 directly instead of 303 when the Post is successful. The AJAX engine inside a browser has no way to stop at the 303 and prevent the redirection. Furthermore, JavaScript will normally see the HTML representation of the new resource in the response. This can be confusing when you want to control what the page to do when the new resource is created and load the JSON representation of the new resource. In this case, 201 is obviously better than 303, because the JavaScript can decide how to notify the user and also furthermore how to load the new resource into the current page or redirect.

Make the moment live with livestamp

Livestamp.js is a neat library that update your moment().fromNow() timestamps with js timer. By default, the update interval is one second, which is too short considering that the from now time shows update every minute. If you set the interval by $.livestamp.interval(int), then you will need to call $.livestamp.resume() in order to prevent the delay on a newly created live timestamp. An example is here.

Traveler application user manual

Since last year, I have been working on a web application to create, manage, and share forms and travelers. A traveler contains a sequence of actions defined by a user in a form. An action requires a person to verify the action is performed and/or collect data as defined in the form. The traveler application records who collects what data at what time before the traveler is completed. It is quite similar to Google Form that used Google speadsheet as the data storage and management interface in that the user defines the form in a WYSIWYG way. The major difference is that Google form is implemented for a survey-like application that collects multiple pieces of data for each form, while the traveler is designed for a workflow-like application that collects one piece of data with revision history from multiple users. The full user manual page is now on github (via rawgithub).

The form builder


The traveler

Introducing node.js to Java developers prezi

A prezi developed for my colleagues.

REST introduction prezi

I developed a new version of REST introduction presentation with a case study of RESTful design and development process.