Re: 301 редирект работает не всегда?

2017-04-20 Пенетрантность Андрей Василишин 

> а вы по логам видите только обращения к счетчикам, или 200 к старому
> домену ?
>  

По логам вижу только 301 редирект и редкие 400 и 408 ошибки

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 301 редирект работает не всегда?

2017-04-20 Пенетрантность Илья Шипицин 
21 апреля 2017 г., 2:08 пользователь Андрей Василишин 
написал:

>
> >  Если страница кэшируемая (например, без явного expires), то она может
> >  быть оставлена в одном из табов, тогда счётчик сработает при очередном
> >  запуске браузера без обращения к серверу.
> >
>
>
> просто странно, редирект со старого домена на новый был сделал уже пол
> года назад, а на старом домене все равно умудряются загружать счетчики
>


а вы по логам видите только обращения к счетчикам, или 200 к старому домену
?


> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 301 редирект работает не всегда?

2017-04-20 Пенетрантность Андрей Василишин 

>  Если страница кэшируемая (например, без явного expires), то она может
>  быть оставлена в одном из табов, тогда счётчик сработает при очередном
>  запуске браузера без обращения к серверу.
> 


просто странно, редирект со старого домена на новый был сделал уже пол
года назад, а на старом домене все равно умудряются загружать счетчики
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 301 редирект работает не всегда?

2017-04-20 Пенетрантность Андрей Василишин 
20.04.2017 23:46, Gena Makhomed пишет:
> On 20.04.2017 23:26, Андрей Василишин wrote:
> 
>>  rewrite ^(.*)$ http://site.to$request_uri permanent;
> 
> Выделение ^(.*)$ лишнее, оно потом нигде не используется.
> 
> Еще при такой директиве при редиректе будут дублироваться аргументы.
> 
> Надо или добавлять ? после $request_uri или использовать return 301:
> 
> rewrite ^ http://site.to$request_uri? permanent;
> 
> return 301 http://site.to$request_uri;
> 
> Последний вариант короче и предпочтительнее всего.
> 


Спасибо за ликбез!
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 301 редирект работает не всегда?

2017-04-20 Пенетрантность Evgeniy Berdnikov 
On Thu, Apr 20, 2017 at 11:26:20PM +0300, Андрей Василишин wrote:
> Есть такая проблема, настроен 301 редирект с кучи доменов на основной,
> конфиг ниже. Все работает, в логах помино 301 редкие 400 и 408 ответы,
> но вот счетчик liveinternet, яндекс.вэбмастер все же показывает пару
> десятков хостов, которые по идее должны были быть отредирекчены на
> другой домен и их счетчики банально не должны были загрузится.
> Кто виноват и что делать, есть у кого-нибудь идеи?

 Если страница кэшируемая (например, без явного expires), то она может
 быть оставлена в одном из табов, тогда счётчик сработает при очередном
 запуске браузера без обращения к серверу.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 301 редирект работает не всегда?

2017-04-20 Пенетрантность Gena Makhomed 

On 20.04.2017 23:26, Андрей Василишин wrote:


 rewrite ^(.*)$ http://site.to$request_uri permanent;


Выделение ^(.*)$ лишнее, оно потом нигде не используется.

Еще при такой директиве при редиректе будут дублироваться аргументы.

Надо или добавлять ? после $request_uri или использовать return 301:

rewrite ^ http://site.to$request_uri? permanent;

return 301 http://site.to$request_uri;

Последний вариант короче и предпочтительнее всего.

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кто же сильнее Cache-Control или X-Accel-Expires?

2017-04-20 Пенетрантность Maxim Dounin 
Hello!

On Thu, Apr 20, 2017 at 09:12:14PM +0300, Иван wrote:

> Максим,спасибо за быстрый ответ! Может быть это указать в документации? Пока 
> что процитированная часть документации, как мне кажется, прямо противоречит 
> этому поведению.

Скорее нет, чем да.  Это поведение надо бы исправить так, чтобы в 
том числе в случае полного запрета кеширования приоритет 
заголовков работал корректно, и результат не зависел от порядка 
заголовков.

