I've mentioned this in passing before, and also typed most of it out a few moments ago and then accidentally closed the client. (doh) I mention it in this more prominant location because it isn't obvious but it's quite important.
The problem stems from the protocol docs, which most (all?) of the client authors just ripped the example HTTP request out of. The Content-type header has a value of multipart/form-data which is the type used in a form with a file upload field which does a multipart encoding. The LJ protocol actually uses application/x-www-form-urlencoded, but the form handler used throughout LJ doesn't actually check the content-type so this has yet to actually cause a problem.
However, in the interests of being 'correct' I think it's important that firstly the documentation be adjusted, and then the clients which have this error be altered slightly to correct this error. Especially with other using LJ now for their own uses, clients sending incorrect HTTP requests is likely to be a source of confusion when things don't work as expected. (It took me quite a while to track down the problem when I was trying to use an LJ client with my php LJ protocol emulator!)
When I last checked, the clients which had this problem included the various forms of the win32 client, loserjabber (although I didn't check the CVS version, and I checked quite a while ago) and mIRC-LJ (fixed).
Apart from anything else, if the clients send correct Content-type headers it may be possible to support other encodings in future where the handler can check based on this header. This might have applications elsewhere if not on LJ itself.