Уважаемые товарищи инженеры,

Я написал на данную тему в англо-язычную ветку "Ideas and Feature requests" 4 дня назад, но покамест не получил там ответа. Не судите строго за то, что не поленился написать сюда на русском.

Существует простой и неплохой модуль, написанный неким Joshua Zhu как часть его проекта под названием "tengine". Модуль называется "http-concat" и полностью совместим с nginx 1.1.14 (проверено). Он позволяет соединять несколько файлов в один и выдавать соединенный файл клиенту, что позволяет сократить время запроса, так как нет традиционного обращения к каждому файлу по отдельности. Мы используем этот модуль для соединения в "бандлы" Javascript и CSS файлов. Исходники http-concat доступны для скачивания здесь: https://github.com/perusio/nginx-http-concat

Если коротко, то этот модуль парсит запрос типа: "/jquery/??jquery.asmselect.css,ui.imageuploader.css,jquery.linkselect.css", после чего соединяет все файлы после "??" в один "бандл" и отправляет клиенту. Он также использует внутренний кэш и прочее, что делает его быстрым и удобным для использования.

Но я бы сюда не обращался если бы не было некоторых моментов :

В данный момент http-concat не может брать файлы из локейшнов, где используются директивы "alias" или "root". Пример:

location /jquery/ {
try_files $uri $uri/ @common;
}

location @common {
# handle common requests for all sites: /jquery/...., etc. if local version of the requested file is not available
root /opt/www/_common;
}

...

Если попытаемся "склеить" файлы из location /jquery, запрос кончится 404 ошибкой. Это происходит потому, что http-concat не может получить путь к файлам, находящимся в локейшне, где действуют директивы root/alias. Я был бы очень признателен, если бы кто-то мог бы взглянуть на исходный код модуля http-concat (URL: https://github.com/perusio/nginx-http-concat/blob/master/ngx_http_concat_module.c) и дать мне какие-нибудь наводящие указания в какую сторону копать или патч, чтобы правильно определить пути таким локейншнам. Я связался с автором, но он сообщил, что не знает как выяснить путь к файлам в локейшнах где определены директивы alias или root.

Вторая проблема связана с тем, что некоторые CSS файлы могут содержать в себе аттрибуты "url", чтобы ссылаться на внешние файлы, например изображения. К сожалению, если пути к этим внешним файлам относительные, то сервер считает, что они относительны текущей страницы, то есть страницы, откуда вызывается конкатенация CSS файлов при помощи http-concat. Например: файл "/jquery/jquery-ui-1.8.17.custom.css" из стандартной библиотеки "jquery" содержит 8 линков на внешние файлы в каталоге images/...., пути к которым должны определятся как /jquery/images/...., если вызывать этот CSS файл напрямую. Но если мы хотим задействовать http-concat в другом каталоге сайта, но при этом использовать данный CSS файл из библиотеки jquery, то линки на изображения больше не работают, так как они становятся относительными того файла, откуда вызывается /jquery/jquery-ui-1.8.17.custom.css.

Перед тем как мы нашли модуль http-concat, мы использовали PHP чтобы связывать CSS и Javascript файлы в один файл, и наш скрипт умел находить линки на изображения с атрибутом "url" и в общем файле, который выдавал клиенту, подставлял вместо относительных абсолютные и правильные пути в таких линках, так как известен путь к самому файлу, в котором эти линки присутствуют. Это делалось при помощи preg_replace():

$uri_path = dirname($css_file['uri']);
// example: url(relative/path/to/file) becomes: url(/absolute/and/not/relative/path/to/file) within a CSS file
$buf = preg_replace('/(:?\s*url\s*\()[\'"\s]*([^\/\'"].*)[\'"\s]*\)/isU', '$1' . ($uri_path == '/' ? '/' : $uri_path . '/') . '$2)', $buf);

Возможно ли как-то использовать PCRE библиотеку чтобы сделать подобную автоматическую замену линков в аттрибутах "url" в CSS файлах на абсолютные пути на языке C? Ведь nginx и так уже использует PCRE в полный рост, так может быть это не такая уж трудоёмкая задача?

К сожалению, у меня очень мало опыта программирования на языке C, поэтому и вынужден обратиться к экспертам. Любые патчи или предложения по устранению изложенных проблем приветствуются. Я также уверен, что этот модуль может быть многим полезен в силу возможности уменьшить количество запросов к javascript/css файлам.

Буду очень признателен за любую помощь.

Спасибо,
Андрей