mod_xsendfile won't work with CGI and mod_rewr

I am trying to use the apache module xsendfile to get a better performance during file streaming. The problem is, that it is just working if I DO NOT use PHP as CGI Version AND if I DO NOT USE rewrite rules for my urls.

Problem 1: mod_rewrite

Calling this one in the Browser will work:

http://subdomain.domain.de/image.php

This one will give me a 404:

http://subdomain.domain.de/rewrittenImageUrl

The rewrite rules are working right. The 404 error is triggered by the xsendfile module. If I add a "R" to the rule in the htaccess (like suggested in this question) it will work again, because I am redirected to the first address given above. But redirecting is not what I want.

I also watched out this post about symlinks, but I think this could not be a solution for my post as long as I use absolute paths generated by using getenv('document_root')? This pathes shouldn't use any symbolic links, do they? Or am I missing something at this point?

Problem 2: CGI

If I switch the PHP mode to the cgi version I will get a 0 byte file. This seems to be the same behaviour like the server would react without any installation of xsendfile.

I have already updated the module to the latest version. Also tested absolute and relative links without any success. In addition to that Deactivating the output compression didn't work.

To complete the given information here is the PHP code I am using:

ini_set('zlib.output_compression', 'Off');
$realImagePath = getenv('document_root')."fixedRelativeImagePathNoParamsNeeded.jpg";

$imageInfos = @getimagesize($realImagePath);
header('Content-Type: '.$imageInfos['mime']);   
header("X-Sendfile: $realImagePath");
exit();

Anyone has a clue?

Update (2014-01-06)

The second problem is solved: I don't know why but it's working after turning on xsendfile in the apache config instead of using the htaccess file. (I will add an answer below as soons as the other problem is solved, too.)

In addition to the first one: First I did not add any options in the httpd.conf as it should be working with the standard configuration. Anyway I now asked my provider to add the absolute project path to the whitelist of XSendFilePath as a global setting. This temporarily solved the 1. Problem with mod_rewrite. But this just seems to be not a real solution for my situation, because I am running many different projects on the server, each with a separated download path. So I would need to ask my provider to add a new path to the config each time I am starting a new project. I still just can't use x-sendfile with mod_rewrotite although I should have access to the document root without any extra settings.

回答1:

mod_xsendfile does construct absolute paths from relative paths based on the request URI, which might in fact be a sub-request in some cases. This does not always produce the results you expect.

Therefore, I would always use absolute URIs in the X-SENDFILE header.

The second consequence of the above is that the constructed path, not necessarily being what you expect, auto-whitelist a directory you do not expect, while then of course not whitelisting the directory you would have expected.

Therefore, always white-list URIs.

In short, Apache might not consider the same directory to be the current working directory of a request as you (or a backend *CGI). Rewriting only adds to the confusion.

I actually considered dropping the relative paths/auto-whitelist stuff altogether for this reasons, because it can be admittedly very confusing, and is also under-documented. I guess it is a little late to drop it entirely, but I should at least mark it deprecated.

回答2:

In your HT access file of main website try to use [L,R=301] in place of just [QSA,L] or [L].

For instance in place to use:

RewriteRule ^download/(.*)/$ download.php?x=$1 [QSA,L]

Use:

RewriteRule ^download/(.*)/$ download.php?x=$1 [L,R=301]

Tell me if resolved your problem guys !