Wrong datauri path generation in css_datauri_cleanup() ?

[fritzgrabo]

Hi! I'm currently working on integrating css-js-booster into an existing website that uses .css files scattered throughout its directory tree. I'm assigning an array containing paths to the .css files relative to the booster_inc.php to $booster->css_source. Also, I'm developing my website at http://localhost/~username/foobar, so I am setting $booster->base_offset and $booster->document_root, too.

Everything seems to work out fine, except for a wrong path calculation in css_datauri_cleanup(). In booster_inc.php:1144, $booster_path is calculated using the document_root object-property, which has never been set for this instance of the Booster class that executes this function. css_datauri_cleanup() is executed only on the instance which was constructed in booster_css.php, and naturally, that instance knows nothing of the
document_root I used when parameterising $booster in my website's files.

However, I don't think it's actually necessary to recalculate $booster_path. In my opinion, it should be enough to use the $dir paramter that gets passed in with a usable relative path anyway? So, in line 1169, instead of

$replace = $treffer[1][$i].$booster_path.'/';

it should be enough to say

$replace = $treffer[1][$i];

At least, that seems to work for me. What are your thoughts on this? Am I missing something?

Regards,
please keep up the good work!,

Fritz.

ps: same file, unrelated issue, line 1170: I guess it should read if (...) ... = $css_stringbase instead of ... $css_stringmode.

[Schepp]

Hello Fritz,

thanks a lot for that well thought and detailed input on that point. You are totally right when noticing that document_root is never set at this point. You are also right with line 1170! :)

However I can not simply switch from an absolute to a relative path for resources during the cleanup-process as for the stylesheet I am hiding the real path from the browser, like so:

/booster/booster_css.php/dir=%3E/styles/style.css

The reason for this is that by hiding those query parameters the files finally get cached by proxies like Squid. On the other hand this makes the browser think the CSS sits in a directory named

/booster/booster_css.php/dir=%3E/styles/

and it gets all paths wrong. As you don't have that sort of effect when removing $booster_path.'/' from the $replace variable, I suppose that you have mod_rewrite set to FALSE (either because you did it, or because Booster detected a misbehavior).
Now I still need to fix the afore mentioned problem and I think I might solve it by passing another parameter to booster_css.php and friends. If it is something one can consider secure.

Regards

Christian