Protocol Versions

The LiveJournal protocol has been more or less static; while new modes have been added, the basic operation has not changed much. Introduction of Unicode support in LiveJournal necessitated changes in the way text is encoded in protocol requests and responses. To allow new clients to take advantage of Unicode support and at the same time avoid breaking existing clients, a versioning scheme was put into the protocol. The client sends the number of the highest protocol version it supports in every request, inside a  attribute; version   is implicit if the client does not send the   attribute.

There are currently two versions of the protocol.

Version 0
In protocol version, textual information transmitted from or to the server is always assumed to be a stream of 8-bit bytes -- not necessarily ASCII, but without any guarantee that the non-ASCII bytes are presented in any particular encoding. You can only upload such unknown 8-bit entries to personal journals. You cannot post an entry to a non-person account (a community) with international or special characters at all, unless you set version.

If a client does not send a  key on a request, it's assumed to support protocol version.

Version 1
Version  differs from version   only by imposing additional requirements on the text transmitted through requests and responses; there aren't any changes in protocol modes. The additional requirements are:


 * In a version  request, the client must transmit all textual information as a stream of Unicode data encoded in UTF-8.
 * The server must respond to version  requests with Version   responses.
 * In such version  responses, the server must also transmit all textual information encoded in UTF-8.
 * The client must expect that and handle such responses correctly.

In other words, all information transmitted via protocol when version  is used is always encoded in UTF-8. UTF-8 is a representation of Unicode in a bytestream format compatible with ASCII.