One way to mitigate BEAST is to do nothing. It so happens that though the vulnerability used in BEAST is still there, exploiting it is rather difficult. It requires the ability to do cross-domain requests, with a high level of control on the data which is sent in the request; in particular, it needs "binary" data. Duong and Rizzo did not find a way to map the attack on plain
Since relying on the non-existence of cross-domain vulnerabilities is, at best, flimsy, browser vendors have also included some extra countermeasures, with record splitting. When the browser wants to send a block of n bytes of data, instead of putting it in one SSL record, it splits it into two records, the first being very small. Record boundaries have no semantic significance in SSL/TLS, so you can do such splitting without changing the meaning. However, each record ends with a MAC computed over the record data and a sequence number, and using one key derived from the initial key exchange. This somehow acts as a pseudo-random number generator. Therefore, the small record "emulates" the random IV generation that makes TLS 1.1+ immune from BEAST.
Ideally, the split would be 0/n: a record with no data (but still with a MAC), followed by a record with the actual data. Zero-length records are allowed (as per the standard) but buggy client and server implementations do not tolerate them (in particular IE 6.0); instead, browsers use a 1/n-1 split, which is just as good for defeating BEAST, but also works with almost all existing SSL/TLS clients and servers. At least Chrome and Firefox have pushed it last year.
The good solution is TLS 1.1+ but even on SSL 3.0 and TLS 1.0, the BEAST issue can be considered as fixed, at least in the Web context. Therefore, use AES, and be happy.