Hi all. I’m currently writing a library in C# / .NET which calls the LiveJournal flat API using challenge‑response authentication. For now it’s just a little project on the side, and so far I have implemented the “login” and “checkfriends” methods.
The problem I’m facing is that I’m getting unexpected responses from the “checkfriends” call. In each request I’m passing the “lastupdate” string exactly as received from the previous request, but sometimes I get a response saying there are new entries when in fact there aren’t. Doing a network capture showed that sometimes the “lastupdate” value received in the response is a date which is earlier than the “lastupdate” which was sent in the request. Then after some further requests, I start getting back the original “lastupdate” value, along with a “new=1” response. I know you’re not supposed to imply any meaning in the “lastupdate” value, but it does seem to be the cause of my spurious results.
To try and understand the problem I created a friends group which contains only myself, so that I could be sure that no changes had been made to my journal. The group number is 3, so the mask to be sent in the request is (1 << 3) = 00001000 binary (8 decimal). That’s correct, right? I sent a bunch of requests with this friends group mask, waiting for the amount of time specified in the “interval” of the previous response before sending the next request, and I found that sometimes the “lastupdate” in the response is “0000-00-00 00:00:00”. The following is the network capture (challenge requests not included, and challenge / response xxx‑ed out):
Request / Response 1:
POST /interface/flat HTTP/1.1 User-Agent: Mozilla/5.0 (LiveJournal Client Test) Content-Type: application/x-www-form-urlencoded Host: www.livejournal.com Cookie: ljfastserver=1 Content-Length: 249 mode=checkfriends&lastupdate=2011-05-10+11%3a24%3a33&mask=8&ver=1&auth_method=challenge&auth_challenge=xxx&auth_response=xxx&user=term_hat HTTP/1.1 200 OK Server: GoatProxy 1.0 Date: Thu, 12 May 2011 14:54:28 GMT Content-Type: text/plain; charset=UTF-8 Connection: close X-AWS-Id: ws48 Content-Length: 61 X-Varnish: 116689367 Age: 0 X-VWS-Id: bil1-varn19 X-Gateway: bil1-swlb03 interval 120 lastupdate 2011-05-10 11:24:33 new 0 success OK
Request / Response 2:
POST /interface/flat HTTP/1.1 User-Agent: Mozilla/5.0 (LiveJournal Client Test) Content-Type: application/x-www-form-urlencoded Host: www.livejournal.com Cookie: ljfastserver=1 Content-Length: 249 mode=checkfriends&lastupdate=2011-05-10+11%3a24%3a33&mask=8&ver=1&auth_method=challenge&auth_challenge=xxx&auth_response=xxx&user=term_hat HTTP/1.1 200 OK Server: GoatProxy 1.0 Date: Thu, 12 May 2011 14:57:02 GMT Content-Type: text/plain; charset=UTF-8 Connection: close X-AWS-Id: ws37 Content-Length: 61 X-Varnish: 733810236 Age: 0 X-VWS-Id: bil1-varn10 X-Gateway: bil1-swlb03 interval 120 lastupdate 0000-00-00 00:00:00 new 0 success OK
Request / Response 3:
POST /interface/flat HTTP/1.1 User-Agent: Mozilla/5.0 (LiveJournal Client Test) Content-Type: application/x-www-form-urlencoded Host: www.livejournal.com Cookie: ljfastserver=1 Content-Length: 249 mode=checkfriends&lastupdate=0000-00-00+00%3a00%3a00&mask=8&ver=1&auth_method=challenge&auth_challenge=xxx&auth_response=xxx&user=term_hat HTTP/1.1 200 OK Server: GoatProxy 1.0 Date: Thu, 12 May 2011 14:59:14 GMT Content-Type: text/plain; charset=UTF-8 Connection: close X-AWS-Id: ws02 Content-Length: 61 X-Varnish: 1739287730 Age: 0 X-VWS-Id: bil1-varn14 X-Gateway: bil1-swlb03 interval 120 lastupdate 2011-05-10 11:24:33 new 1 success OK
As you can see, the “lastupdate” is initially being returned as “2011-05-10 11:24:33”, but in the next request it is returned as “0000-00-00 00:00:00”. In the request following that, the value is “2011-05-10 11:24:33”, which is the value which was initially being returned. No changes were made to my journal during the time of the above examples. Do you see anything wrong with my requests? Or could it be a bug in the LiveJournal API, or temporary technical fault? I’ve read in the community that checkfriends was disabled at one point due to a buggy client causing server‑side issues, but that it should now be working and usable for paid users. This behaviour appears to be random, but it is repeatable (based on a number of tests I have performed over the last week).