Re: location uri с аргументами включительно

[Sergey Croitor]

Здравствуйте Вадим,

да, должен.
В основном все кэшируется, кроме исключений.
Вот урезанная location секция из текущего nginx конфига:

location / {
proxy_pass      http://backend;
proxy_cache cache;
proxy_cache_valid 200 302 304 180m;
proxy_cache_valid any 1s;
proxy_cache_key
"$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri";
proxy_hide_header "Set-Cookie";
proxy_ignore_headers "Cache-Control" "Expires";
add_header Cache-Control private;
expires 180m;
include         /etc/nginx/proxy.conf;
if ($request_uri = /index.php?main_page=accountbox) {
return 412;
}
# еще штук 20 подобных ($request_uri = /index.php?...) отсылок на на бэкенд

if ($arg_main_page = nocachedajax) {
return 412;
}
# еще штук 10 подобных ($arg_xxx = /yyy) отсылок на на бэкенд

if ($request_method = POST ) {
return 412;
}
error_page 412 = @fallback;
error_page 413 = @longcache;
}

location @fallback {
proxy_cache off;
proxy_pass      http://backend;
include         /etc/nginx/proxy.conf;
expires off;
}

то есть кэшируется все, за рядом исключений.
Строка для создания ключа включает в себя не нормализованный $request_uri
Еще раз повторю, что надо:
есть ряд запросов, которые НЕ надо кэшировать для обычных пользователей и
наоборот надо для роботов.
Например:
1) имя пользователя/статус shopping cart вверху страницы не надо кэшировать
для пользователей и надо для роботов (пусть хоть пустой ответ им идет - им
по барабану)
2) запрос "/index.php?main_page=nocachedajax&q=savelocation" пишет в сессию
урл последней странички и отдает пустую строку.
для пользователя его НЕ надо кэшировать, а для роботов нужно(поскольку не
нужно для них хранить последний урл в сессии).



2013/1/14 Вадим Лазовский <vadim.lazovskiy at gmail.com>

> Здравствуйте.
>
> Должен ли кэшироваться ответ от index.php c другими аргументами? Если да,
> то по какому ключу?
>
>
> 14 января 2013 г., 16:58 пользователь Sergey Croitor <scroitor at gmail.com>написал:
>
>> Прежде чем надеяться, я плотно мониторил логи в течение месяца где-то.
>> В данном конкретном случае роботы не балуют и используют именно этот
>> паттерн ничего не переставляя.
>> То есть, буде такая возможность для location, то оно решило бы проблему.
>> И по моему опыту, роботы если и переставляют/добавляют к урлу параметры,
>> то только от кривого кода в html или комбинируя всякие чекбоксы и селект
>> боксы.
>> Ну а если какой лихой робот и переставил бы, то и фиг с ним(в моем
>> случае).
>> 99% этих бесполезных запросов nginx бы отдал из кэша и одному из PHP и
>> этим бы решил проблему.
>> Но видимо не судьба.
>> Насколько я понял, это решаемо только путем предварительного вычисления
>> условий с помощью perl_set внутри общего location.
>> Пока отщелкиваю подобные запросы от ботов на бэкенде, как это не
>> прискорбно.
>>
>> 2013/1/14 Andrey Repin <hell-for-yahoo at umail.ru>
>>
>>> SC> Пытаюсь организовать кэширование страниц с uri начинающегося со
>>> следующих
>>> SC> символов:
>>> SC> /index.php?main_page=nocachedajax&q=savelocation
>>>
>>> Боюсь вас разочаровать, но для URL'ов в таком виде многие роботы
>>> частенько
>>> переставляют параметры запроса, как им угодно, так что на выполнение
>>> условия
>>> "начинается с" я бы на вашем месте надеяться не стал.
>>>
>>> SC> Надо сделать это только для роботов
>>>
>>> SC> Поначалу была мысль сделать так:
>>>
>>> SC> location /index.php?main_page=nocachedajax&q=savelocation {
>>>
>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> Best Regards,
> Vadim Lazovskiy
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130114/fb782769/attachment-0001.html>