Nginx - превратите $ arg_ в путь с 3 подкаталогами для try_files

В настоящее время я работаю над сервером кэширования изображений с использованием Nginx, однако у меня возникают проблемы с тем, чтобы Nginx обслуживал кэшированные изображения.

Предполагается, что сервер кэширования может обслуживать два типа изображений, первый из которых представляет собой довольно маленькие изображения, которые не требуют большого вмешательства со стороны сервера изображений.

Это работает так, как я хочу, используя следующую конфигурацию:

location = /small/ {
  try_files /small/logos/$arg_id.jpg @gen_script;
}
location @gen_script {
  rewrite ^(.*)$ /small/index.php?id=$arg_id;
}

Здесь нет проблем, используя эту конфигурацию, он пытается найти изображение в каталоге /small/logos с именем, которое соответствует предоставленному ID-parameter, если оно не существует, оно ссылается на @gen_script, это приводит к index.php, который будет генерировать изображение. Это работает без проблем.

Теперь что касается части, которая вызывает у меня проблемы, второй тип изображения, который должен обслуживать сервер, обычно больше и создается на основе нескольких параметров (height, width, that sort of thing).

Эти изображения идентифицируются по сгенерированному хешу, который всегда 128 characters long.

Я пытаюсь добиться того, чтобы первые три символа хеша были превращены в каталоги пути, по которому можно найти изображение, за которыми следуют полный хеш и ".jpg". Вот конфигурация для этого аспекта, не работает, и я не знаю, почему:

location ~* "^\/image\.php\?hash=(?<a>.{1})(?<b>.{1})(?<c>.{1})(?<d>.{125})(?:.+)$" {
  try_files /images/$a/$b/$c/$a$b$c$d.jpg @image_gen;
}
location @image_gen {
  rewrite ^(.*)$ /image.php$is_args$args;
}

В отличие от ожидаемого поведения, каждый запрос к image.php фактически принимается (или отправляется) image.php, снова создавая запрошенное изображение, полностью в отличие от того, что должен делать (или любой ...) кэширующий сервер .

В целях пояснения, если хэш будет abcde12345 (сокращен для удобства чтения), то изображение будет расположено в /images/a/b/c/abcde12345.jpg. Как я могу гарантировать, что try_files проверяет, существует ли файл в ожидаемой структуре подкаталогов, и если он не пересылает исходный запрос /image.php со своими аргументами, гарантируя, что изображение будет сгенерировано?


nginx nginx-location
person Rodent85    schedule 19.10.2017    source источник
comment
Вы не можете проверить аргументы в выражении location. Директивы location и rewrite используют нормализованный URI, который не включает ? и все, что следует за ним.   -  person Richard Smith    schedule 19.10.2017
comment
@RichardSmith В этом есть смысл, параметр - это не местоположение. Если я изменю location ~* ... на location = /image.php, могу ли я повторно выразить $arg_hash в операторе if в блоке местоположения? Или должно быть иначе?   -  person Rodent85    schedule 19.10.2017
comment
Вы можете использовать if, но тогда вы не сможете использовать try_files. Вы придерживаетесь /image.php?hash= стиля запроса?   -  person Richard Smith    schedule 19.10.2017
comment
Да, боюсь, что это в основном предназначено для замены существующего сервера кэширования изображений, что нового в этой «версии» - это размещение изображений в подкаталогах.   -  person Rodent85    schedule 19.10.2017

Ответы (1)


arrow_upward
1
arrow_downward

Вы можете использовать что-то вроде ниже

http {

    map $arg_hash $arg_hash_folder {

        default '';
        ~*(.)(.)(.)(.*)$ /$1/$2/$3/$1$2$3$4.jpg;
    }

    server {

        location = /image.php {

            try_files $arg_hash_folder @process_image;
        }

        location @process_image {

            # Try rewrite here and see if it works
            # If it doesn't work then you should have the php processing code here
            # fastcgi_pass ....;
        }
    }
}

Карта предоставит вам путь к папке, если он не найден, будет вызываться process_image, здесь вы можете попробовать переписать, я сомневаюсь, что это сработает, поэтому вам нужно будет снова включить здесь код обработки PHP

person Tarun Lalwani    schedule 19.10.2017