Content-Type "text/xml; charset=utf-8"
This is redundant. For XML, the <?xml?> declaration takes precedence over the Content-Type header. If the XML Declaration is omitted you've got UTF-8 anyway.
I would normally leave the charset out for XML. Given that XML has its own perfectly good inline character encoding mechanism, the Content-Type header is unneeded and can only get in the way by accidentally choosing the wrong type for files without an encoding specified that are treated as UTF-8 everywhere else.
The one time you do need a charset parameter for XML is when you're serving a non-ASCII-compatible character set, usually UTF-16, where otherwise the parser wouldn't get as far as reading <?xml. But it's pretty rare you'd ever want to do that. UTF-16 isn't a great file storage/over-the-wire format.
Content-Type "application/xml"
The application/xml media type is specified by RFC3023, and a charset parameter has been explicitly defined for it. So you can use charset if you want (though as per the above, I generally don't want).
Content-Type "application/x-javascript"
Is an unofficial type so there is no specification to say whether a charset parameter exists or what it might do. This type should probably be avoided in favour of text/javascript (traditional) or application/javascript (defined by RFC4329).
In practice, setting a charset on your JavaScript resources isn't necessarily enough, as IE completely ignores it.
Summary of the precedence (highest to lowest) given to scripting character set mechanisms:
IE: <script charset> attribute, charset of parent page
Opera: charset of script file, charset of parent page
Mozilla, Webkit: charset of script file, <script charset> attribute, charset of parent page
Probably the ProxyPass / directive you have in your config routes all requests to the Tomcat backend, bypassing all your mod_rewrite directives. You can try to remove the ProxyPass directive and use RewriteRule with the [P] flag after your other rewrites:
For the expire headers the situation is worse — in another similar question a solution was not found.
Option +FollowSymLinks would be needed for using mod_rewrite in .htaccess files; in your case it is not required, because you can put everything in the Apache config. Moving rules from config to .htaccess is pointless and can only make things slower. However, there is an important difference between .htaccess and the Apache config — in .htaccess patterns in RewriteRule are matched against relative filesystem paths (which never start with /), while in the VirtualHost context these patterns are matched against the URL path after the hostname, which always starts with /. Therefore at least one of your rules is incorrect:
RewriteRule ^content/(js|css)/([a-z]+)-([0-9]+)\.(js|css)$ /content/$1/$2.$4
should be
RewriteRule ^/content/(js|css)/([a-z]+)-([0-9]+)\.(js|css)$ /content/$1/$2.$4
(note the additional slash in the beginning).
Best Answer
You need to be careful with mime types as they're sent to the browser to help them interpret what way to render certain files.
Changing these two particular MIME types shouldn't hurt, but I'd be very wary of doing this in general. The mime type is sent with the headers for that particular file and changing those may result in unexpected behaviour with certain clients.
i.e. you can't really tell what will happen by changing mime types as such, as that's client specific. You'd need someone with experience of all the various web browsers to tell you in this case, or you'd need to go test it yourself. In general, that's what you'd need to be careful of.