(Just in case it is not clear, сейчас документация правильно 
описывает поведение в случае, если ни один из заголовков 
кеширование не запрещает совсем.  Зависимость от порядка возникает 
тогда и только тогда, когда один из заголовоков кеширование 
полностью запрещает.)

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кто же сильнее Cache-Control или X-Accel-Expires?

2017-04-20 Пенетрантность Иван 
Здравствуйте!

Максим,спасибо за быстрый ответ! Может быть это указать в документации? Пока 
что процитированная часть документации, как мне кажется, прямо противоречит 
этому поведению.

С уважением, Иван.

В письме от 20 апреля 2017 21:08:33 пользователь Maxim Dounin написал:
> Hello!
> 
> On Thu, Apr 20, 2017 at 08:17:07PM +0300, Иван wrote:
> > Здравствуйте!
> > 
> > Есть конфиг бэкэнда, вот его кусочек:
> > 
> > location ~ \.m3u8$ {
> > expires -1;
> > add_header "X-Accel-Expires" "100"
> > }
> > 
> > Как следует из русской и английской документации:
> > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid
> > (кстати, как делать красивые короткие ссылки на документацию, которыми
> > оперирует в этом списке рассылки команда nginx?)
> > 
> > > Если в заголовке нет поля “X-Accel-Expires”, параметры кэширования
> > > определяются по полям заголовка “Expires” или “Cache-Control”.
> > 
> > То есть можно предположить, что приоритет у X-Accel-Expires.
> > Но нет. Как показывает моя практика и, например, этот вопрос:
> > https://serverfault.com/questions/641367/nginx-using-x-accel-expires-with-> 
> > > cache-control
> > 
> > Приоритет имеет Cache-control. То есть в такой конфигурации на фронтэнде:
> > 
> > location ^~ /video/ {
> > 
> > proxy_buffer_size 16k;
> > proxy_buffers 32 16k;
> > 
> > proxy_cache video;
> > proxy_cache_lock on;
> > 
> > proxy_cache_use_stale updating;
> > proxy_cache_key "$proxy_host$uri";
> > 
> > proxy_pass http://backend;
> > 
> > }
> > 
> > m3u8 файлы, проходящие через этот локейшен на приведенный выше локейшен
> > бэкэнда кешироваться не будут. Ситуацию спасает только
> > proxy_ignore_headers Expires Cache-Control;
> > 
> > Подскажите, пожалуйста, где ошибка: в nginx, документации или моём
> > понимании того или другого?
> 
> Текущая реализация такова, что если до заголовка X-Accel-Expires
> встретится заголовок Cache-Control или Expires, запрещающий
> кеширование совсем, то кеширование будет запрещено.
> 
> То же самое с Cache-Control vs. Expires: в соответствии со
> стандартом HTTP/1.1 заголовок Cache-Control имеет приоритет, но
> если до него в ответе был заголовок Expires, полностью запрещающий
> кеширование, то кеширование будет запрещено.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кто же сильнее Cache-Control или X-Accel-Expires?

2017-04-20 Пенетрантность Maxim Dounin 
Hello!

On Thu, Apr 20, 2017 at 08:17:07PM +0300, Иван wrote:

> Здравствуйте! 
> 
> Есть конфиг бэкэнда, вот его кусочек:
> 
> location ~ \.m3u8$ {
> expires -1;
> add_header "X-Accel-Expires" "100"
> }
> 
> Как следует из русской и английской документации:
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid 
> (кстати, как делать красивые короткие ссылки на документацию, которыми 
> оперирует в этом списке рассылки команда nginx?)
> 
> > Если в заголовке нет поля “X-Accel-Expires”, параметры кэширования
> > определяются по полям заголовка “Expires” или “Cache-Control”.
> 
> То есть можно предположить, что приоритет у X-Accel-Expires.
> Но нет. Как показывает моя практика и, например, этот вопрос: 
> https://serverfault.com/questions/641367/nginx-using-x-accel-expires-with-cache-control
> 
> Приоритет имеет Cache-control. То есть в такой конфигурации на фронтэнде:
> 
> location ^~ /video/ {
> proxy_buffer_size 16k;
> proxy_buffers 32 16k;
> 
> proxy_cache video;
> proxy_cache_lock on;
> 
> proxy_cache_use_stale updating;
> proxy_cache_key "$proxy_host$uri";
> 
> proxy_pass http://backend;
> }
> 
> m3u8 файлы, проходящие через этот локейшен на приведенный выше локейшен 
> бэкэнда кешироваться не будут. Ситуацию спасает только
> proxy_ignore_headers Expires Cache-Control;
> 
> Подскажите, пожалуйста, где ошибка: в nginx, документации или моём понимании 
> того или другого?

