Protocol Versions

Needs Update: This documentation was ported over from LJ's Server Manual with minimal modification. It may not match Dreamwidth's implementation of the method, and needs to be double checked against the DW code and updated as necessary.

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 ver attribute; version 0 is implicit if the client does not send the ver attribute.

There are currently two versions of the protocol.

Version 0

In protocol version 0, 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 1.

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

Version 1

Version 1 differs from version 0 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 1 request, the client must transmit all textual information as a stream of Unicode data encoded in UTF-8.
• The server must respond to version 1 requests with Version 1 responses.
• In such version 1 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 1 is used is always encoded in UTF-8. UTF-8 is a representation of Unicode in a bytestream format compatible with ASCII.