[Chip Bradford]

I'm working on getting a new site setup here and ran into some trouble trying to get the response headers correct.

The site uses a separate sub-domain for cookie-less content with the following .htaccess:

RewriteRule ^(.*)-[0-9a-f]{32}\.([^\.]+)$ $1.$2 [E=FINGERPRINT]
RewriteRule ^(css|js)/(.*)$ ../php/page.php/$2?pageType=$1 [QSA]

# Set a future expires head
ExpiresActive On
ExpiresDefault "access plus 1 year"

# Unset them if this URL doesn't have a fingerprint
Header unset Expires env=!REDIRECT_FINGERPRINT
Header unset Cache-Control env=!REDIRECT_FINGERPRINT

# Make sure Cache-Control is public
Header append Cache-Control "public" env=REDIRECT_FINGERPRINT

The main site generates URLs to this domain that include a fingerprint of the file (md5). The fingerprints are designed so that a far-future expires/cache-control header can be set but if the file changes (and thus the fingerprint) clients will download new versions.

The goal of the .htaccess file is to set a 1-year expires/cache-control header if the request URI has an embedded fingerprint, or to have no expires/cache-control on the off-chance the fingerprint wasn't included (this really shouldn't happen, but if it does it should fall back on last-mod/etags checks). In addition, css/js files get some extra processing (and are cached with Cache_Lite).

"[E=FINGERPRINT]" works with apache but seems to make the whole rule fail under LiteSpeed, but changing it to "[E=FINGERPRINT:1]" seems to fix that problem.

The environement variable is passed to the php handler as FINGERPRINT instead of REDIRECT_FINGERPRINT, which isn't a big deal.

The kicker is that those conditional headers don't seem to work at all (no matter what "env=...." is set to, the header directive is always processed). On top of that, LiteSpeed seems to be completely ignoring the mod_expires part of the file and is setting its own 7-day expires/cache-control headers even if I manually set those headers in the .htaccess file (and since they are added last they will override anything I set).

I can get the right headers coming out of my php script, so my backup plan at this point is to pipe *all* static content through the php handler, but it seems like there must be a better way to get this working. Any suggestions would be greatly appreciated.

On an unrelated note, is there any way to access git from an ssh login? It would be far more convenient to be able to checkout an updated version of the site directly to the server before deploying a new version than to have to checkout on my local machine, zip everything up, upload, and then unzip.

[Scott S]

I would suggest opening a support ticket so we can investigate this for you. It may be a bug in LiteSpeed that we would need to pass on to them, but I couldn't say for sure until we inspect your error logs and such.

Regarding Git: We don't offer the git binaries on our fleet at this point in time.

[Chip Bradford]

Scott S, on 14 October 2011 - 10:00 PM, said:

I would suggest opening a support ticket so we can investigate this for you. It may be a bug in LiteSpeed that we would need to pass on to them, but I couldn't say for sure until we inspect your error logs and such.

I didn't see any errors when I took a quick look, but I'll open a ticket so you guys can take a closer look.

Quote

Regarding Git: We don't offer the git binaries on our fleet at this point in time.

Fair enough. If I wanted to play around myself with getting a statically-linked version of git running on my account would there by anything wrong with that? (Obviously I wouldn't expect support for something that's not supported, but I also wouldn't want to inadvertently violate any policies you guys might have about those sorts of things.)

[MikeDVB]

As long as it's not a daemon (i.e. running constantly, serving requests) I see no issues with a pre-compiled version of Git. I can say, however, if you have any issues getting it to work that you would be 100% on your own as it's well outside the scope of our support.