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).
I don't really see it as a problem, as cookies aren't that big and the server doesn't have to send them back in the response. So while yes, one or more cookies set by example.com will "balloon" the request to static.example.com, static.example.com doesn't have to send it back in the response, so the server's response is completely unaffected.
Further, if you have content that you know to be static (images, CSS, JS, etc.), you should be setting proper cache control headers, especially an Expires header for some appropriate time in the future (e.g. +1 day, +1 week, +50 years, whatever makes sense for how often your static content changes). With this done, those cookies will only be sent one time, and then future need for those files will be handled by the browser's cache.
If you do still feel like this is too much (I can't really see how it could be, honestly), you can possibly mitigate it by using paths. For example, if your web app only needs cookies at example.com/app, set the cookie-path to be /app, and then requests to static.example.com/images/some-awesome-image.jpg won't send that cookie because the path doesn't match.
You can further mitigate it by reducing the number of cookies you use -- for most purposes, one (and only one) cookie storing a single session ID only adds a few bytes (less than 1KB in every implementation I've seen/used), and gives the server ample information to look up everything it needs to know about that client server-side.
Honestly, if you're worried about short-URL domains making your site non-future-proof because of cookies, then I think you have an architectural problem with too many/too big cookies, and you should re-evaluate your strategy from that point of view.
Best Answer
You have to "disable" the proxy on static files (i.e. enable it only on other files):
Also try
debug.log-request-handling = "enable"
and check error.log, also see http://redmine.lighttpd.net/projects/lighttpd/wiki/DebugVariables