Текущая реализация такова, что если до заголовка X-Accel-Expires 
встретится заголовок Cache-Control или Expires, запрещающий 
кеширование совсем, то кеширование будет запрещено.

То же самое с Cache-Control vs. Expires: в соответствии со 
стандартом HTTP/1.1 заголовок Cache-Control имеет приоритет, но 
если до него в ответе был заголовок Expires, полностью запрещающий 
кеширование, то кеширование будет запрещено.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Как правильно кешировать запросы от анонимов?

2017-04-20 Пенетрантность Иван 
Здравствуйте!

Достаточно популярная, как мне кажется, проблема. Хочу кешировать запросы к 
какому-то локейшену, например, к / , но только от анонимных пользователей. То 
есть тех, у которых еще нет для нас никаких кук.

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

То есть по факту мой вопрос сводится к тому, как выполнять 
fastcgi_ignore_headers Set-Cookie;
или не выполнять в зависимости от каких-то условий, например, от наличия уже 
поставленных пользователю кук.

Пока я создал вот такого монстра (он работает, но мне не нравится):

map $http_cookie $main_cache {
default 0;
"" 1;
}

location = / {
if ($main_cache) {
rewrite ^ /_main_cache/ last;
}
fastcgi_pass unix:/run/php-fpm.socket;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param HTTP_GEOCOUNTRY $geoip_country_code;
  
}
location = /_main_cache/ {
internal;

#Это чтоб в бэкэнд везде приходил правильный адрес, никто не должен знать про 
_main_cache
rewrite ^ / break;

fastcgi_cache main;
fastcgi_hide_header "Set-Cookie";
fastcgi_ignore_headers "Cache-Control" "Expires" "Set-Cookie";
fastcgi_cache_valid 200 10s;
fastcgi_cache_key "/";
fastcgi_cache_use_stale updating;
fastcgi_cache_lock on;

#Аноним после первого посещения не аноним, а так как мы игнорируем Set-Cookie 
ставим средствами nginx.

add_header "Set-Cookie" "visited=1; path=/";

fastcgi_pass unix:/run/php-fpm.socket;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param HTTP_GEOCOUNTRY $geoip_country_code;
}


Можно как-то изящнее и феншуйнее? Пожалуйста, не предлагайте переделывать 
бэкэнд. Это нереально.

С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Кто же сильнее Cache-Control или X-Accel-Expires?

2017-04-20 Пенетрантность Иван 
Здравствуйте! 

Есть конфиг бэкэнда, вот его кусочек:

location ~ \.m3u8$ {
expires -1;
add_header "X-Accel-Expires" "100"
}

Как следует из русской и английской документации:
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid 
(кстати, как делать красивые короткие ссылки на документацию, которыми 
оперирует в этом списке рассылки команда nginx?)

> Если в заголовке нет поля “X-Accel-Expires”, параметры кэширования
> определяются по полям заголовка “Expires” или “Cache-Control”.

То есть можно предположить, что приоритет у X-Accel-Expires.
Но нет. Как показывает моя практика и, например, этот вопрос: 
https://serverfault.com/questions/641367/nginx-using-x-accel-expires-with-cache-control

Приоритет имеет Cache-control. То есть в такой конфигурации на фронтэнде:

location ^~ /video/ {
proxy_buffer_size 16k;
proxy_buffers 32 16k;

proxy_cache video;
proxy_cache_lock on;

proxy_cache_use_stale updating;
proxy_cache_key "$proxy_host$uri";

proxy_pass http://backend;
}

m3u8 файлы, проходящие через этот локейшен на приведенный выше локейшен 
бэкэнда кешироваться не будут. Ситуацию спасает только
proxy_ignore_headers Expires Cache-Control;

Подскажите, пожалуйста, где ошибка: в nginx, документации или моём понимании 
того или другого?

С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru